Читать интересно, но мне кажется больший акцент на процессе принятия решений (в т.ч. технических) было бы интереснее читать, чем про сами детали реализации.
Несколько заметок по поводу затеи в целом:
- Ментальность. Специалисту трудно выйти из зоны комфорта, когда нужно решать управленческие задачи. Когда в руках привычный молоток - видишь вокруг только гвозди. Программировать - привычно, понятно и интересно. А делать интересную игру - непонятно, непривычно и страшно (вдруг идея окажется неинтересной). В итоге, спустя месяцы выясняется, что лестница, на которую с таким энтузиазмом забирались, была приставлена не к той стене и получается, в лучшем случае, технологическая демка, но не игра. Outer Colony, как пример.
- Определиться с целью: хобби или коммерческая разработка. Если планируете выпустить демо в обозримом будущем и в перспективе - зарабатывать, то примеряйте на себя роль гейм-дизайнера \ продюсера в первую очередь.
- Начинать с геймплея. Почитайте про MDA framework, это задаст правильный настрой. Игроку важен игровой опыт (aesthetics в MDA), а технологии - это лишь инструменты для его создания. То, что вы перечислили - это пока набор механик, без привязки к опыту. Лично я так и не понял из двух статей: 1) в чем именно будет геймплей игры, 2) чем он будет значительно лучше референсов. На кладбище игр полно проектов с эпитафией "хотели сделать как референс". Например, Super Combat Fighter.
- Планы на демку - слишком оптимистичные, на полную версию - нереалистичные. По демке - если у вас по каждой задаче расписаны детали, вплоть до структур данных, алгоритмов и формул, то мб успеете к ноябрю впритык. По полной версии - fuzzy logic, NN - это возведение времени разработки в квадрат. Мультиплеер - в куб. Напрмер, в Project Zomboid два выделенных чувака (+аутсорсеры с недавнего времени) пилят вменяемый мультиплеер уже несколько лет и все не допилят.
Резюмируя, я бы рекомендовал вам переключиться в режим гейм-дизайнера, определить в чем будет геймплей, какой критичный функционал для него нужен (и вырезать все некритичное, например: анимацию, камеру, физику, аудио, меню), реализовать критичные механики максимально просто и быстро (в ущерб качеству \ технологиям, т.к. это прототип на выброс. Скажем, вместо GOAP - использовать FSM или decision tree на if'ках; вместо Astar сразу телепортировать в position) и выдать на растерзание толпе, чтобы проверить интересность идеи игры. А обратная связь от игроков уже подскажет, куда двигаться дальше.
Читать интересно, но мне кажется больший акцент на процессе принятия решений (в т.ч. технических) было бы интереснее читать, чем про сами детали реализации.
Несколько заметок по поводу затеи в целом:
- Ментальность. Специалисту трудно выйти из зоны комфорта, когда нужно решать управленческие задачи. Когда в руках привычный молоток - видишь вокруг только гвозди. Программировать - привычно, понятно и интересно. А делать интересную игру - непонятно, непривычно и страшно (вдруг идея окажется неинтересной). В итоге, спустя месяцы выясняется, что лестница, на которую с таким энтузиазмом забирались, была приставлена не к той стене и получается, в лучшем случае, технологическая демка, но не игра. Outer Colony, как пример.
- Определиться с целью: хобби или коммерческая разработка. Если планируете выпустить демо в обозримом будущем и в перспективе - зарабатывать, то примеряйте на себя роль гейм-дизайнера \ продюсера в первую очередь.
- Начинать с геймплея. Почитайте про MDA framework, это задаст правильный настрой. Игроку важен игровой опыт (aesthetics в MDA), а технологии - это лишь инструменты для его создания. То, что вы перечислили - это пока набор механик, без привязки к опыту. Лично я так и не понял из двух статей: 1) в чем именно будет геймплей игры, 2) чем он будет значительно лучше референсов. На кладбище игр полно проектов с эпитафией "хотели сделать как референс". Например, Super Combat Fighter.
- Планы на демку - слишком оптимистичные, на полную версию - нереалистичные. По демке - если у вас по каждой задаче расписаны детали, вплоть до структур данных, алгоритмов и формул, то мб успеете к ноябрю впритык. По полной версии - fuzzy logic, NN - это возведение времени разработки в квадрат. Мультиплеер - в куб. Напрмер, в Project Zomboid два выделенных чувака (+аутсорсеры с недавнего времени) пилят вменяемый мультиплеер уже несколько лет и все не допилят.
Резюмируя, я бы рекомендовал вам переключиться в режим гейм-дизайнера, определить в чем будет геймплей, какой критичный функционал для него нужен (и вырезать все некритичное, например: анимацию, камеру, физику, аудио, меню), реализовать критичные механики максимально просто и быстро (в ущерб качеству \ технологиям, т.к. это прототип на выброс. Скажем, вместо GOAP - использовать FSM или decision tree на if'ках; вместо Astar сразу телепортировать в position) и выдать на растерзание толпе, чтобы проверить интересность идеи игры. А обратная связь от игроков уже подскажет, куда двигаться дальше.