Видимо отдельную тему создавать пора, чую мы не успокоимся)
ЦитатаKamiRonin ()
"No Man's Sky" - воксели
Я конечно могу ошибаться, но по-моему там не будет возможности менять ландшафт, и воксели тогда там не нужны, а планеты генерируются продвинутым алгоритмом тесселяции из сфер, по заданным параметрам, и разумеется на лету, по мере приближения игрока к планете вплоть до мелких камушков на поверхности. Изучал я этот вопрос, действительно поразительная штука. И кстати на тему размера клиента, не думаю что он у них с миллиардами планет и тысячами представителей фауны, и прочего и прочего, будет весить сотни гигов Вот наглядная демонстрация плюсов генерации, уникального контента много, весу мало и не нужно много дублировать, только алгоритм генерации.
Про пару проектов, хм, как бы это по аккуратнее бы. Любой проект сделанный на движках Unity, Cry, UDK и многих других Везде где есть система префабов и расставление префаба по карте используется система генерации, при загрузке сцены этот объект генерируется в указанных координатах, и более того, любой вызов Instantiate в коде, тоже можно отнести к генерации. Вопрос лишь в том что можно пойти дальше, и генерировать объекты не по предварительно указанным дизайнером в редакторе координатам, а по определенному заданному правилу. И ещё дальше, объекты разбить на модули и генерировать их разными комбинациями (хотя юнька уже это делает, и каждый объект имеет разные компоненты определяющие его поведение), а потом и модули эти разбить на небольшие кирпичики и собирать различные вариации из них, и как квинтэссенция, кригер, где вообще обошлись без них, и генерируют всё из кода, и думаю меши хранят в нём же.
А мы, по-моему, спорим, лишь о разности подходов к расстановки объектов по миру и определению их свойств, заранее, ручками, в редакторе или по определённому алгоритму. И здесь есть близкая аналогия, что бы построить график функции, можно хранить на бумажке все координаты точек принадлежащих графику, и чем больше точек записать тем более точно можно построить сложные кривые, а можно просто записать функцию этой кривой и построить график по ней. И там и там есть свои плюсы, и для каждой ситуации лучше свой подход или комбинация подходов.
ЦитатаKamiRonin ()
2.5 млрд в американской валюте за игровую СТУДИЮ Mojang, а не игру, кстати)
У маджонгов помимо майнкрафта было что-то вроде ещё двух игр, про которые ни кто ничего в мире не слышал. На момент покупки в нём было около 14 человек, средне статистических работников, учитывая то, что сам Нотч и ещё один человек, который кстати Скролс делал ссылка на вики, которые с самого начала всё это затеяли, сразу после покупки из студии ушли (и при подписании контракта учитывалось, что они уйдут). Так что боюсь что 2,5 миллиарда это именно за майнкрафт, а если точнее, за лицензию на его сиквел, потому что сам видишь, в топе прибыльных онлайн игр его нет
Сообщение отредактировал BlackX - Суббота, 20 Декабря 2014, 13:56
Конечно, о нём родимом) В конце концов сколько стоит Скайрим и Сталкер, 100 миллионов? 500? Миллиард? А Майнкрафт 2,5 миллиарда в американской валюте)
А генерация штука всё равно крайне полезная, хоть и специфическая. Я твёрдо уверен, что за генерацией (не обязательно рандомной) будущее. Просто не научились ещё пользоваться ей полноценно, да мощностей вычислительных не хватало, но щас эта проблема уходит. И кстати самое яркое подтверждение моих слов "No Man's Sky" игра построенная на сгенерированном контенте, и что бы просмотреть весь уникальный контент, говорят необходимо несколько десятков лет реального времени (преувеличивают конечно как всегда, и считают все, даже самые минимальные отличия, но надеюсь смысл понятен). Она содержит несколько миллионов планет и каждая со своим ландшафтом, атмосферой, фауной и прочими спецификами.
А тот же MW3, если там одна машина 20 раз в сцене используется, то вероятно она не часть меша сцены, иначе бы их сделали бы поуникальней, и эти 20 копий создаются из эталона непосредственно при запуске сцены, а это и называется генерация Только не по какому-то алгоритму, а вероятно, по списку заданных точек, мол, при старте сцены, там, там, и вон там, создай вот эту машину. А можно было бы, например, сделать 3-4 вида колёс, и по тому же принципу раскидать по этим копиям машин, сделав их более разными, или например текстуры на них разные натянуть (хотя подозреваю это как раз делается, и машина эта, там встречается сильно больше раз, чем 20 ), причём натягивать текстуры именно на лету, что бы не хранить в билде несколько моделей машины отличающихся только цветом.
Просто нужно определять что делать заготовками, а что генерировать из кубиков, и размер этих самых кубиков, и чем они меньше, тем меньше весит билд и больше уникальных вещей можно из них построить, но дольше это будет загружаться сцена. И разумная комбинация этих двух подходов даёт сейчас самые лучшие результаты, и это сейчас мировая практика.
Но конечно, я знаю и о противоположных примерах, где генерация в мире вообще не используется, яркий представитель "RAGE", где все не интерактивные объекты, это часть одного огромного заготовленного разработчиками меша сцены, с натянутой на него всего, огромной, несколькогигобайтовой текстурой. Так что тоже имеет право на жизнь такой подход, по крайней мере пока
Но что-то меня опять понесло, и мы совсем отдалились от темы. И если есть желание буду рад перенести нашу дискуссию в личные сообщения. А тем временем решение найдено, называлось необходимое мне безобразие "паттерн пространственного разбиения" ссылку на английское описание которого здесь уже скинул OpenGOO, за что ему ещё раз спасибо. Русская версия этой же статьи. Там всё достаточно подробно описано с простыми примерами на С++ и ссылками на более развитые решения.
KamiRonin, не скажи, клиент содержащий набор кирпичиков несоизмеримо меньше клиента содержащий огромный список готовых объектов и уровней. Здесь нет необходимости хранить каждый кирпичик множество раз в каждом объекте, достаточно одного экземпляра каждого вида.
А на счёт скорости, ну так это взаимосвязь, либо скорость, либо объём. Либо хранишь, либо генерируешь.
P.S. Если у тебя кирпичиков на несколько гегибайт, до у тебя проблема с кирпичиками...
KamiRonin: Тут много специфики самой игры. Очень простой мир, грубо говоря это просто пространство с фоном, в котором существует множество динамичных объектов со своей логикой поведения. Не знаю, может это и есть то самое новое слово?) А вообще, и тут есть выход. То от чего я отказался, генерация мира по ключу) На сервере стоит генератор, и в каждом клиенте стоит генератор, дублируется только он, при подключении к серверу, он посылает клиенту ключ генерации имеющегося мира, и клиент у себя в памяти строит идентичную копию, и раскидывает в неё все статические объекты. А динамические объекты передаются клиенту по видимости.
Если не нужно что бы мир менялся, не надо менять ключ, и пусть каждый раз на клиентах строится одна и та же копия мира. Из минусов, нужно основательно подойти к вопросу генератора и сделать его достаточно качественным что бы результат удовлетворял всем критерии.
Вряд ли открыл Америку, но надеюсь дал пищу для размышлений)
Я для теста компилировал пустую сцену с одним векторным прямоугольником и простейшим контролером на нём, и в результате это весило для стенд элоун почти 20Мб. для андроида 12Мб, а для HTML5 68Кб, что больше походит на реальный вес.
Так что можно предположить сколько лишнего мусора он напихал в ПК сборку, без которого в принципе можно обойтись, а если использовать 3Д графику, шейдера к ней, графические пакеты и прочие навороты, ты мусора который, может нужен, а может и не нужен для конкретного проекта, будет ещё больше.
И конечно не забывай про оптимизацию моделей и ресурсов для игры, так-то у тебя одна модель персонажа может половину объявленного размера весить, и это не считая прочих фокусов, которые разрабы с переменным успехом побарывают, типа периодического удвоения вершин меша из-за вершин развёртки, и прочих интересных особенностей.
Ranger, ну ладно, да, обобщил при нормальной архитектуре проекта, почти вся.
Безмерно благодарен, вот чего мне для счастья не хватало, тем более что я готов реабилитироваться как пользователь гугла, и нашёл перевод этой книги на русском: Шаблоны игрового программирования.
Там рассматриваются весьма обобщённые случаи, на С++, и как я понимаю заточенные под UDK, и для юньки это нужно сильно адаптировать, но в принципе этого уже более чем достаточно, при наличии большого желания) Безмерно благодарен)
Касательно веса, да, Юнька очень много мусора в билд засовывает, вся папка асетс в твой проект входит целиком, и ещё куча дополнительных файлов из системных библиотек, и многого другого, и так с ходу не скажу, возможно ли его вообще почистить. Проверь сборку для ПК классического, размер должен быть примерно таким же, для мобильников поменьше, минимальный вес на HTML5 там измерятся даже килобайтами может пустой проект. Так что вес это нормально, по крайней мере для обычного пользователя.
А на счёт СДК, такое с ней часто бывает, и самая распространенная проблема, что кое кто, скачал 64х-битную версию СДК, для 32х-битной, версии Юньки, у неё вроде 64 нет ещё, только собираются сделать, не помню, в любом случае, половина этих проблем решается скачкой правильной версии.
Уххх, сходил, называется, на работу... Итак, по порядку: To Ranger: Несколько тысяч объектов не в видимости игрока, а в мире, и да, весь мир, это одна сцена (в идеале, хотя скорее всего без разбиения не обойтись, но посмотрим). И да они все существуют вне зависимости видит их игрок или нет, кстати игра мультиплеерная, и с живым функционирующим миром и "экосистемой" которая может функционировать и без иргоков, ради чего собственно и весь гемор.
Да, отчасти как в Сталкере, и собственно в чём проблема, отрисовывать их всех в одном кадре конечно не буду, даже создание разведено по времени, и плавно наращивает количество управляемых ИИ персонажей и прочих объектов до заданного и поддерживаемого значения, с нижних уровней, и поднимаясь плавно выше. И я не собираюсь обрабатывать физику взаимодействия между ними, но согласись, что бы хотя бы бросить кубики, нужно определить кто с кем сравнивается, а значит кто-то на кого-то должен напасть, а значит, этот кто-то должен знать что рядом находится кто-то другой. И для решения этого вопроса я и ищу, как тут подсказывают "Алгоритм восприятия окружения", или иную систему дающую подобный функционал. И я, в принципе, не понимаю, почему эта задача такая редкая, любой не заскриптованный на игроке ИИ должен её ставить вопрос её решения, а я ни чего в интернетах найти не могу(
Кстати безмерно благодарен KamiRonin, обязательно поищу.
А вариантов её решения как всегда, несколько, первый: дискретное пространство, это я даже вроде придумал как реализовать, здравствуй наследование классов, и класс родитель который содержит всё взаимодействие с табличей пространства, и от которого наследуют логику все поведенческие скрипты игры. Но опять же не без боя, внезапно осознал что в каждой ячейки массива находится список всех находящихся внутри объектов, куда можно быстро записать и выписать любой объект, и безразмерный лист для этой цели крайне медлителен, а размерный массив имеет сложности, сейчас думаю над одной переменной типа стринг с ключевыми символами после которых идёт ID объекта.
Второй внешний менеджер который знает о местоположении всех объектов ииии, видимо ежесекундно просчитывает расстояние между ними всеми, или делит пространство на определённые зоны, и смотрит кто в этой зоне находится и они все взаимодействуют, не знаю, этот вариант не продумывал.
Третий, он же сейчас, "План Б": Так как игра мульплеерная, и весь мир будет считаться на сервере, сделать его не на юньке, а на С++, обойдя все ограничения всех движков, и упершись лишь в вычислительные мощности серверной машины, которые планируются весьма выдающимися и уже заложены в бюджет...
P.S. OpenGOO От юньки отказаться не могу, ибо это 16 платформ, и да, в идеалистических планах, кроссплатформенный мультиплеер на 10-14 платформ и всё это на одном сервере и в огромном мире, который единая сцена, как на сервере так и у всех игроков) Но это уже, как говорится, на правах грёз и рекламы)
И да, устаёт, это вторая причина по которой отказался от колайдеров, про версия выдаёт 15 фпс уже на 7 тысячах. Но в принципе на первых парах думаю 5 000 мне более чем хватит) А там посмотрим, либо обработку всех невидимых объектов за движок вынесу, либо буду искать как можно это ограничение обойти ибо ресурсов вычислительных предполагается много, на крайняк переступлю себя, и забью на полностью живой, независимый от игрока(ов) мир), но это последнее решение.
Иии, пока никаким образом не делаю, вот это и спрашиваю, как его можно эргономично делать, слышал про описанный метод, вроде всё логично, но много вопросов по занесению и изменению данных в ячейке, туманно представляю себе мастер-класс, который будет этим заниматься, и к которому в конечном итоге будут принадлежать все поведенчесские классы игры, но поподробнее бы про решение почитать, а я даже не знаю как оно называется, как проблематику обозвать, по моим запросам ничего не находит.
Добре всем. Уже всю голову сломал различными вариантами, и поэтому уже мало что соображаю, так что не обессудьте.
Пишу ИИ для игры, вернее пытаюсь писать. Сама система принятия решений в принципе есть, а вот системы ввода исходных данных в неё нет. Задача не сложна: рассказать объекту в мире, какие объекты находятся вокруг него, в определённом радиусе. С единственным условием, таких объектов, собирающих информацию обо всём вокруг в реалтайме, одновременно существует, до нескольких тысяч.
Может подскажите что-то дельное, перебирать каждым объектом каждый очевидно нельзя. Пробовал вешать коллайдеры тригерные, и записывать через он тригер энтер и удалять через ексит, проблема пришла откуда не ждали, при уничтожении объекта внутри тригера, ОнтриггерЭксит не вызывается. Пробовал стрелять рейкастами по сторонам, с системой разводки по времени, но это уже крик души.
Слышал про "решение белых людей распространённой проблемы" про дробление пространства на ячейки и хранение в них списка находящихся в ячейке объектов. И в реалтайме объект просто проверяет свою и соседние ячейки и формирует список объектов. Но всё это очень мельком, и даже не знаю как подобное решение называется. Что забивать в поисковик. Голова уже не варит, и ничего умнее чем прибежать на форум к завершению дня я уже видимо придумать не могу.
Хоть обучающую литературку по теме посоветуйте, крайне желательно на русском. Или на краяйняк скажите как эта "известная проблема" называется, и какой алгоритм искать и под юньку пытаться адаптировать.
Да, последнее, игра 2Д, и никаких препятствий видимости нет, препятствия большие, а радиус обзора относительно маленький, так что это можно не учитывать.
BlackX, с аватаром у нас аналогично, но гта - это святое!
А для меня после разочарования 4 части ничего святого в ней нет( Судя по роликам в пятой RockStars осознали все нюансы и поспешили исправиться, но для меня мир уже всё равно никогда не станет прежним)