>>0991
res://
│
├── assets/ # Внешние ресурсы
│ ├── sprites/ # Спрайты и изображения
│ │ ├── characters/ # Спрайты персонажей
│ │ ├── environment/ # Спрайты окружения
│ │ └── items/ # Спрайты предметов
│ ├── animations/ # Анимации (например, .anim файлов)
│ ├── sounds/ # Звуковые эффекты и музыка
│ ├── fonts/ # Шрифты
│ └── tilesets/ # Тайлы и тайлсеты для уровней
│
├── scenes/ # Игровые сцены
│ ├── main/ # Главные сцены (например, основное меню, игра)
│ ├── characters/ # Сцены персонажей (Player, NPC)
│ ├── environment/ # Сцены окружения (уровни, фоны)
│ ├── ui/ # Сцены интерфейса
│ └── items/ # Сцены предметов (если предметы имеют свою логику)
│
├── scripts/ # Скрипты
│ ├── global/ # Глобальные скрипты (менеджеры, утилиты и т.д.)
│ ├── characters/ # Скрипты персонажей
│ ├── environment/ # Скрипты окружения
│ ├── ui/ # Скрипты интерфейса
│ └── items/ # Скрипты предметов
│
├── resources/ # Ресурсы Godot (например, .tres и .res файлы)
│ ├── materials/ # Материалы (если используются)
│ ├── shaders/ # Шейдеры (если используются)
│ └── prefabs/ # Префабы (готовые компоненты для переиспользования)
│
├── ui/ # Интерфейсы (помимо сцен)
│ ├── themes/ # Темы интерфейса
│ └── widgets/ # Отдельные виджеты и элементы UI
│
├── addons/ # Плагины Godot и сторонние аддоны
│
└── project.godot # Файл конфигурации проекта

>>1314

>заморачивался готовя самодостаточные сцены - чтобы все их настройки устанавливались через экспорт-переменные

Да, так и надо делать с кастомными объектами.

>Надо поменять материал меша? Ставлю на родителя экспорт переменную и херачу код, устанавливающий ребенку новый материал.

Это имеет смысл если тебе часто нужно назначать материал снаружи. Однако, лучшим решением будет полностью абстрагироваться от концепции материалов, например, устанавливать не материал, а "тип персонажа", чтобы объект мог сам выбрать, какой материал ему нужен. Если ты явно кидаешь в него материал вместо назначения абстрактного "типа", ты по сути лезешь в чужую реализацию, создавая лишнюю зависимость от чужой реализации. У объекта должна быть подвижная ручка "выбрать тип" с делениями и подписями, а не пустая дырка для материала.

>Теперь я забил на это, добавляю сцену на уровень, включаю Editable Children, меняю что надо, группирую ноды через Ctrl+G чтобы случайно не выбрать ребенка вместо родителя, сворачиваю и еду дальше. Пока подводных не вижу.

Подводные:
1. Редактирование исходника вставленной сцены нарушает работу использующей сцены, поскольку она лезет в чужие кишки и зависима от них. Можно сломать так, что просто перечеркнёшь несколько часов работы независимо от того, есть у тебя гит/бекап или нет. Сам Godot может иногда спотыкаться при сложных манипуляциях в таких сценах.
2. Ты превращаешь сцены в тугой клубок лапши, которую тяжело понять, распутать и отладить, а потому становится сложнее расширять и поддерживать. По сути, так ты противоречишь основам ООП (объектно ориентированного проектирования), возвращаясь к неуправляемой лапше.
3. Сцены, в теории, грузятся дольше, т.к. ограничивается возможность переиспользования ресурсов в памяти. Вместо десятка одинаковых бойцов с разными enum в экспорте и одинаковым набором ресурсов внутри у тебя десяток частично независимых фрагментов сцены с кучей рандомных настроек в разных местах. Даже если нет ощутимой разницы, Godot по своей философии заточен на максимальное переиспользование всего, что можно. Фича с редактированием потомков такая же опасная, как доступ к рандомным нодам через get_node(), "синглтоны" и т.п. - они есть, но не предназначены для обмазывания проекта с ног до головы, т.к. нарушают базу ООП.

>>1335

>Но пока не встречал.

А я встречал несколько раз такое:
- есть сцена А с десятком нод, ничего особо сложного;
- есть сцена Б, использующая сцену А, немного сложнее;
- в сцене Б добавлены ноды к внутренним нодам сцены А;
- по какой-либо причине ноды в сцене А как-то меняются.
Что должно произойти, как думаешь? Интуиция подсказывает, что движок должен сохранить содержимое Б без изменений, даже если сцена А изменилась (т.к. ты видишь содержимое из А внутри Б, как будто это копия, но это не копия). Но на практике у меня движок просто-напросто игнорировал часть нод сцены Б, просто перечёркивая работу, будто бы её и не было совсем. Особенно обидно если это обновление произошло после реимпорта 3D модели, к костям которой я что-то прицепил через ноду RemoteTransform3D. Как минимум один раз мне пришлось доставать из архива старую версию этих сцен, чтобы перенести утраченные ноды из старой версии Б в "новую" версию Б, хотя изменения на самом деле касались только сцены А.

Легко представить, как ты можешь просто не заметить такой косяк, если у тебя большие сцены и ты не пересматриваешь их все после каждого изменения. Вот взял, изменил какую-то сцену, запустил игру - вроде всё работает, ошибок нет, но ВНЕЗАПНО что-то не так: кучки нод просто не существует. Начнёшь вслепую перекапывать сцены в поиске того, что ты потерял и почему. А как найти то, чего нет? Если не помнишь наизусть, что и где должно быть, придётся сверять со старой версией проекта. Лично я гитом не пользуюсь, но вряд ли сравнение текстовых файлов облегчит поиск, потому что в текстовом виде tscn слишком запутанные, и не факт, что эта "потеря нод" вообще видна в сцене Б, если ты её не сохранял (а вот если уже сохранил - тогда, вроде, ноды исчезают уже из файла), а изменения в сцене А не являются ошибочными (с точки зрения самой сцены А ошибки нет).

Честно, не знаю, баг это или нет, пофиксили уже или нет, и можно ли пофиксить. Однако эти грабли заставили меня избегать фичи "редактировать внутренние ноды". Лучше я потрачу больше времени на планирование сцены А, чем костылить что-то в рамках сцены Б, потом случайно/необдуманно менять сцену А и терять работу в Б, о которой я уже даже забыл.

>таких изменений много, в разных сценах, но каждое из них нужно один, ну максимум два раза

Звучит не очень. Можешь привести примеры таких ситуаций?

>хуже чем лапша, ощущается будто в супе тонешь

В чём "суп"-то? Смысл как раз в том, чтобы разделить проект на независимые компоненты, разложенные по уровням абстракции - они не смешаны в одной миске, а аккуратно разложены по блюдам - бери что хочешь, в каком угодно порядке. Движок даёт тебе ноды - это самый низкий уровень абстракции, как базовые ингредиенты. Из нод ты должен сделать сцены, которые описывают какие-то игровые сущности - бутерброды. Из этих сцен - сущности более высокого уровня - тарелки с бутербродами разных видов. Если ты хорошо спланировал разделение, то изменение сущностей низкого уровня не должно повлиять на сущности высокого уровня (и наоборот). Тарелка не должна внезапно взрываться и отравлять всех окружающих угарным газом, если ты заменил колбасу на сыр или поменял сорт хлеба булочки.

Например, ты сделал монетку, разметил её копии по сцене уровня, а у одной из копий сделал стоимость 25 вместо 5 (требует замены текстуры в одной из внутренних нод); далее ты решил, что монетка должна иметь анимированный спрайт вместо статичного - это изменение монетки не должно приводить в негодность сцену уровня, не должно влиять на поведение монетки со стоимостью 25. В твоём случае, ты как минимум рискуешь пропустить отсутствие правильной текстуры у монетки со стоимостью 25, т.к. движок сбросил её кастомизацию из-за изменения внутренностей её сцены. Чтобы этого избежать, тебе нужно поле, в котором можно ввести или выбрать сумму, а уже сама монетка выберет себе подходящую текстуру или анимацию - тогда вне зависимости от изменений монетки сцена с монетками не пострадает (до тех пор, пока ты не изменишь само поле "стоимость монетки", но это нарушает интерфейс объекта, чего следует избегать, в отличие от изменений внутренней реализации). Даже если у тебя во всей игре сейчас всего одна монетка со стоимостью 25, это не значит, что в будущем не будет связанных с ней изменений. А если ты забудешь, где она и что с ней (а ты забудешь) - рискуешь выкатить патч игры, в котором ты сделал всего лишь косметическое изменение, которое могло бы остаться незамеченным или за которое ты ожидал похвалу, но игроки теперь не могут пройти игру из-за сломанной монетки на одном из поздних уровней и жалуются на абстрактную "багованность", потому что им лень перечислять все баги, где и как они их нашли и т.д.

_{^{всё-всё, ухожу прикручивать мультиплеер к кнопке}}

>>1765

>а обращаться через HTTP запросы к какому-нибудь простому готовому серверу типа ollama или llamafile.

В llama.cpp и так лежит http сервер: ./llama-server. Но, имхо, пайпы ничем не сложнее, а даже проще, линукс вэй и все дела. Запустил процесс и общаешься с ним, это даже меньше требует чем писать хттп клиент.

>Чтобы игрок с NPC мог разговаривать?

Я не эксперт в нейронках, но по опыту с гопотой, пофиг на файнтюн, можно много контекста загнать в промпт. В принципе, это же умножение входа на веса, P x M, так что тут можно считать, что данные могут быть как в весах, так и в промпте, от перемены мест условно результат то на то и выйдет.

> заточка всех этих моделей на "послушного ИИ-ассистента" никак не помогает, а только вредит, если ты хочешь кого-то кроме "помощника".

А, тут такой момент, в моем посте ссылки на модели с припиской -instruct. Это модели которые файнтюнили примерами "запрос? ответ" поверх базовой модели. А значит, можно и сами сырые модели использовать, или их -chat вариант.

>А что именно ты хотел сделать?

Просто поэкспериментировать. Например, команды для RTS. У меня была идея, что llm может генерить код по произвольной текстовой команде. Например, выбрать всех юнитов-стрелков. Или юнитов в красных беретах. Но код генерится долго и ненадежно. У одного чувака видел на хабре пример, как он генерит json команды. Сообщает в контексте какие есть поля, и нейронка генерит команду. Или у другого дядьки был пример генерации sql запроса из текста. А можно и дальше пойти, тут был старый тред где предлагали сделать эмерджентную ртс. То есть и сами способности и аттрибуты юнитов можно создавать нейронкой по описанию, а потом ими управлять. "Создай технологию тяжелых юнитов (+ в промпт идет контекст игры - какие уже есть юниты, какие могут быть технологии, требование соблюдать баланс)" - и она выдаст что то вроде "слонопотамы с пусковой установкой кристалбомб".
Вторая идея - концепция "бога-гейммастера". Это нечто, запускающееся периодично, например раз в 1-5 минут, и пытающееся понять, что вообще за ситуация, как ее можно описать. Например, игрок пишет команды "пойду в магазин и куплю удобрения". "Пойду в строительный и куплю металлических ведер". Нейронка может описать что он готовится выращивать овощи на ферме. Или может оценить что он планирует восстание. И двигать дальше сюжет в таком направлении.

>>1836

>не будь ЧСВшным дауном

Как будто можно просто взять и измениться.

>не мешай ему, а даже подсматривай и учись.

Так ты поставь себя на его место. Ты несколько лет занимался проектом в одиночку. Выработал некую систему, привык к ней, она как продолжение тебя. И окружающие тебя хвалят, дают деньги. Приходит посторонний человек и кромсает твою систему на мелкие кусочки, делает что-то непонятное, по факту отбирает у тебя контроль за проектом, теперь любые изменения нужно с ним согласовывать. Негативные эмоции в такой ситуации более чем естественны. Но это не отменяет того факта, что твоя система - говно, серьёзно замедляющее разработку всего проекта.

>>1835

>мегапопулярный андертейл

Это из серии "так плохо, что уже хорошо". От какой-то стилизованной под древнее однобитное ретро игры многого не ожидаешь, работает и ладно. А Яндере замахивается на АААА симулятор школьной резни.

Суть в том, что если ты замахнулся на что-то хорошее, делай это хорошо. Если тебе лишь бы что-то высрать (игры с джемов, ассетфлипы) - тогда вопросов нет. В любой непонятной ситуации сначала лепишь из говна и палок прототип, выбрасываешь его, лепишь другой, третий, десятый. Но это не игры, к ним вопросов нет.

Ошибка ЯндереДева и ему подобных в том, что он на протяжении нескольких лет мял в руках прототипа кусок, а не разрабатывал полноценную игру. Вот и не делайте так. Слепили прототип, выбросили, делаете нормальную игру по всем правилам проектирования.

>>1838

>поведение фриковое

>не будь фриком

Да он обычный комнатный сыч по поведению. Или хочешь сказать, что в /gd/ все поголовно нормисы?

>не потому что код говно

Всё-таки говнокод сыграл свою роль. Полагаю, он затягивал с обновлениями не сознательно, а просто потому что добавлять новый контент тупо сложно, когда у тебя портянка ифов на десятки тысяч строк. Если бы он быстро разрабатывал игру, выполняя обещанное в срок, всем было бы глубоко насрать, какой он там по жизни человек. Народ ждал от него контента, а получил только отсрочки, отговорки и бесполезные побочные свистелки с перделками, которые банально проще вставить в говнокод.

Сравни, например, с Dwarf Fortress.
1. Никто не осуждает за длительность разработки, наоборот, хвалят за то, что не бросают проект.
2. Никто не обсуждает проблемы в их коде (глобально на весь интернет, высмеивая портянки ифов так, что Ютуб в рекомендациях выдаёт).
3. Никто не обсуждает их личности (глобально).
Почему? Потому что они доставляют обещанный контент. Я не знаю, как у них с кодом, но наверняка всё хорошо, раз удаётся стабильно поддерживать разработку столько лет. Говнокодер так бы не смог.

Или взять тот же Godot. Всего 1.5 шиза хейтят его из-за личной вражды с Хуаном, а в остальном движок хорош, потому что продолжает доставлять контент - в данном случае новые фичи, исправление багов, юзабилити. А %другойдвижок% топчется на месте и теряет юзеров, почему? Навалили говнокода и погрязли в нём (а кто конкретно виноват - СЕО или ещё кто - не суть важно).

Вывод: качество кода важно (в важном проекте).

>>1773

>ради пиара стоит говорить что там нейронка, ИИ, самообучение, ЛЛМ и прочие модные слова.

Сейчас так не стоит делать. Generative AI вызывает животную ярость в некоторых обезьянах, особенно у рисовак и им сочувствующих. Steam требует от тебя объяснить подробно, как ты используешь "ИИ", иначе забанить игру могут, как и в случае с 18+ контентом.

Как и с 18+, в загон с ИИ стоит заходить только если действительно есть что показать. Иначе ты себе и видимость снижаешь, и ЦА свою не интересуешь.

>В вашем случае пикрил - идеальное решение.

Ты не понимаешь, на if-else разговорный ИИ делать чрезвычайно сложно. Почему у большинства игр - линейный сюжет без развилок, с псевдовыбором

>Согласен!

>Ладно, уговорил.

>(Просто кивнуть головой)

>(Молчание означает согласие)

? Почему даже в AAA RPG NPC ведут себя как тупые таблички с надписями, выдающие всего 2-3 фразы? Почему квесты - это "принеси 10 шкур волков"? И т.д.

Раньше было много разных попыток добавить в игру разговоры с NPC в произвольном формате. Однако, обычно это сводилось к поиску ключевых слов - если удалось угадать/узнать ключевое слово - получишь дополнительную реплику от NPC, что может помочь в прохождении какого-то квеста. Нормально общаться, а тем более заводить отношения не получалось.

Нейросети в теории могут с этим помочь. Что такое нейросеть? Это способ аппроксимации неизвестных функций. Мы знаем, что для того, чтобы ответить на заданную фразу нужно выполнить какую-то сложную функцию, которую выполняет наш мозг. Мозг, грубо, содержит миллиарды if-else, и мы не можем вручную повторить сколь-либо существенную часть из них. А нейросеть может приблизиться к некой упрощённой версии этой функции, сделать грубую модель того, что генерирует правильный ответ на запрос.

Практическая разница в том, что когда пишешь if-else вручную, ты своим мозгом создаёшь грубую модель некоторой сложной системы. Эта модель работает без примеров, сразу, как будет написана. Нейросети нужно предоставить примеры того, что ты хочешь получить - примеры сами по себе содержат в себе какую-то информацию о том, как их создавать, и нейросеть способна создать грубую модель системы за тебя. Выгодно это тем, что ты можешь создать миллионы виртуальных if-else автоматически, просто собрав достаточно примеров ввода-вывода. А дальше, если получится правильная модель, она сможет тебе генерировать что-то новое точно так же, как вручную написанные if-else, только теперь их миллионы, а не несколько десятков на каждую тысячу строк кода.

>>1791

>В llama.cpp и так лежит http сервер

Не знал. Я думал, llama-cpp - это только библиотека, которую нужно подключать, а "запустить" нельзя.

>линукс вэй и все дела

На Windows что делать будешь? На Android? С HTTP ты можешь скинуть нейронку на другой компьютер.

>это даже меньше требует чем писать хттп клиент

В Godot HTTP запросы очень легко делать:
https://docs.godotengine.org/en/stable/tutorials/networking/http_request_class.html
Суть в том, чтоб не возиться с низкоуровневыми API, а просто кинуть запрос и получить ответ. Потом, если получится что-то годное, переделать легко. Чтоб сфокусироваться на высокоуровневых абстракциях.

>по опыту с гопотой

ChatGPT? У него сотни миллиардов параметров.

>пофиг на файнтюн, можно много контекста загнать в промпт

Без файнтюна нейронке сложнее правильно отвечать, особенно если она "маленькая" (tinyllama). Из личного опыта и какой-то статьи, даже большие (70b+) могут игнорировать инфу из промпта и выдумывать своё. А у маленьких ещё и контекст мизерный: чем больше ты накидал инфы в промпт, тем меньше контекста на связное общение с игроком (цепочка сообщений).

>данные могут быть как в весах, так и в промпте

Как показывает практика - промпта недостаточно.

>модели с припиской -instruct. Это модели которые файнтюнили примерами "запрос? ответ" поверх базовой модели. А значит, можно и сами сырые модели использовать, или их -chat вариант.

Базовые модели - просто "предсказатель текста". И если твой текст не похож ни на что в интернете (или моделька маленькая и не знает ничего похожего), нормального предсказания от неё не получишь.

Кумеры из /ai/ не зря ищут файнтюны на эротику и ролевую игру. Потому что без файнтюна, даже если модель не отказывается от запроса, она просто не понимает, что от неё требуется, и никаким промптом нормально объяснить не получится. Если тебе нужен правдоподобный персонаж, а не бесформенная куча, слепленная из тысяч персонажей - тем более.

>команды для RTS

>выбрать всех юнитов-стрелков

Суть RTS примерно как у шутеров: скорость реакции важнее стратегического мышления. Пока ты вводишь текстовые или пусть даже голосовые команды, любой достойный игрок в RTS выиграет бой одной мышкой. Синглплеер? Разве что для инвалидов на приставках, которым неудобно мышкой выделять юнитов. Просто такие команды лишают игрока контроля над игрой.

>сами способности и аттрибуты юнитов можно создавать нейронкой по описанию

А как игра будет их интерпретировать? Сначала тебе необходимо разработать игру, в которой возможно создание произвольных юнитов. А потом уже как-то генерировать описание юнитов. Даже в полностью текстовой игре от простого текста толку мало.

>требование соблюдать баланс

С этим LLM могут справиться только на уровне "ну да, нужен какой-то баланс, делай". Они даже на простых математических задачах ломаются, а нужно что-то уровня таблиц с тысячами параметров в формулах. Однако, если делать свою нейронку, в теории баланс можно регулировать с её помощью (если сможешь сформулировать, что такое баланс конкретной игры).

>технологию тяжелых юнитов

>и она выдаст что то вроде "слонопотамы с пусковой установкой кристалбомб"

Хрень какая-то, уровня кнопки "сделать случайного персонажа" в редакторе персонажей. Условный Spore привлекателен тем, что ты сам своих слонопотамов сделать можешь и потом ими управлять, а не тупой генератор тебе выдаёт какую-то рандомную фигню...

>Например, игрок пишет команды "пойду в магазин и куплю удобрения". "Пойду в строительный и куплю металлических ведер". Нейронка может описать что он готовится выращивать овощи на ферме. Или может оценить что он планирует восстание. И двигать дальше сюжет в таком направлении.

Вообще не понял. В чём игра заключается? Это чисто текстовая игра (без графики, физики и т.п.)? Если это чисто текстовая игра, то движок тут не нужен, LLM выполняет роль игрового движка (с горем пополам). А если у тебя 2D/3D игра, то куда игрок вводит эти команды и как твоя игра поймёт решение LLM?

Главная проблема тут в том, что ты переносишь на обученную кем-то другим нейронку ответственность за играбельность твоей игры. Если вдруг эта нейронка ломается на чём-то в твоей игре - что будешь делать? Откажешься от фичи в игре, или разведёшь руками и скажешь, чтоб игроки терпели баг? Редактированием промпта ты можешь случайно что-то другое сломать, а проверить это сложно. Это, кстати, одна из причин критики LLM: внутри может быть "спрятано" нечто "спящее", вызываемое определённым запросом. В игре это может вести критическим багам.

Конечно, самодельная нейронка тоже не полностью безопасна... Но над ней ты имеешь больше контроля - легче будет что-то исправить. В т.ч. файнтюном - по отзывам игроков, например, как в тех же чатботах, либо по собранной статистике игровых сессий. Тоже преимущество нейросетей - вместо попыток лично разобраться в тысячах if-else, просто кидаешь статы прошедших сессий с оценкой "делай так" или "больше такого не делай" и нейронка подстраивается под это, улучшая игровой опыт для всех игроков. Геймдев 2.0, впрочем, у больших дядь такое 100% было уже давно.

А если удастся учить нейронку в рантайме игры - возможно создать 100% персональный опыт. Для какого-нибудь симулятора свиданий крайне важная функция, чтоб игрок чувствовал связь с персонажем, а не гонял по захардкоженным сюжетным веткам, подробно описанным в интернете, так что в игру бессмысленно играть, прочитав фанатскую wiki. По сравнению с классической процедурной генерацией потенциал у такой игры значительно выше. Впрочем, самообучающиеся в рантайме NPC были ещё в 90-х.

>>2030

>Не люблю ответственность.

Ты в любом случае несёшь ответственность за свою игру перед игроками. Если твоя игра - нерабочий клубок багов, можешь сколько угодно оправдываться тем, что это чужая нейронка виновата - ты в любом случае выкатил нерабочий клубок багов. И игроки будут занижать оценки твоей игры, а не какой-то там облачной нейронки. Наглядных примеров полно: игра ломается из-за какой-то там технологии от третьих лиц, а игроки поливают говном разработчика игры, который использовал эту технологию от третьих лиц.

>>2025

>динамическое поддержание баланса

Т.е. 50% побед? Только начинаешь уверенно побеждать, как игра специально бросает тебя в непроходимые для тебя условия и ты проигрываешь. А если не забросишь игру с горящей жопой после десятка поражений подряд, игра сжалится и даст тебе победить, специально выбрав унизительно лёгкие условия для твоей победы. Такого баланса в играх предостаточно и без нейросетей.

>>1980

>Уже работают в етом направлении

Там нейронка выучила дум наизусть после огромного количества часов игры в оригинальный дум. И тратит на симуляцию намного больше оригинала. Таким тупым способом новую игру не сделать.

>>1951

>она будет придумывать подходящие юниты.

Ещё раз, как твоя игра будет реализовать все эти придуманные нейронкой юниты? Мы о сегодняшних возможностях говорим (в контексте Godot), а не о гипотетической волшебной кнопке "сделай игру".

>>1948

>В реале как раз командир задает общую канву и формулирует четкие приказы, а не бегает руко водить каждого по одиночке.

В реале у командира свой начальник, который дал ему приказ захватить или уничтожить заданную цель. И этот реальный командир отдаёт приказы своим подчинённым не ради собственного удовольствия, а ради выполнения поставленной начальником задачи, иначе лишится своей должности или даже жизни. Смекаешь? Зачем тащить этот реализм в игру, если от него нет "фана"? Это просто реализм ради реализма получается.

>промптом тоже можно описать тактику

А можно описать:

>Эй, нейронка, сыграй за меня, мне лень.

Или просто посмотреть летсплей. Или вообще забить на игры и заниматься тем, что тебе не лень и всё ещё доставляет удовольствие, если RTS - это не твоё.

Какая-то высосаная из пальца проблема. Есть набор классических механик, они доставляют игрокам фан - нет, нужно прикрутить реализм, чтобы был реализм.

Кроме того, если нужно, чтобы нейронка управляла юнитами в стратегии - сначала стратегию сделайте, а потом будете тренировать нейронку в эту игру играть.

>>2458

>лоуполи моделек чуть сложнее примитивов

И будет у тебя игра чуть сложнее примитивов. Даже заставка "трубопровод" в Windows не так проста, как кажется на первый взгляд. Особенно художникам. А графика - это то, на что первым делом обращает внимание твой потенциальный игрок.

>"2д игры проще чем 3д" - самый большой развод

Смотря как на это смотреть. Если делаешь 1-в-1 по механикам, но с разным рендером: всё сводится к количеству разных анимаций и стилю. 2D обычно более стильное и впечатляющее, чем 3D, но сотни анимаций потребуют больше времени в 2D. 3D позволяет крутить камерой, но если механики полностью совпадают, то это просто не нужно. 3D модельку сложнее детализировать, натягивать на скелет и анимировать по 12 правилам анимации. Необходимы специальные знания для 3D, тогда как рисовать в 2D можно буквально на любой бумажке. Оптимизация 3D графики сложнее, чем 2D графики. Главное преимущество 3D: использование одной текстуры, меша, скелета, анимации и т.д. много раз.

Но 3D графику редко используют для точной копии 2D игры. Чаще всего 3D используют, чтобы получить больше разных механик, недоступных в 2D, и другую перспективу на виртуальный мир: вид от первого и третьего лица, прыжки, карабканье, 3D головоломки, объёмные структуры и прочее. Навигация в 3D как игрока, так и NPC. Манёвры в 3D пространстве. Все специфичные для 3D механики сложнее, чем то, что может предоставить даже самая сложная 2D игра.

Кроме того, нужно осознавать ожидания игроков. Заявленная как 3D игра вызывает обычно больше ожиданий, чем любая 2D игра в том же жанре. Если ожидания не оправданы - игру игнорируют, либо заваливают негативными отзывами. Да, несложно сделать 3D игру на примитивах без текстур, но это не то, что ожидает средний игрок, когда слышит "3D". Стилизованные игры в 3D выглядят специфично и обычно менее популярны, чем фотореалистичные. Нужно очень постараться, чтобы игра на простых примитивах добилась признания и популярности. А простая 2D игра может быть любима игроками за картинки и историю, даже если механики слабые; никто не ожидает от 2D игр фотореализма и/или переусложнённых трёхмерных механик.

Банальный вид от первого лица требует проработки деталей, которые в 2D с видом сверху вообще нельзя разглядеть даже с максимальным приближением; в противном случае, у тебя будет сплошная заливка на половину или весь экран, что просто дезориентирует в пространстве, а ведь 3D навигация сложнее игроку.

Т.е. в среднем 2D игры всё-таки проще делать. При условии, что не замахиваешься на что-то слишком грандиозное и/или если художник. 3D проще если согласен терпеть негативные отзывы игроков за примитивную графику и/или если программист с кучей интересных 3D механик в голове, которые оправдывают недостаток качественной графики.

Для новичков рекомендуют 2D, чтобы разобраться с базовыми принципами геймдева без необходимости учитывать глубину пространства, вращать камеру в редакторе сцен и т.д. А ещё накидать примитивные рисунки в 2D проще, чем в 3D. Но такие учебные проекты не предназначены для публикации.