Графический API. Следущий переломный момент для меня наступил когда я посмотрел лекцию по WGPU. Тогда я понял что это именно те инструменты которые я искал и начал эксперименты. До этого у меня было представление что WebGPU это стандарт для веба. Оказывается это не совсем так. Несколько лет назад стандарт задумывался разработчиками браузеров именно как низкоуровневая альтернатива WebGL. Насколько я понял над WebGPU работают именно разработчики браузеров, и он никак не связан с Kronos. Изначально, библиотека WGPU создавалась для реализации стандарта WebGPU в FireFox, но позже Mozilla и Google стали поставлять свои реализации этого стандарта для нативных языков отдельно от браузера. У Google свой аналог WGPU называющийся Dawn, и в целом устроенный похожим образом, но реализованный на C++. По сути WGPU это очень тонкая низкоуровневая надстройка над графическими API вроде Vulkan, Metal и DX12 написаная на Расте с заголовками под Си. Вам дается есть очень явный доступ к графическим девайсам – очереди, пулы, буферы команд, дескрипторы, графические и вычислительные пайплайны, примитивы для синхронизации и вот это все. По сложности WGPU где-то посередине между Metal и DX12. Это почти 1-в-1 копия подхода низкоуровневых графических API, из отличий в нем упрощена работа с памятью, и требуется немного меньше кода. Главный плюс WGPU по это кроссплатформенность. В зависимости от системы (mac, pc, ios, android) можно указать разный backend – Vulkan, dx12 или metal. В расте многие библиотеки, в том числе bevy, поддерживают вывод через WGPU, поэтому их ресурсы можно переиспользовать как аттачменты в одном пайплайне без трансфера через CPU.
Читать интересно, но мне кажется больший акцент на процессе принятия решений (в т.ч. технических) было бы интереснее читать, чем про сами детали реализации.
Несколько заметок по поводу затеи в целом:
- Ментальность. Специалисту трудно выйти из зоны комфорта, когда нужно решать управленческие задачи. Когда в руках привычный молоток - видишь вокруг только гвозди. Программировать - привычно, понятно и интересно. А делать интересную игру - непонятно, непривычно и страшно (вдруг идея окажется неинтересной). В итоге, спустя месяцы выясняется, что лестница, на которую с таким энтузиазмом забирались, была приставлена не к той стене и получается, в лучшем случае, технологическая демка, но не игра. Outer Colony, как пример.
- Определиться с целью: хобби или коммерческая разработка. Если планируете выпустить демо в обозримом будущем и в перспективе - зарабатывать, то примеряйте на себя роль гейм-дизайнера \ продюсера в первую очередь.
- Начинать с геймплея. Почитайте про MDA framework, это задаст правильный настрой. Игроку важен игровой опыт (aesthetics в MDA), а технологии - это лишь инструменты для его создания. То, что вы перечислили - это пока набор механик, без привязки к опыту. Лично я так и не понял из двух статей: 1) в чем именно будет геймплей игры, 2) чем он будет значительно лучше референсов. На кладбище игр полно проектов с эпитафией "хотели сделать как референс". Например, Super Combat Fighter.
- Планы на демку - слишком оптимистичные, на полную версию - нереалистичные. По демке - если у вас по каждой задаче расписаны детали, вплоть до структур данных, алгоритмов и формул, то мб успеете к ноябрю впритык. По полной версии - fuzzy logic, NN - это возведение времени разработки в квадрат. Мультиплеер - в куб. Напрмер, в Project Zomboid два выделенных чувака (+аутсорсеры с недавнего времени) пилят вменяемый мультиплеер уже несколько лет и все не допилят.
Резюмируя, я бы рекомендовал вам переключиться в режим гейм-дизайнера, определить в чем будет геймплей, какой критичный функционал для него нужен (и вырезать все некритичное, например: анимацию, камеру, физику, аудио, меню), реализовать критичные механики максимально просто и быстро (в ущерб качеству \ технологиям, т.к. это прототип на выброс. Скажем, вместо GOAP - использовать FSM или decision tree на if'ках; вместо Astar сразу телепортировать в position) и выдать на растерзание толпе, чтобы проверить интересность идеи игры. А обратная связь от игроков уже подскажет, куда двигаться дальше.
Очень полезные советы, спасибо!
Помогу тебе своим комментарием. Подавляющему большинству пофиг как ты будешь добиваться целей. Показывай нам, что сделано будем активно оценивать и обсуждать. Видно, что ты человек опытный статья грамотная, но я устал читать эту заумь на скриншоте с противогазом. Задач набрал себе не мало, ведь даже игру игрой делать в одно лицо сложно, а ты еще и подменять своей работой "высокоуровневый" движок собрался. Не уверен, что успеешь до конца года, что-то похожее на игру сделать без движка.
Ты сказал Majestry это волшебное слово так как их давно не делали. Только допускаю, что в настоящее время разные команды их делают, без анонса.
Мне эта тема тоже очень нравится, я в одном из своих учебных упражнений по Unity делал сцену на примитивах в которой герои, стражники, монстры и налоговые инспектора делают свои дела. Герои исследуют, защищают, атакуют цели под флагами монстры просто крашат вся. Баблишко капает герои покупают бутылки, кольца защиты новые пушки и броню. Было прикольно и без анимации и без моделей. Поиск пути писал примитивный свой без NavMesh даже работало кое как у меня. Сейчас опыта поднабрался планирую когда то вернуться к этой теме если получится, но не в этом году.
Спасибо. Игра все же не прям совсем с нуля, и у меня есть надежда что выбранный уровень абстракции в моем случае даст больше продуктивности чем попытки адаптировать Unity или Godot под не совсем стандартный жанр (возможно я конечно не прав). Я только сейчас закончил работу над основными механиками и приступил к геймплею в прототипе. Следующие две-три статьи все же будут скорее техническими, но после этого я начну фокусироваться на публикции подробностей механик геймплея.
Как я уже писал в самом начале, в этих статьях я не ориентируюсь на широкую аудиторию, но за отзыв спасибо, постараюсь более интересно писать о технических деталях проекта.
заумьВроде бы наоборот дружелюбно написал, как настроил себе тулсет и почему он именно такой.
Очень интересно как разработчику, спасибо!
Есть небольшое ощущение, что ты попытался запихнуть все-все в одну статью. Очень много буллетпоинтов с кучей текста - такое наверно лучше делать заголовками подразделов. А по каждому такому подразделу я с удовольствием бы читал даже чуть более подробные статьи! А так, получается все самое интересное ты рассказал, а дальше рутина и никакого кликбейта)
Что ещё хочу заметить: то, что ты называешь прототипом - это будет прототип движка игры, а не прототип самого геймплея. Это даже не прототип, а какой-то PoC. "Да, я сделал игру на расте и webgpu". А что за игра, в чем ее кайф - не понятно даже после этого прототипа, он не проверяет гипотезы, он просто является кодом-основой для самой игры. Ну будет какая то симуляция человечков, которые что-то делают - я лучше пойду в римворлд играть, она уже готова и она классная) ну ты понял.
Опять же, это просто первые мысли. Я люблю технологии и с удовольствием бы читал тонны текста только про одни шейдеры, например. Я не спорю, что идеи у тебя есть там крутые - но вот о них, наверно, важнее всего в первую очередь говорить. Статьи о том, как ты реализуешь эти идеи (с техническими подробностями) я бы завал с ещё большим удовольствием! Ты сам пишешь "концепция и задачи прототипа" - концепции нет, задач нет. Есть жанр, стек, чек-лист движка. Задача твоего прототипа - просто иметь в себе сделанные технические фичи. Это плохая задача. Есть опасность выгореть и забить, так и не начав пилить геймплейные вещи, имхо.
А так, круто! Жду инфы по геймплею и более структурированной нудятины про раст и низкоуровневые графические апи.
Спасибо. Я это понимаю, отвечал на похожий комментарий в другом посте – думаю сначала статьи на более общие темы – ECS, графика, поиск пути и пр. То что нужно решить в первую очередь. Особенности геймплея это то над чем я постоянно экспериментирую в данный момент и планирую делать все больший фокус по мере готовности основных механик.
Я планирую об этом писать, но уже немного постфактум когда это будет готово и можно будет показывать результат.
Мне кажется симуляция и реализация мира где твои поселенцы дают квесты другим поселенцам это довольно необычно и добавляет глубины. Я начну об этом писать ближе к концу лета, надеюсь у меня будет интересные результаты к этому времени.