- ildarin
- Постоялец
Я с Ren'ом согласен, нафиг не нужное хз что, даже толком объяснить не могут.
Разные симуляции уже изобретены, кому то нравится, кому то не.
ildarin
>Конечно. А разве есть смысл считать себя ничтожным?
Есть смысл пользоваться опытом других. Или ты всерьез считаешь что ты это первый придумал? Концепция, где карта сражается сама с собой, а игрок лишь песчинка этой войны, я придумал впервые в 98 году, когда играл в мад. Там было две банды НПС они передвигались рандомом и агрились друг на друга, если оказывались в одной клетке
ildarin
> Юнити - ок. Я с навмеш не работал, и предпочитаю понятные открытые решения (зачастую собственной разработки), особенно когда дело касается производительности. Сторонние решения - закрыты и сложны в понимании, что сказывается. Но построение карты перемещений и поиск пути (a star) - это тривиальная задача, тут не вижу смысла проверять - это реализуемо и результат понятен.
Тогда советую поработать, а не делать свой велосипед. Результат все равно не понятен. Но в рамках теста можно сравнить - Вы разрабатываете на А-Стар, я на НавМеш. Сравниваем, код открытый?
Но вы понимаете, что с таким велосипедом, от вас потребуется дополнительная реализация построения карт. Например, строим мы здание, и ваш поиск пути должен это учитывать. + Никаких дискретных карт занятости. + Разные карты, для юнитов разных размеров.
tac
> Вы разрабатываете на А-Стар
Я с этим алгоритмом уже не одну игру сделал) Давай лучше на "ты"? Если хочется - можешь попробовать сделать, но выглядит как попытка натянуть свою логику на ограничения сторонней либы.
Это не "велосипед", это то, как разрабатываются серьезные игры. Не просто так набирают спецов на с++ и пишут свои шейдеры, а не используют ассеты и коробочные решения. Как раз таки любители делают игры на встроенных либах, вроде встроенного движка физики в юнити. Я уже написал - почему так, не хочу повторятся.
Да, лучше реализовывать самому, чтобы все было оптимизированно. Про поиск пути и строение зданий с перестройкой - это всё на чистом astar* можно делать. А там уже есть куча различных технологий для этого, есть статьи. Например, на графах и многогранниках, с сохранением путей перемещений и т.д. Да, в этом нужно разбираться, учить матчасть и читать книжки по математике и геометрии.
При корректном построении архитектуры ПО - юнити - это слой "представления", т.е. интерфейс. Это слой, на который ни один из внутренних компонент не должен быть завязан. Например, если смотреть майнкрафт - там логика чанков и т.д. - это независимый от графической библиотеки кусок логики. И код там хорошо оптимизирован. Игра не рисует кубики, которые не видно и т.д. - эта вся "ручками" написана. В хорошем коде разработчик должен понимать код полностью, без "магических" кусочков юнити-физики, которая хрен пойми как внутри работает.
И при создании игры - тоже можно на этапе диз-дока прописать все игровые взаимодействия, без темных пятен. Описать все возможные игровые ситуации, наполнение контентом и т.д. Можно и отчасти, потом допиливать, но костяк должен быть четкий.
ildarin
> Да, в этом нужно разбираться, учить матчасть и читать книжки по математике и геометрии.
Зачем? Вот пока переписывались, я уже набросал и понял примерные цифры теста, а ты их еще и близко не знаешь, у тебя темное пятно ... а самое главное не для чего делать велосипедные (да, да это уже именно велосипед, когда есть стабильное решение верить в чудо ассемблера) решения. Цифры будут только у тебя хуже, чем у юнитеского готового решения. (это распространяется на их стабильные решения, а НавМеш это стабильное решение - в отличии от физики, которая в юнити вообще ни какая, но мы не о физике)
Лан, я не жадный цифры такие.
Допустим мир целиком это 30х30 км. - мир сравнимый с миром Кенши. Обсуждаем в соседней теме. И кстати, Кенши использует НавМеши - там можно легко в сборке найти папку НавМешей порядка 1-2 гига.
Далее, террайн у нас 1024х1024, с высотой до 750. Размеры разрешения текстур т.н. сплатмап сильно уменьшенные по сравнению от дефолтного (иначе по умолчанию один такой террайн занимает 20 Мб) = 256х256, такое же разрешение высот. В общем максимум до чего можно уменьшить это примерно 1,2-1,5 Мб. Это для рендеринга. Но примерно такой же размер занимает и сам НавМеш - который указывает какие есть территории и какие проходимые из них (по умолчанию они занимаю 5-7 Мб, но можно уменьшить до 1,5 мб.)
Итак у нас есть 1,5 мб х 900 примерно 1,3 Гб памяти - понятно, что постоянно столько держать в ней нельзя. (т.к. есть еще и рендеринг и куча всего другого). Но скажем процентов 10% можно кэшировать. Загрузка одной карты занимает порядка 1 мс. т.е. примерно 100 мс. из 1 сек. мы потратим просто на перезагрузку карт. (Если бы мы загружали бы все сразу, то только этим и занимались бы). Итого у нас есть где то 0.9 сек полезного времени на 10% карты. Учитывая что реакция игрока до 1 сек. это вполне допустимо.
Что касается числа НПЦ. Были у меня другие тесты, до 5000 в одном кадре еще допустимо. Но не более. Что-то серьезное можно сделать до 1000 . Это геймплеем нужно обеспечить. Но у нас 900 террайнов, поэтому если NPC меньше 1000 вообще, затрат будет еще меньше, т.к. с большой вероятностью будут террайны, где вообще нет NPC и соответственно, те где NPC больше 1, а значит загружать надо 1 раз, а рассчет будет для большего числа NPC.
Итого сделать игру где 30х30 км и 1000 юнитов, можно вполне себе можно обеспечить их реальную "живость". Но если делать больше - будет плохо.
Ren
То, что у кого-то что-то не вышло не означает, что не выйдет ни у кого. Заметил, что в Скайриме можно рубить поленья? Это вырезанная логика с лесопилками.
Подчерпнуть опыт других - так я только "за". Например, мне интересная механика социальных взаимодействий между нпц, вроде "Дилемма Заключенного". Кстати, вот какие-то люди этим занимались. Если думаешь, что они занимались какой-то фигней и лучше бы деньги зарабатывали и лайки/просмотры набивали - ок, твоё право, но обсуждать нам тогда тупо нечего.
Меня интересует КАК сделать интересную песочницу с событиями на взаимодействии нпц между собой и игроком без лудонарративный диссонанса. Например, диалоговую систему на "словах". Когда это не выбор из 3 предзаписанных текстов с предзаписанным вопросом в шапке; а текст формируется логикой игры, как в Shadows Of Doubt. Какие еще есть примеры? Какие игровые ситуации можно сформировать и как их реализовать? Как сделать это интересным? Какие еще модели реального мира можно перенести в игру и сделать их частью геймплея?
Например, в Middle-earth: Shadow of War есть механика, при которой порабощенный орк может свергнуть и занять место в иерархии. Интересно? Да. Можно ли представить аналог такой механики, например, в Скайриме? Да. Как эта механика может быть реализована в рамках сабжа? Вот и вопрос.
> Или ты всерьез считаешь что ты это первый придумал?
Что придумал?
tac
> Были у меня другие тесты, до 5000 в одном кадре еще допустимо.
Все прекрасно, пока мы принимаем твою машину за "эталон ЭВМ". Тогда уж и пиши "минимальные требования". У тебя смешалось в одну кучу - нагрузка на проц и на видюху. Отображение "юнитов" - сколько полигонов, какие шейдеры, разрешение и т.д.? И поиск пути + магические накладные расходы либы. Для поиска пути графика вообще не имеет значения - там другие алгоритмы и нагружают вообще другие компоненты ЭВМ (память и проц). Т.е. они вообще параллельны, не связанны. Для оценки производительности нужно измерять выделение памяти, операции на проце, алгоритмическую сложность и т.д. Оценить алгоритмическую сложность проприетарного кода - невозможно (без реверс-инжиниринга).
В A plague tale вообще добились отображения 300 000 крыс, используя различные методы оптимизации - может и больше получится. "Преждевременная оптимизация - корень всех бед" (с) https://elizarov.livejournal.com/17873.html
5000 и не нужно. Я выше подсчитал, что вполне достаточно около 50 нпц для погружения. Причем, возможно - часть нпц (50 шт) будут "умными", а остальные - ведомые или типа того, взаимодействующие всегда группой (типа домашних питомцев). Есть и другие методы оптимизации.
Инструмент нужно подбирать под нужды. Если нужно - то не юнити, а вообще OpenGL можно юзать. Если навмеш удовлетворит требованиям - то его. Не нужно копать молотком.
***
Пока что условно такой вариант: рпг управление одним персонажем в сеттинге средневекового фэнтэзи с орками (скайрим/готика). В одной группе нпц (города, деревни, лагеря) в среднем 7 персонажей, около 7 групп. Процедурная генерация мира. То, что может игрок - могут и нпц . Игрок может влиять на состояние группы (опосредованно), влиять на положение и отношение нпц/игрока в группе между собой.
В качестве ключевых рассматриваемых игровых ситуаций можно брать различные события историй (игр/кино/ирл) и раскручивать их до встраиваемых в модель. Как альтернатива - скрещивать и модифицировать уникальные механики уже имеющихся игр и программных реализаций.
Ладн, пойду кенши скачаю)
ildarin
> Все прекрасно, пока мы принимаем твою машину за "эталон ЭВМ". Тогда уж и пиши "минимальные требования".
Проц: 2th Gen Intel(R) Core(TM) i7-12700K 3.60 GHz
Оперативка: 16Гб
Карта: GeForce RTX 4060
остальное у тебя бла-бла ... и все можно посчитать, если делать тесты, а не крутить карандашом в руках.
И на самом деле - дело не в проце/оперативке или карте - дело в размере сборки, все остальное неважно, предполагая что делают сеньоры. Если она будет больше 10 Гб - это уже стремно. А тут только на пустую карту уровня 3-5 текстур порядка 3 Гб.
ildarin
> Ладн, пойду кенши скачаю)
Правильно, это минимальный уровень, который нужно сделать. И его нужно знать.
ildarin
> вполне достаточно около 50 нпц для погружения
ну и отлично, я для себя определил, что начну со 100. Мне больше нравится сеттинг по SciFi, скажем высаживаются на планету 100 людей. Тут опять же нужно посмотреть опыт киносъемок, где хорошо бы иметь 2-3 разных места. Если ограничить игрока не столько количеством юнитов, сколько "живут одновременно мест" скажем 5-10 одновременно живых мест может быть достаточным, с их переключением. Для любого кино это уже даже много.
На самом деле, одновременно контролировать можно 4 персов, 8 уже сложно (это я понял, играя в Stranded Alien Dawn, где реализована идеальная автоматизация персов, сравнительно в Кенши все загибается без присмотра). А 30 как в Кенши - при том, что она сильно багована почти не вероятно. Поэтому всего 100 "с именами" действительно вполне достаточно. Сколько болванчиков ходят сзади за лидером, - это уже не столь важно.
Вполне себе можно сделать как в Симс, там ограничение на кол-во симов в одном месте, сделано почти не заметно - они просто ротируются.
Так вот когда мы понимаем эти цифры - только тогда можно придумывать геймплей.
upd.
и да, после 8 персов, контролировать можно только хорошо автоматизированных персов, т.е. тех персов, которых игрок "заавтоматизировал" можно упростить до 1 "автомата".
ildarin
> Меня интересует КАК сделать интересную песочницу с событиями на взаимодействии нпц между собой и игроком без лудонарративный диссонанса.
Значит плохо отследил ту тему, которую сам же указал, что нашел.
Проблема всех ошибок - в умении разработчика с триггерами и со сценами (сценариями).
Ну и не озвучены критерии не_интересного, коли речь про нарратив. Но все какие-то критерии нерратива нельзя не разрешить декорацией, а вот живым миром - легко загубить.
> Например, диалоговую систему на "словах". Когда это не выбор из 3 предзаписанных текстов с предзаписанным вопросом в шапке; а текст формируется логикой игры, как в Shadows Of Doubt.
Названная игра тем и выделяется, что там все предзаписано:) Это моя концепция "живого времени", когда то писал на этом форуме об этом.
Обман обывателя в том, что там и само количество стеков на персонажа не фиксировано, а формируется, и сами слоты заполняется заготовками, которые меняются (считываются и записываются в стек-слот по триггерам изменений).
Fantarg
Минимум две проблемы фиксированного нарратива я уже назвал: диссонанс и отсутствие реиграбельности. Не хочу опять этот бессмысленный флейм "что лучше", задолбало. Ща бы еще обсуждать какой цвет самый лучший (фиолетовый если что).
Если я правильно понял - ты говоришь о генерации "сценария" из неких заготовок? Не совсем понятно без ссылки. Но если это так - то это как раз пример "процедурного" контента.
tac
> Мне больше нравится сеттинг по SciFi, скажем высаживаются на планету 100 людей.
Такое сеттинг я тоже рассматривал. В целом концепт такой: римворлд с проектированием и полетом корабля (потом вышла SPACE HAVEN - то, о чем я и думал). Но моделировать не только подконтрольную игроку область, но и остальную часть, включая высадки на планеты (по областям) и экономику мира. Недавно немного проработал похожий концепт.
Принцип схож с SH, команда жрет/пердит и оперирует системами корабля (слева). В режиме менеджмента - строительство и работа с командой. Но переключением на режим полета (камера отдаляется) - превращается в bullet hell с автотаргетом; возможно, частичным, как Ildarin Diabloid Roguelike - некоторые системы корабля позволяют "магию" Например, магнит притягивает ресурсы (строчка справа вверху в диздоке), которые команда таскает до склада. Требует энергию и всякое такое. Потенцивально - на оружие переключение с автотаргета на мышь.
Но в этом концепте только это, хотя моделирование экономики тоже хочется, с разными ресурсами на станциях, но это вторично. Графически - 3Д в изометрии.
ildarin
> А что вы думаете?
Я думаю: зачем это всё, если у Dwarf Fortress уже есть спрайты?
ildarin
> Минимум две проблемы фиксированного нарратива я уже назвал: диссонанс и отсутствие реиграбельности. Не хочу опять этот бессмысленный флейм "что лучше", задолбало.
Не-не-не. Здесь кроется смысл. Ты пробежал Скайрим по быстрому на минимальной сложности, не заглядывая в закоулки и не читая тексты. И тебя не интересовали никакие сторонние события.
Тогда как других игроков ты пытаешься заставить вникнуть в мельчайшие подробности ссоры между орком#756 и орком#344. На основании того что это якобы не скриптово.
То есть ты сам не являешься таким игроком, каким хочешь видеть всех остальных, отсюда и дыры в понимании.
ildarin
> проблема нарратива я уже назвал: диссонанс
А это вообще не совместимо. Слишком много терминологии, слишком мало смысла.
Ren
Я тебя опять не понимаю.
Ren
> Тогда как других игроков ты пытаешься заставить вникнуть в мельчайшие подробности ссоры между орком#756 и орком#344. На основании того что это якобы не скриптово.
ildarin
> Ren
> Я тебя опять не понимаю.
Кажется я тут понимаю. Рен хочет сказать, что нет никакой разницы, произошло ли событие скриптово или случайно, для игрока это ничем не отличается.
