Когда делали прототип Blood&Gold: Carribean! на движке Маунт-Блейда для того что бы не решать задачи поиска пути, контроля скорости и ввода «просто» заменяли модельку игрока и лошади (sic!) моделькой кораблика — так оно и ушло в релиз. Хє-хє :)
1. Читит. Но и ставка была не на АИ — он должен развлекать игрока, а на сетевую часть.
2. Это и не требуется. АИ регирует по зонам опасности — к примеру, деверсанты ищут путь с минимальным весом опасности, а армии наоборот ищут «опасность»
3. С++ пришлось изучить что бы адекватно читать код оригинальных козаков (я не совсем программист, а игровой дизайнер), так как в момент старта мы хотели что бы Казаки3 игрались точно так же как и оригинал. Сейчас правда баланс сильно поменялся.
С технической стороны движок располагает набором внутренних функций, базовых, очень похоже на то как работает «Монобехевиор» в Юнити, только наши скрипты, а это 99,9% всей игровой логики написаны в скриптах и компилируются в память в рантайме, а не транслируются по надобности. Дальше просто идёт обычный asm: jmp на функцию движка с передайчей хендла объекта.
Под мануалом имелся ввиду гугл для 101-го велосипеда который вы описали в дев. стори.
Ок, в статье не было ни слова про динамическую потологию карты для поиска пути, но писать свою реализацию? Я чего-то совсем не понимаю этого момента. Может быть пришлось писать оптимизацию? Тогда, да, статья на тему как делался поиск пути в игре Казаки в помощь (главный хинт — то что карта «своворачивается» в несколько «слоев», где каждый более высокий слой более крупный для «быстрого» поиска.
Относительно туторов — мне больше с# попадался, да и дев-стори от других компаний «почему мы сразу перешли на сишарп» — должен был навести на мысли ;)
на скринах не видно контролов, посему рискну предположить что кнопки были стандартно аки джойстик вертикально-горизонтально? Если так попробуйте сделать с наклоном в 45 как игровое поле и по ходу движения змеи протестировать — думаю будет хорошо
1) То что ДжаваСкрипт — костыль — писали сами разработчики Юнити с момента создания этого чудесного инструментария и уже в 2012-2013 в тырнетах были тонны вайна почему не стоит…
2) Проект на 20+ Гб и всё в ЮнитиАсетс?.. Прошу прощения, но кажется это уже проблема архитектуры. При всём кажущемся «могуществе» среды разработки — библиотечные вещи типа «списка текстур» и «списка иконок для спелов» — уже пора давно выносить в простые библиотеки которые можно править без пересборки проекта — следует научится разделять игровую логику и контент
3) А* на джва скрипт — когда родной пазфайндинг юнити не полное говно?.. После таких слов очень-очень хочется попросить взять паузу, трезво переосмыслить всё что было написано, оценить все за и против и только потом продолжать — иначе потом будет очень больно, поверь.
И да — больше гугла, велосипеды уже давно написаны, осталось их только правильно применить ;)
И вот почему после таких статей хочется зять и ткнуть носом в Read The Fucking Manual?!.. Сколько уже на момент старта работы над игрой было статей «как не надо делать игры» — чесс слово, половину хтонического ужаса удалось бы избежать…
ЗЫ: 10 лет уже делаю игры, так что курсе что и как :)
А чем не угодили обычные стролочки в углу для управления? Благо место на экране есть. Да и простор для редакции 2.0 есть — там кнопки с бустами для паравозика прицепить
2. Это и не требуется. АИ регирует по зонам опасности — к примеру, деверсанты ищут путь с минимальным весом опасности, а армии наоборот ищут «опасность»
3. С++ пришлось изучить что бы адекватно читать код оригинальных козаков (я не совсем программист, а игровой дизайнер), так как в момент старта мы хотели что бы Казаки3 игрались точно так же как и оригинал. Сейчас правда баланс сильно поменялся.
С технической стороны движок располагает набором внутренних функций, базовых, очень похоже на то как работает «Монобехевиор» в Юнити, только наши скрипты, а это 99,9% всей игровой логики написаны в скриптах и компилируются в память в рантайме, а не транслируются по надобности. Дальше просто идёт обычный asm: jmp на функцию движка с передайчей хендла объекта.
http://www.gamedev.ru/code/articles/PositionBasedPhysics#v_chyom_je_profit_
С виду простой метод возволяет моделировать вполне внушительное количество взаимодействующих объектов:
На этом просчитывается взаимодействие 5000 шариков, расчёт всей физики занимает чуть больше 2мс на одном ядре процессора Core2Duo E6600 2.4GHz.
Впрочем если скрость А* устраивает — то не стоит тратить на это силы и время.
Ок, в статье не было ни слова про динамическую потологию карты для поиска пути, но писать свою реализацию? Я чего-то совсем не понимаю этого момента. Может быть пришлось писать оптимизацию? Тогда, да, статья на тему как делался поиск пути в игре Казаки в помощь (главный хинт — то что карта «своворачивается» в несколько «слоев», где каждый более высокий слой более крупный для «быстрого» поиска.
Относительно туторов — мне больше с# попадался, да и дев-стори от других компаний «почему мы сразу перешли на сишарп» — должен был навести на мысли ;)
Могу просто сслыки на игры:
http://store.steampowered.com/app/48720/?l=russian
http://store.steampowered.com/app/333420/
1) То что ДжаваСкрипт — костыль — писали сами разработчики Юнити с момента создания этого чудесного инструментария и уже в 2012-2013 в тырнетах были тонны вайна почему не стоит…
2) Проект на 20+ Гб и всё в ЮнитиАсетс?.. Прошу прощения, но кажется это уже проблема архитектуры. При всём кажущемся «могуществе» среды разработки — библиотечные вещи типа «списка текстур» и «списка иконок для спелов» — уже пора давно выносить в простые библиотеки которые можно править без пересборки проекта — следует научится разделять игровую логику и контент
3) А* на джва скрипт — когда родной пазфайндинг юнити не полное говно?.. После таких слов очень-очень хочется попросить взять паузу, трезво переосмыслить всё что было написано, оценить все за и против и только потом продолжать — иначе потом будет очень больно, поверь.
И да — больше гугла, велосипеды уже давно написаны, осталось их только правильно применить ;)
ЗЫ: 10 лет уже делаю игры, так что курсе что и как :)