Было бы неплохо привести какие-то примеры кейсов, где такой способ будет полезен.
Вот делаем мы ААА-проект уровня RDR2 (у нас сразу и мультиплеер, и одиночная кампания). У нас команда в 1000 человек, а на встрече присутствуют Development Director, Art Director, Creative Director, Publishing Producer и CEO. Вместе они тратят весь день, чтобы обклеить все стены в переговорке всеми возможными событиями в игре и как-то договориться по каждому из них.
Выглядит так, что составление детальной документации по flow игрока - это задача геймдизайнеров, делается это не за одну встречу и занимает не одну схему, особенно если проект объемный.
Код всего класса RandomExtractor целиком приведён ниже.
Зачем так сложно? Кладём все сегменты в список, перемешиваем его и идём по списку возвращая сегменты по одному. Как дошли до конца - снова перемешиваем
IEnumerator getSegment<T>(T[] segments) {
List<T> segmentsList = new List<T>(segments);
while (true) {
shuffle(segmentsList);
foreach(T value in segmentsList)
yield return value;
}
}
...
// Получение случайного значения. Каждый вызов iterator.MoveNext()
// будет присваиваьит iterator.Current новое случайное значение
var iterator = getSegment<int>(new int[] { 1, 2, 3 });
iterator.MoveNext();
Debug.Log(iterator.Current);
В целом, если скорость движения игрока постоянна, то нам достаточно просто создавать новые сегменты каждые X секунд (например, через StartCoroutine), а не замерять расстояние в каждом апдейте. Если хотим ставить сегменты прям идеально - можно держать ссылку на последний созданный и спавнить новый в N метрах от него. Удаление - также: мы знаем скорость, а значит, знаем за какое время сегмент окажется за камерой и станет не нужен. Сразу после его создания вызываем Destroy() с этим временем.
Проблема фона легко решается скайбоксом. Тогда не нужен будет отдельный спрайт в конце. Скайбокс даже можно сгенерировать нейронкой, а не рисовать самому.
Примеры современного ИИ какие-то не сильно современные.
В "Gears Tactics" противники с ИИ действуют стратегически: каждый получает свою задачу от группового ИИ
Групповой ИИ - это просто бот, который командует другими ботами, как ИИ-оппонент в стратегиях. Такой был ещё в первом XCOM четверть века назад.
разработчики использовали систему навигационных полигонов, называемых navmesh. Они поделили эти полигоны на группы: синие зоны — легкий путь, жёлтые — немного сложнее, красные — самые сложные.
NavMesh - это стандартный инструмент ИИ-навигации, доступный в любом современном движке, от громадного UE, до крохотного Godot. Сама же навигация с весами - это, например, алгоритм А* 1968 года
Эх, и не упомянули ни одной большой и проработанной игры, в которые разработчики вкладывали душу и месяцы труда. Например, серии Epic Battle Fantasy, Sonny или Submachine.
И ни одного русскоязычного разработчика, а ведь было довольно большое комьюнити: форум, блоги. Люди неплохо зарабатывали на этих играх. Их работы довольно часто оказывались на первых страницах сайтов-агрегаторов, хоть в большинстве своём и не гремели на весь интернет. Из наиболее известных вспомнились Punks Not Dead, Zombotron, Intrusion. Samorost и Machinarium, вроде тоже на флеше. На закате технологии ещё была Don't Open the Doors.
В данном вопросе есть ещё один довольно важный аспект: найм новых сотрудников. Когда у вас своя сложная технология - движок целиком или какая-то крупная его часть (например, ИИ или физика) - вашим новым коллегам придётся потратить несколько месяцев только на то чтобы её изучить и войти в курс дела. И нужно будет приставить к новичку ментора-синьора, чтобы максимально ускорить этот процесс.
Кроме того, далеко не все кандидаты вообще захотят изучать in-house технологии, нужные только в одной конкретной компании. Большинство всё же предпочтёт распространённые Unity / UE, опыт на которых котируется больше. Чтобы компенсировать этот момент вам, возможно, придётся или предлагать более высокие зарплаты, или как-то иначе завлекать сотрудников.
А что если что ваш новый сотрудник уволится через полгода? Деньги на его обучение и время его ментора вы уже потратили, а ничего полезного для проекта он сделать не успел. Ещё и человека надо искать с нуля.
Ещё неприятный сайд эффект - джуны для вас становятся сильно дороже. Если инди-студия может взять студента с базовым знанием Юнити и он уже через месяц худо-бедно (зато недорого) будет приносить пользу, то порог вхождения в вашу технологию для него выше в разы, плюс время его ментора. И вот уже по стоимости джуны для вас приближаются к мидлам. Зато джуны хотя бы есть на рынке. Мидлов найти куда сложнее, а те что есть - не горят желанием к вам идти.
Было бы неплохо привести какие-то примеры кейсов, где такой способ будет полезен.
Вот делаем мы ААА-проект уровня RDR2 (у нас сразу и мультиплеер, и одиночная кампания). У нас команда в 1000 человек, а на встрече присутствуют Development Director, Art Director, Creative Director, Publishing Producer и CEO. Вместе они тратят весь день, чтобы обклеить все стены в переговорке всеми возможными событиями в игре и как-то договориться по каждому из них.
Выглядит так, что составление детальной документации по flow игрока - это задача геймдизайнеров, делается это не за одну встречу и занимает не одну схему, особенно если проект объемный.
Зачем так сложно? Кладём все сегменты в список, перемешиваем его и идём по списку возвращая сегменты по одному. Как дошли до конца - снова перемешиваем
Код функции shuffle можно найти например тут, там строк 10 от силы.
В целом, если скорость движения игрока постоянна, то нам достаточно просто создавать новые сегменты каждые X секунд (например, через StartCoroutine), а не замерять расстояние в каждом апдейте. Если хотим ставить сегменты прям идеально - можно держать ссылку на последний созданный и спавнить новый в N метрах от него. Удаление - также: мы знаем скорость, а значит, знаем за какое время сегмент окажется за камерой и станет не нужен. Сразу после его создания вызываем Destroy() с этим временем.
Проблема фона легко решается скайбоксом. Тогда не нужен будет отдельный спрайт в конце. Скайбокс даже можно сгенерировать нейронкой, а не рисовать самому.
Примеры современного ИИ какие-то не сильно современные.
Групповой ИИ - это просто бот, который командует другими ботами, как ИИ-оппонент в стратегиях. Такой был ещё в первом XCOM четверть века назад.
NavMesh - это стандартный инструмент ИИ-навигации, доступный в любом современном движке, от громадного UE, до крохотного Godot. Сама же навигация с весами - это, например, алгоритм А* 1968 года
Так хорошие же советы и рассуждения правильные. Тоже подпишусь под каждым абзацем.
А десятки проектов могут идти параллельно если автор ими руководит или менторит.
Кажется, помню Вас по форуму flashgamedev.ru. Вообще странно что при таких оценках так мало просмотров.
Да, отличное было время :D
Эх, и не упомянули ни одной большой и проработанной игры, в которые разработчики вкладывали душу и месяцы труда. Например, серии Epic Battle Fantasy, Sonny или Submachine.
И ни одного русскоязычного разработчика, а ведь было довольно большое комьюнити: форум, блоги. Люди неплохо зарабатывали на этих играх. Их работы довольно часто оказывались на первых страницах сайтов-агрегаторов, хоть в большинстве своём и не гремели на весь интернет. Из наиболее известных вспомнились Punks Not Dead, Zombotron, Intrusion. Samorost и Machinarium, вроде тоже на флеше. На закате технологии ещё была Don't Open the Doors.
В данном вопросе есть ещё один довольно важный аспект: найм новых сотрудников. Когда у вас своя сложная технология - движок целиком или какая-то крупная его часть (например, ИИ или физика) - вашим новым коллегам придётся потратить несколько месяцев только на то чтобы её изучить и войти в курс дела. И нужно будет приставить к новичку ментора-синьора, чтобы максимально ускорить этот процесс.
Кроме того, далеко не все кандидаты вообще захотят изучать in-house технологии, нужные только в одной конкретной компании. Большинство всё же предпочтёт распространённые Unity / UE, опыт на которых котируется больше. Чтобы компенсировать этот момент вам, возможно, придётся или предлагать более высокие зарплаты, или как-то иначе завлекать сотрудников.
А что если что ваш новый сотрудник уволится через полгода? Деньги на его обучение и время его ментора вы уже потратили, а ничего полезного для проекта он сделать не успел. Ещё и человека надо искать с нуля.
Ещё неприятный сайд эффект - джуны для вас становятся сильно дороже. Если инди-студия может взять студента с базовым знанием Юнити и он уже через месяц худо-бедно (зато недорого) будет приносить пользу, то порог вхождения в вашу технологию для него выше в разы, плюс время его ментора. И вот уже по стоимости джуны для вас приближаются к мидлам. Зато джуны хотя бы есть на рынке. Мидлов найти куда сложнее, а те что есть - не горят желанием к вам идти.