Последний раз я обещал задать вопрос сообществу. Что же, сам заголовок не до конца описывает то, о чем речь пойдет дальше, но лаконичнее я ничего не придумал.

У меня еще до новогоднего подкаста, из-за некоторых заметок, рассуждений людей о механиках, из-за жарких споров о том, как все же стоит делать игры, в которые мы хотим играть, из-за рассуждений об ECO 9.0 и плеймекерстве, возникла мысль, которая бередила мою голову во времена, скажем так, геймдизайнерской молодости. Собственно, в своей последней заметке я о ней и писал. После прочтения диалогов о ГМ-ах я уже окончательно убедился, что пора об этом поговорить.

По факту многие уже занимаются плеймейкерством и часто пишут об этом.

Но как я и говорил — в большинстве случаев невозможно поменять какие-то базовые, может, даже фундаментальные вещи в игре, которые по мнению многих стоило бы поменять.

Если вернуться к моей прошлой заметке, то где-то в середине таймлайна можно наткнуться на, скажем так, дыру в пространстве, где мы просто занимались своими делами. Суть в том, что где-то тогда же, или может чуть раньше, я набрел на довольно интересный свободный проект, который, по сути, предлагает не просто песочницу, а буквально гору песка, вроде того, что есть в Minecraft, но эта песочница лишена многих недостатков своего проприетарного старшего брата.

Мне только спросить: Блог им. William_Godwin: Хотели бы вы, чтобы у ММОзга был свой маленький виртуальный мир со своими правилами?

Итак, я хочу предложить для начала лишь обсудить за и против, посмотреть на проблему со всех углов.

Minetest — это даже не игра, а инструмент по созданию игр на довольно простом скриптовом языке. Но спектр возможностей, которые дает этот инструмент, практически не имеет каких бы то ни было ограничений. Разве что в рендер влезть можно только где-то глубоко, понимая, что именно ты делаешь и как вообще работает ядро. Это расстраивает только лично меня, т.к. хотелось бы попробовать какие-нибудь шейдеры написать, почему нет?

И я предлагаю сообществу поразмыслить над тем, чтобы создать свой виртуальный мир, наполнить его своими правилами, механиками, всем тем, что мы так долго ищем в одном месте, но никак не найдем. Хотите механик из H&H + ECO? Пожалуйста. Отсутствие PvP? Без проблем. Наоборот — PvP и сложную систему штрафов? Сколько угодно! Хотите Si-Fi, хотите что-то похожее на Worlds Adrift? Да что угодно, пока общее число пользователей не перевалит за пару тысяч.

Мы можем взять чужие идеи, но взять все лучшее, изменить и убрать все худшее и создать для себя и товарищей среду, которая будет не просто приятным времяпрепровождением, а прецедентом! Вы сможете сказать: «да вот же все работает, черт возьми!»

Конечно, я бы с удовольствием помог с графикой, как 2D, так и 3D, возможно с чем-то еще, но нужны те, кто решил бы заняться таким проектом, и те, кто поверил бы в него.

Думаю, это очень сложная тема и, возможно, возникнет бурное обсуждение. А может, окажется, что никто не готов вкладывать силы в мимолетную фантазию. (ничего страшного это можно понять) Я не буду сильно защищать эту идею, так как она в каком-то смысле довольно радикальная и требует поддержки многих людей. Но я считаю, что не поделиться ею было бы преступлением. ^_^

Так что… Что думаете?

48 комментариев

avatar
Однозначно да
  • +1
avatar
Вопрос не в том, «хочешь или нет». Вопрос больше в том, кто будет решать что делать.
Демократия большинства? — плавали, знаем. По всем законам психологи как только собирается больше нескольких десятков человек, трения неизбежны.
Диктатура администрации? — сколько человек из местных ее примет. Не тот контингент.
Внутренняя демократия при решающем голосе кодеров? — сколько их тех кодеров будет

Вот если договориться о том, как принимать решения и затем неукоснительно соглашаться с этим договором. Но только говорить о том, как оно должно быть правильно гораздо легче, чем самому принимать правильные решения. Если в комментариях идут временами настолько серьезные баталии, то что говорить о воплощении на практике.
  • +7
avatar
Прямая демократия — единственный способ определить что действительно нужно сообществу. Ее не менее важный аспект — не только сам процесс принятия решений, но и возможность дробления сообществ, как и пересечение с объединением. (в этом плане сообщества открытых проектов и их форки очень яркий пример) Да, не может и никогда не будет ситуации, при которой все со всеми во всем согласны, так поэтому люди и объединяются, поэтому, если говорить об играх, есть такая штука как целевая аудитория. Именно поэтому последнее время столько проблем с ММО — они пытаются не целевую аудиторию завлечь и создать сообщество, а нагнать побольше «потенциальных клиентов».

В формальных обсуждениях так же могут существовать правила, которые предварительно устанавливаются голосованием. Серьезно, посмотрите на крупные открытые проекты на гитхабе или гитлабе, на блендер.
  • +4
avatar
Прямая демократия — это отнюдь не единственный способ. Прямая демократия МОЖЕТ быть полезной для определения начальной стратегии, но затем процесс развития очень сильно зависит от самого сообщества. «Крупные открытые проекты» тем и хороши, что в них на стадии создания остаются только люди, согласные по большинству вопросов, а все остальные отсеиваются еще на стадии организационных вопросов.
Как квинтэссенция этого — «Прямая демократия хороша для узкого сообщества единомышленников». Но для сообщества с разноплановыми мнениями она может быть весьма разрушительна. Яркий пример для тех, кто в танке. Первая итерация Эко была весьма успешной, потому что сервер был закрытый и принимали только единомышленников. Третья итерация вызвала некоторые разногласия в сообществе игры, поскольку сервер был открытый, хотя и рекламировался в достаточно узком сообществе. Что-то подобное я наблюдаю сейчас в Атлантис, но там как раз «демократическая диктатура» и поэтому разброда и шатаний нет.

PS. Дабы не совсем оффтопить — я бы даже поучаствовал в создании как кодер и геймдизайнер.
Комментарий отредактирован 2020-01-21 21:02:19 пользователем selezin
  • 0
avatar
«Крупные открытые проекты» тем и хороши, что в них на стадии создания остаются только люди, согласные по большинству вопросов, а все остальные отсеиваются еще на стадии организационных вопросов.

Ну почему же? В любой момент можно начать реквестить изменения из своей ветки, если оформить запрос правильно и написать годную фичу, которая всем понравится, то в чем проблема? К слову, у каждого проекта доля авторитаризма действительно разная, но это уже скорее по историческим причинам.

1) Когда человек является продуктом своей среды и ведет себя так, как принято в этой среде, все проблемы детерминированы именно его средой, а не методами управления.

2) Прямая демократия предполагает, что сообщества, как я и писал это не разрозненные группы по интересам, а просто кооперирующиеся и пересекающиеся сообщества. Решение конкретного вопроса у конкретных людей и не должно затрагивать тех, кто к этому вопросу не имеет отношения.
Собственно, мнения, которые не уживаются приводят к голосованию по поводу создания «форка». Не вижу тут проблемы. Я же не зря привел пример.
Хотя, стоит признать, что чистый референдум без федераций и прямых представителей федераций (то есть маленький, но все же элемент представительной демократии) на реальных гигантских сообществах не сработает.

Если действительно готов писать на Lua, то это ОЧЕНЬ круто, т.к. как раз еще и его учить и писать что-то параллельно своему проекту я не готов.=) Надеюсь будут еще люди, и тогда обсудим!)
  • 0
avatar
Собственно проблема ровно одна. Несогласные с принятием какой-либо фичи с большой долей вероятности покинут проект, даже если участвуют в нем в качестве «электората», а не разработчиков. Конечно, это не значит, что после каждого принятия серьезного решения сообщество уменьшится на треть/четверть, но уменьшится точно. С каждым новым решением людей будет все меньше и меньше, ибо «обещали, что будет как я хочу, а сами все решают по-другому». И даже понимание, что решало большинство не поможет. А делать что-то «чисто для своей тесной группы сотоварищей» — тупиковый путь.
По личному опыту чистая демократия срабатывает только в случае принятия самых общих решений. Хотя даже такое фундаментальное решение, как быть/не быть пвп, расколет сообщество на два огромных лагеря и борьба будет ого-го-го. Лично мне ближе принцип «послушай других и сделай по-своему».

С учетом того, что программированием вплотную я не занимался лет пять (если не больше) и времени свободного у меня как у любого специалиста на 8-часовой ставке, то в принципе да, готов попытаться писать код. Правда, в сетевом программировании я нуб полный, но с внутренним кодом сервера справиться в состоянии, думаю.
  • 0
avatar
1) Если человек даже после обсуждений и попыток найти компромисс наотрез откажется сотрудничать, то какой смысл дальше сотрудничать? Тяжелые споры и разбирательства не улучшат качество чего бы то ни было.

2)Ну кто-то уйдет ( я уверен, что из-за КАЖДОГО решения кто-то точно уходить не станет, люди из игр-то не особо уходят =) ), а кто-то придет. В любом случае при наличии какого-то фундамента уже формируется целевая аудитория, как и тут на ММОзге уже есть определенная ЦА.

Насчет программирования. Там простой интерфейс в виде набора готовых функций и переменных и никакого сетевого кода и т.п. не требуется. Практически сразу можно писать игровую логику. Максимум если захочется очень с генератором мира побаловаться, то там да что-то свое нужно, но апять же можно и просто попросить меня карты высот состряпать))
  • +2
avatar
Если человек даже после обсуждений и попыток найти компромисс наотрез откажется сотрудничать
Если бы дело касалось десятка энтузиастов, то спору нет. Но как я понимаю, предлагается создать что-то, что устроит достаточно обширную аудиторию ММОзга. Это, конечно, не десятки тысяч потенциальных пользователей ААА-ММО, но зато и предполагается, что в какой-то степени участвовать будут все заинтересованные/желающие. А значит, будем наступать на те же грабли, что и большие студии. Интереснее будет смотреть как участники пытаются найти компромисс, нежели делать что-то конкретное. Или я неправильно понял изначальную задумку?

— Пока так примерно просмотрел что предлагается конструктором. Первое впечатление, что не все так уж радужно и обширно. графика таки весьма кубична и вряд ли ее получится поднять. LUA не особо способствует обработке серьезных запросов, скажем ИИ для животных пока неясно как нормально реализовать. Сама система «Клиент и сервер в одном флаконе» кажется спорной, хотя я возможно еще не совсем пониманию принципы. И т.д. Разбираться и разбираться.
Хотя как некий симулятор социальной общины я уже подумываю как реализовать можно.
  • 0
avatar
Однозначно нужно.
Для опытно-практической отработки обсуждаемых здесь (в рамках данного сообщества) особенностей общераспространённых игровых механик.
На оформительскую часть лучше забить в пользу проработки вышеупомянутых игровых механик (смотрите на Еву – осовремененное оформление в ней смотрится как седло на корове).
Для того, чтобы число персонажей не перевалило лимит, лучше ввести типа подписку. Типа с подтверждением по электропочте, привязанной к аккаунту ММОзговеда
  • 0
avatar
Воу воу!)

Я думаю, что это можно пока делать и без оплаты, суть-то не в ней. Тем более смысла создавать лишние пороги для вхождения я не вижу, например.

Обычно онлайн, то есть среднее число игроков в единицу времени это 0.5 — 1 % от тех, кто вообще устанавливал клиент или оплачивал подписку\коробку. С учетом возможностей Minetest, «прочности» на такую затею ему должно хватить.
  • +1
avatar
Звучит интересно, уже есть идеи где вы будете организовываться?
  • 0
avatar
Не совсем понимаю что означает «Где».))
  • 0
avatar
Ну т.е это будет сервер дискорда, форум, ветка на этом сайте или что то еще. )
Как будет происходить обмен наработками и прочими штуками ?)
Комментарий отредактирован 2020-01-21 23:29:09 пользователем EvilCr4b
  • 0
avatar
А, ну если Атрон позволит, то лучше, наверное дискорд.

Плюс я привык к гитлабу (тем более уже возможно кодер намечается ))) ), а там есть система реквестов, соответственно там позже можно будет конкретные реквесты обсуждать, голосовать и роадмап тоже делать.
  • 0
avatar
А, ну если Атрон позволит, то лучше, наверное дискорд.

Отдельный канал? Да без проблем, конечно же.
  • +3
avatar
Я не очень понимаю практическое применение.

Окей, есть конструктор, в котором можно реализовать любую механику. Что дальше? Окей, возьмём самый яркий пример — в Эко 9.0 не будет противостояния правительств, и многих это печалит. Сколько нужно кодеро-дней, чтобы хотя бы крупными мазками повторить основные эковские механики и дополнить их теми, которые планируются в 9.1?

Кто будет этим заниматься, на каком языке, разделяет ли он нашу приязнь к Эко (или не к Эко, а к чему-то другому, что мы захотим реализовать)?
Комментарий отредактирован 2020-01-22 00:17:57 пользователем ky0uraku
  • +1
avatar
Польза подобной инициативы не столько в том, чтобы что-то воспроизвести, а в том, чтобы опробовать в изолированном окружении отдельные механики и уже из них собрать виртуальный мир. Вертикальный vs горизонтальней прогресс, системы ограничения бесконтрольного PvP, баланс игроков с разной длиной игровой сессии.

Цели что-либо воспроизвести, конечно, ставить не нужно.
  • 0
avatar
Вы так говорите, как будто всё перечисленное уже лежит на блюдечке и двумя кликами мы можем взять и добавить в наш конструктор PvP, несколько видов прогресса и далее по списку.

Если я правильно понял — ничего этого нет.

Ну и проверять какие-то гипотезы из других игр в вакууме — это, мне кажется, довольно бессмысленно, потому что на игроков воздействуют не только сами механики, но и всё остальное комплексно — оформление, сеттинг, комьюнити…
  • 0
avatar
а в том, чтобы опробовать в изолированном окружении отдельные механики и уже из них собрать виртуальный мир.
Тестирование отдельной механики без привязки к полноценному сеттингу — тупик. Механика-то может и хороша, но без взаимодействия с другими механиками — она как рычаг без коробки передач. Что вы можете сказать о характеристиках автомобиля, рассматривая отдельный рычаг? Да и даже цельную коробку передач без ее интеграции в двигатель?
  • 0
avatar
Кто будет этим заниматься, на каком языке, разделяет ли он нашу приязнь к Эко (или не к Эко, а к чему-то другому, что мы захотим реализовать)?
Заниматься будут энтузиасты, как же иначе :)
Язык указан — LUA.
А вот с «разделяет ли он нашу приязнь» будут проблемы, я лично пока не вижу каким образом групповым решением можно создать принципы и сюжеты.
Комментарий отредактирован 2020-01-22 00:48:40 пользователем selezin
  • 0
avatar
``` Сколько нужно кодеро-дней, чтобы хотя бы крупными мазками повторить основные эковские механики и дополнить их теми, которые планируются в 9.1?```
Я думаю годы…
И это одна из основных проблем этой идеи-это слишком много труда, слишком долго.
Комментарий отредактирован 2020-01-22 11:23:52 пользователем VezhiyOleg
  • 0
avatar
На что нужны годы? На сотню строк скрипта, регистрирующего сущности и ивенты? Да это, скажем, одна какая-т окомплексная механика, но годы. Простите и не сочтите за хвастовство, но за 1.5 года мы свой движок физический написали, который уделывает PhysX и Bullet.)) (и «мы» в данном контексте означает, что я подкидывал идеи архитектуры, а делал по факту все один человек с перерывами на работу. ^_^)
  • 0
avatar
ок. Напишу подробнее. Я работаю senior developer с общим стажем программирования более 20 лет. Участвовал в том числе в крупных и серьезных проектах. Я конечно в данном случае не владею комплексной информацией о среде языка и способов построения алгоритмов и логики в нем. Но исходя из моего опыта agile, scrum и итерационный оценки времени выполнения задачи, для повторения основных эковских механик необходимо явно более 700 человеко-дней.Это конечно очень грубая и даже эмоциональная оценка, но просто я в целом представляю себе объем механик Eco и время для реализации подобного, насколько бы удобным не были инструменты для создания игровых механик. И это все не учитывая ограничения движка и языка с которыми неизбежно придется столкнуться.
При этом Ваша идея мне кажется бесконечно вдохновляющей и крутой, но просто поймите что это надолго
Комментарий отредактирован 2020-01-22 22:02:31 пользователем VezhiyOleg
  • +3
avatar
Я все понимаю, но я не просто козырнуть решил. Вы представляете сколько человека в Nvidia работало и работает над PhysX? Знаете какой результат? Он бесполезен в случае, если вы не пишите простой шутер на десяток человек или долго и упорно не моделируете текущую воду и развивающиеся флаги. Про объем легаси кода в коммерческих движках и вообще раздутой кодовой базы даже заикаться бесполезно.

И таких примеров в индустрии просто гора, так что я не считаю, что это аргумент, уж извините. Слишком много я встречал senior developer-ов ( ни в коем случае не принимайте на свой счет), которые, например, не понимают разницу между реляционной моделью данных и базой данных.
  • +1
avatar
Хоть я и полностью согласен с представлениями объемов легаси кода, с количеством человека в Nvidia работавшим над PhysX, с общей температурой примеров по больнице индустрии (да что там, я же сам все это каждый день вижу).
Однако, обобщенные библиотечные решения являются важными и эффективными компонентами любого проекта. PhysX надо уметь готовить. У него тяжелая документация, а работа с ним требует от пользователя недюжих знаний математики. В основном — тензорной алгебры и функционального анализа. А максимального преимущества от PhysX/Bullet/Havok/… можно добиться, собственно, разделив видимое пространство на N пространств. Камни — в одном, люди — вдругом, машины — в третьем, деревья — в четвертом. Все счастливы и вся физика на десятках квадратных километров пространства считается за 2-4мсек и синхронизируется по сети.

Писать свое решение можно. Это даже полезно. Просто еще важно допускать сомнение в том, а насколько твоя реализация выгоднее более глубокого изучения уже имеющихся решений.
Есть и еще один момент: обобщенное решение позволяет тебе задействовать функционал сразу на ранних этапах работы и в краткие сроки собрать прототип с желаемыми механиками.
  • +2
avatar
Главный вопрос тут, а какие мощности для этого понадобятся? Суть ведь еще и в эффективности работы движка)

Наша проблема была в том, что прототип можно и на UE4 заделать, вот только пользы от него мало, ведь 500к + динамических капсул он посчитать не способен (никакие «живые миры» там нам не светили), вне зависимости от объема пространства, количества статики, физ. материалов, да и вообще чего угодно. Мы проделали уйму тестов и они четко показывают графики со скачками и плато, где видно переполнение кеша объемами данных, видны проблемы синхронизации потоков и не менее большая проблема деревьев (а это вообще фундаментальная штука во всех современных физ. движках, от которой мы как раз отказались)) ), которые нужно постоянно перестраивать.
Да, наверное можно заставить вообще каждый чанк мира считаться на отдельной одноядерной машине, но эффективно ли это? А сколько это стоит? Как по мне сначала нужно добиться максимальной производительности в условиях одной машины, а вот когда тебе уже точно не хватает именно физических ресурсов того же CPU, то можно уже задумываться о сети. Как минимум я это вижу более логичным.
  • 0
avatar
Вопрос генерации идей и их проверки один из самых важных в геймдеве, так что создание такого маленького виртуального мира определённо нужно. На мой взгляд, не обязательно даже ограничиваться одним миром. Как в системе контроля версий, можно сделать ветки, идущие по разным направлениям. Но в итоге, пройдя через тестирование, сливающиеся в единый master-мир. Я даже думаю, что подобное начинание, в случае, если оно принесёт осязаемые плоды в виде разработанных и принятых сообществом механик, может быть интересно не только нам самим. Инструмент для тестирования идей важен для индустрии в целом.
  • 0
avatar
Сразу видно, проект получил отклик ^_^
Мне всё равно кто будет принимать решения, если смогу чувствовать свою вовлечённость и полезность.
Думаю стоит поставить точку отчёта успешности проекта, скажем на 30 игроках, после альфы продвинуться в интернете с целью получения притока новых людей, тогда не страшен будет уход старых игроков. Всем всё равно не угодишь.
  • 0
avatar
LUA как то смущает, сам сервер на с++, некоторые инструменты на втором питоне, на мой взгляд нужно ориентироваться на эти языки. Опять же луа встроенный язык, возможно стоит делать внешнии сервисы связанные с игрой по апи, например систему торговли, перемещения (телепортации), производства.
Возможно что то типа догмы из евы…
  • 0
avatar
Предлагаете переписать сервер? :)
  • 0
avatar
Меня тоже Lua смущает, есть же много более новых языков. Или хотя бы JavaScript, который знают значительно больше людей, чем Луа. Вообще на Луа что-то пишется, кроме игровых UI?
  • 0
avatar
Lua является широко распространенным встраиваемым языком программирования. Простота его встраивания и природная склонность к параллелизму, в купе с крайне хорошей внутренней оптимизацией, позволяют этому языку прекрасно подходить как для встраиваемых решений, так и для решения прикладных задач в области математики, физики и химии.
Мало кто на lua делает именно UI, в основном Lua используется для выполнения бизнес логики игр, программ симуляции и самых всевозможных контроллеров систем автоматизации.

Многих людей отталкивает необычность грамматики языка. Меня тоже отталкивает. Lua является математически ориентированным языком и создавался в первую очередь для решения математических задач. Этим и обусловлена грамматика Lua. Математикам так понятнее и удобнее.

А если кому-то кажется что встраиваемый интерпретируемый язык не может решать задачи достаточно быстро, то лично я советую посмотреть на проект Terra. Транслятор Terra построен на базе проекта LLVM (clang и еще целый ворох компиляторов вроде spir-v, glsl, hlsl), который позволяет транслировать код Lua в опкоды процессора буквально на лету, создавая тем самым новые, правильно выравненные секции исполнения прямо во время работы основного кода программы.

Сам же Lua очень часто выступает в качестве эталонной массы для сравнения быстродействия разных встраиваемых языков.
  • +4
avatar
Дело не в быстродействии, а в том, насколько легко его изучить и начать писать на нём, насколько всё понятно с первого взляда, сколько людей его уже знают. Хорошая документация к API, поддержка IDE и т д. Имхо, легче найти 10 ММОзговедов, которые могут сесть и написать что-то на JS, чем одного на Lua.

Да и въезжать в математические абстракции — не самая привлекательная идея, когда хочешь просто сделать игру.
Комментарий отредактирован 2020-01-28 19:46:18 пользователем Eley
  • 0
avatar
Очень просто найти 10 человек, которые напишут что-то на JS и оно не будет работать, это да.
  • +1
avatar
Когда дело касается игр, дело всегда становится в быстродействии. Чтобы обеспечить 96FPS, один такт симуляции не должен занимать больше 10.42мсек. Не менее 8мсек должно быть отведено на обработку звука и картинки. Ну а все остальное время полностью в вашем распоряжении, товарищи разработчики бизнес-логики. ~2.5мсек… на четырех-шести ядрах, на четырех-восьми потоках, со строгим аффилированием. Пользователь же хочет собрать комп за $300 и чтоб на нем любой AAA летал на ультрах. :)

JS(v7) в 51 раз медленнее Lua. v8 — в 3.5 раза медленнее только за счет AOT, но весит как слон и встраивается как питон — никак. Трансляторы v7/v8 — расширяемые, а не встраиваемые.
JS-пользователя найти проще чем пользователя Lua. Но стоит применить критерии отбора, как для игр пользователя Lua становится в несколько раз проще найти чем пользователя JS.
Как только ты заходишь в геймдев, там сразу начинает царить Lua и еще несколько интерпретируемых собратьев.

AngelScript является встраиваемой версией C/C++ с незначительными изменениями, он всего в 2 раза медленнее Lua и этот разрыв можно стереть руками, немного исправив его виртуальную машину.
Вопрос всегда был в выборе между Lua, AngelScript и ChaiScript. И у Lua сообщество значительно больше других конкурентов. Поэтому Lua и популярнее.

Remedy работают с D. Движок у них компилируемый, с ручным управлением памятью, а бизнес-логика — интерпретируемая и со сборщиком мусора. D из коробки позволяет оба этих режима сборки, в обоих случаях давая максимально возможное быстродействие и прекрасную плотность команд.
Control, Quantum Break и более старые проекты дают прекрасное представление о том, что D может предоставить своим пользователям.

А по поводу скорости обучения, ты просто не играл в РО. :)
К 2008 году в клиенте РО стала доступна виртуальная машина команд, которую туда затащили разработчики чтобы дать больше возможностей гомункулам алхимиков. Языком команд был Lua, который разработчики затащили абсолютно никак не порезав.
В результате, менее чем за год вся школота уже прекрасно владела языком. Многочисленные доморощенные умельцы клепали своих полноценных ботов прямо внутри клиента игры. Система команд гомункула представляла из себя огромную дыру в безопасности клиент-серверного взаимодействия.
Для приватных серверов на основе Афины этот момент тогда стал настоящим бичом, т.к. со стороны сервера это никак не засекается.
Язык изучается очень легко.
Комментарий отредактирован 2020-01-29 09:29:10 пользователем FrankStein
  • +11
avatar
Два ChaiScript`а этому господину!

На нашей пиратке гомункулы не работали, да :(
  • +1
avatar
FPS же относятся к отрисовке, а зачем пересчитывать бизнес-логику так часто? Если моб будет целую секунду думать, напасть ему на меня или на тебя, то ничего страшного не случится, по идее. Или законы мира — нажал рубить дерево и вполне можешь треть секунды подождать, пока система просчитает, разрешено ли законами рубить его.
  • +1
avatar
Угу, расскажи это всем игравшим на последнем цикле в Эко — когда каждая попытка убрать с земли ветки или пень выкорчевать залипала на эти жалкие полсекунды, но доставляла такой дискомфорт, что мне пришлось когтистыми админскими лапами срочно лезть и отменять этот закон :)
  • 0
avatar
А что, всех это сильно бесило?
  • 0
avatar
Да, играть стало крайне некомфортно — по сравнению с отсутствием лагов до этого.
  • 0
avatar
Не, ну в какой-то степени он прав, но только в том плане, что системы компенсации лага так и делают, но для игрока все происходит с моментальным откликом нормально.

Но, я боюсь, что все, что больше 500-800 ms никакой компенсацией спасти невозможно. Хотя, какие-то не требовательные к обновлениям штуки можно и подождать. Скажем, бекап в BD, не обязательно вообще держать что-то вне оперативной памяти — сегодня технологии это позволяют.
  • 0
avatar
Если моб даже 0.003 ms думает это вопрос контекста, ситуации. Одно дело если элемент массива обрабатывается 0.003 ms, а их там пара тысяч, а когда их 500 000 эти самые 0.003 определяют как долго система будет ждать, чтоб отрендерить следующий кадр.

Даже компенсация лага и\или предсказание с экстраполяцией дальше 500 ms использовать на регулярной основе в динамической сцене очень плохо. Кстати, будет как с теми же, например, машинами в эко, физика вообще очень не любит какие бы то ни было задержки.
  • 0
avatar
FPS — это универсальное мерило производительности игры. Сегодня, пока еще, эталоном является 60FPS. Но готовиться надо к 96FPS. Современные многоядерные и гетерогенные вычислительные системы, установленные в качестве домашних ПК (даже за те же $300), способны обеспечить игроку требуемые 60FPS с огромным запасом. Поэтому сегодня на ряду с мерилом FPS еще используют мерило TPF (Time Per Frame), измеряющееся в миллисекундах.

Так вот. Даже если процесс отрисовки кадра выделен в отдельном потоке, нарисовать все равно получится только стабильную картинку. Это означает, что когда кадр начинает асинхронно рисоваться, мир замирает и его нельзя трогать до самого конца отрисовки. Ух ты, даже в асинхронном рендеринге мы прилипаем к FPS…
Припомни на своей памяти артефакты анимации из FIFA, Mass Effect, Star Track, любой игры серии Batman и еще целой кучи тайтлов. Это происходит потому что кто-то забыл что при асинхронном рендеринге состояние мира трогать не надо.

На деле же, многие движки, если не строго привязаны к FPS (даже если рисуют асинхронно), то симулируют несколько раз между кадрами. У меня по умолчанию FPS ограничен на 60, а SPS (Simulation Per Second) ограничен 120. И в моей тестовой среде TPF сохраняется около 3-4мсек, т.е. я все еще могу усложнять геймплей. Но я знаю что у меня многие механизмы еще очень сырые и я могу сильно уменьшить свой текущий TPF.

Симуляция — это один маленький шаг жизни мира, когда мир имеет возможность обработать запросы пользователя, систем ИИ, анимации, физики, звуков и еще огромной горы всякого сервисного барахла. Тут нельзя просто так взять, запустить поток выполнять какую-то ересь и забыть о нем. Симуляция всегда должна начинаться в одном фиксированном состоянии мира и приводить к другому фиксированному состоянию мира. Иначе — баги из Mass Effect, TES, NFS и прочего, прочего, прочего… и из Batman. :)
К слову о мобах и их мыслях. ИИ думает каждую симуляцию, т.к. каждую симуляцию окружающий мир меняется. Механизмы вообще ИИ являются очень непростыми в объяснении и требуют отдельной заметки.
Но вот если тебе на пару секунд позже прилетит дамаг, ты будешь недоволен. Особенно если дамаг прилетит от уже убитого тобой моба, а ты такой сказал себе «Фууух» и не стал хилиться.
Задержки симуляции принципиально неуместны. Состояние мира между симуляциями должно быть детерминированным.
  • +6
avatar
Сложно сказать, где именно на графике Даннинга — Крюгера я нахожусь, но мне тоже кажется, что эта идея крайне сложна в реализации. Именно поэтому я жутко заинтригован. :)

Конечно, меня так и подмывает сказать «Да! Давайте сделаем Worlds Adrift!», но проблема в том, что Wolrds Adrift для меня — это те самые ванильные облака, та самая музыка, тот самый лунный свет и странной формы корабли. Поэтому не думаю, что нечто подобное можно будет воссоздать. Да и не думаю, что нужно. А вот новые идеи, аналогов которым нет, вполне.

Мы говорим про прямую демократию и другие формы принятия решений. А мне кажется, что на первом месте стоит всё же момент увлечения идеей. И поэтому естественным продолжением этой инициативы я вижу красивое оформление своих идей, даже небольших, в качестве отдельных заметок под единым тегом. Крутое описание того, что можно было бы реализовать в рамках предложенного полигона, на ваш взгляд.
  • 0
avatar
Увлечение идеей — это хорошо. Но опыт в
многие уже занимаются плеймейкерством и часто пишут об этом.
говорит мне, что именно принятие решений часто убивает проект. Не поиск кодеров, дизайнеров. Не технические сложности. 80% идей убивает именно невозможность договориться в команде «что же мы делаем». Если в общих чертах расходятся редко, то как только начинается рассмотрение мелочей — команда распадается. Например, чтобы кодер работал эффективно нужно либо платить ему, либо сделать так, чтобы перед ним стояли интересные задачи, либо дать ему возможность реализовать то, что именно он хочет. Если кодер будет делать то, что решило большинство, но не он, то его интерес падает со временем экспоненциально.
  • +2
avatar
Для меня между плеймейкерством и геймдизайном слишком много различий. Плеймейкеры, как я уже много раз говорил, похожи на инженеров ЦУП из сцены фильма «Аполлон-13» — они оперируют только тем, что есть на борту конкретной игры. Геймдизайнер оперирует на совершенно другом уровне. На уровне идеи о том, чего ещё нет, но могло бы быть.
  • 0
avatar
Ну что, товарищи, которые плюсов поставили аж 19 штук, вы в дискорд пойдете обсуждать?))

Никого не гоню, думаю тут торопиться особо некуда, но чтоб закрепить внимание сделать первые шаги.)
  • 0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.