На дворе 2025 год, а я всё ещё продолжаю делать видеоигры. Если верить archive.org, я начал заниматься этим двадцать лет назад! Достаточно долгий срок для одного увлечения...
Когда я рассказываю о том, над чем работаю, люди часто спрашивают меня, как я делаю игры, и их часто удивляет (а иногда и тревожит?), когда я говорю, что не пользуюсь коммерческими игровыми движками. Существует какой-то стереотип, что если ты делаешь игры не в популярном инструменте наподобие Unity или Unreal, это значит, что ты чуть ли не вручную пишешь ассемблерный код.
Я искренне считаю, что создание игр без огромного «многофункционального» движка может быть проще и интереснее, а часто и позволяет оптимальнее тратить вычислительные ресурсы. Я не делаю игру, в которой «есть всё», поэтому мне не нужны 90% фич, предоставляемых движками. Все мои игры обладают конкретным стилем и у меня есть конкретные способы работы с моими инструментами. Часто оказывается так, что используемым по умолчанию реализациям фич в крупных движках наподобие Unity не хватает столь многого, что мне всё равно приходится писать их самостоятельно. В конечном итоге, мои проекты по большей мере оказываются моими собственными инструментами и системами, а движок становится необходим лишь для создания удобного UI и части рендеринга...
Тут можно задаться вопросом, а зачем вообще использовать движок? Что он даёт? Зачем я позволяю инструменту потенциально препятствовать моей работе, когда его владельцы внезапно принимают неэтичные и ужасные бизнес-решения? Или выпускают обновление, которое требуется для запуска моей игры на консолях, но ломает всю систему в игре, заставляя переписывать её? Зачем я ежедневно борюсь с этим для работы с движком, пока я постепенно заменяю все его стандартные системы и он постепенно становится только загрузчиком ресурсов и фреймворком UI редактора?
Для меня ответ очевиден: просто не нужно использовать крупные игровые движки, и вместо них писать собственные маленькие инструменты для конкретных сценариев. Это интереснее, и к тому же мне нравится управлять своим стеком разработки. Когда что-то идёт не так, я могу найти проблему и устранить её, а не отправлять отчёт о баге, чтобы спустя три месяца получить ответ, что избавляться от него не будут. Мне нравится знать, что спустя ещё два десятка лет я всё ещё смогу скомпилировать свою игру без необходимости пиратить древнюю версию поломанного игрового движка.
Разумеется, это мои личные предпочтения, но уже долгое время я пишу инди-игры. Я несколько лет работал с движками наподобие Game Maker, и уже потом перешёл на более легковесные и специализированные процессы разработки. К тому же я работаю в очень маленьких командах, где легко создавать одноразовые инструменты для членов команды. Но я хочу развеять миф, что создание игр «с нуля» — это какая-то серьёзная и неподъёмная задача; особенно учитывая состояние опенсорсных фреймворков и библиотек в 2025 году. Множество популярных инди-игр было создано на фреймворках наподобие FNA, Love2D и SDL. Создание игр «без движка» не означает, что вам в буквальном смысле нужно открывать текстовый редактор и писать системные вызовы (хотя если хотите, можете поступить и так). Часто на изучение способов самостоятельной реализации таких систем тратится столько же времени, сколько и на изучение проприетарных процессов работы с самим движком.
С учётом всего вышесказанного, я думаю, было бы интересно рассказать о моём процессе работы и о том, что я использую при создании игр.
Языки программирования
Бóльшую часть времени я работал на C#, и за исключением кратковременного перехода на C++ несколько лет назад, я вернулся к современному процессу работы с C#.
Наверно, когда я говорю о C# разработчикам крупных игр, они вспоминают, как этот язык выглядел примерно в 2003 году — с закрытыми исходниками, интерпретируемый, многословный, со сборкой мусора. Должен сказать, что с тех пор язык существенно улучшился. C# 2025 года очень отличается от C# даже 2015 года, и многие из изменений были направлены на повышение производительности и улучшение синтаксиса языка. Теперь вы можете распределять в стеке массивы динамического размера ! C++ не может этого делать (хотя C99 может...).
Кроме того, разработчики dotnet реализовали в C# горячую перезагрузку (которая чаще всего работает), что потрясающе удобно для разработки игр. Можно запустить свой проект при помощи dotnet watch , и изменения в коде будут применяться интерактивно. Это замечательно, если вам нужно поменять способ отрисовки или обновления противников.
К тому же C# оказался золотой серединой между высокой производительностью (которая нужна в видеоиграх) и простотой повседневной работы. Например, я работал над City of None с моим братом Лиамом, который в начале проекта почти не умел кодить. Но за прошлый год он постепенно освоил язык настолько, что теперь умеет самостоятельно писать бои с боссами. Вот настолько доступен C#; к тому же, выстрелить себе в ногу на нём довольно сложно. Для маленьких команд, где каждый выполняет разнообразные задачи, это очень хороший язык.
Наконец, у него есть встроенная рефлексия... И хотя я бы не использовал её в коде релизов, возможность рефлексии игровых объектов в инструментарии редактора очень удобна. Я с лёгкостью могу создавать инструменты для интерактивной проверки, показывающие состояния игровых объектов без необходимости метапрограммирования или данных рефлексии в игре. Потратив несколько лет на создание игр на C++, я очень рад, что у меня снова появилась эта возможность.
Окна... Ввод... Рендеринг... Звук?
Всё это важные аспекты при «создании игры с нуля», однако есть куча отличных библиотек, помогающих выводить всё на экран, от SDL, GLFW и Love2D до Raylib и так далее.
Я пользовался SDL3, потому что он выполняет всё необходимое в качестве кроссплатформенной абстракции поверх системы: работу с окнами, джойстиками и рендерингом. Он работает в Linux, Windows, Mac, Switch, PS4/5, Xbox и так далее. В версии SDL3 есть абстракция GPU, обрабатывающая рендеринг на DirectX, Vulkan и Metal. Всё просто работает без проблем, фреймворк опенсорсный и используется многими в нашей отрасли (например, Valve). Я начал работать с ним, потому что FNA, который использует Celeste на всех платформах, кроме Windows, применяет его в качестве абстракции платформы.
Я написал собственный слой C# поверх SDL для общих инструментов рендеринга и ввода, которые я применяют во всех проектах. У меня есть собственный способ структурирования моих игр, поэтому мне удобно взаимодействовать с этим тонким слоем. Он замечательно подходит для моих целей, но у него есть и полнофункциональные альтернативы, например MoonWorks.
До выпуска SDL3 с абстракцией я писал собственные реализации OpenGL и DirectX, что было непросто! Но это многому меня научило, к тому же результат оказался не таким плохим, как я ожидал. Однако я всё равно очень благодарен за SDL GPU, потому что это очень прочный фундамент, который будет протестирован на миллионах устройств.
Для звука мы используем FMOD. Это последний проприетарный инструмент, оставшийся в наших процессах разработки, что мне не нравится (особенно когда что-то перестаёт работать и приходится патчить библиотеку вручную), но это лучший инструмент для этой задачи. Если вам нужно только воспроизводить звуки, то для этого есть более легковесные опенсорсные библиотеки, но я работаю с командами, которым требуется точный контроль над динамическим звуком, поэтому без инструментов наподобие FMOD не обойтись.
Ассеты
Про ассеты мне сказать особо нечего, потому что когда выкатываешь собственный движок, то просто загружаешь в него все нужные файлы и двигаешься дальше. Все мои игры с пиксель-артом загружаются полностью, и это нормально, потому что вся игра весит порядка двадцати мегабайтов. Когда я работал над Earthblade, где ассеты больше, я регистрировал их при запуске игры и загружал только по запросу, избавляясь от них при смене сцен. Мы выбрали простейшую реализацию, которая выполнила свою задачу.
Иногда нужно преобразовывать ассеты перед тем, как их сможет использовать игра; в этом случае я обычно пишу небольшой скрипт, который выполняется во время компиляции игры и выполняет всю необходимую обработку. Вот и всё.
Редакторы уровней, UI...
Когда-нибудь я напишу полностью процедурную игру, а пока мне нужны инструменты для проектирования внутриигровых пространств. Для этого есть множество потрясающих готовых инструментов, например LDtk, Tiled, Trenchbroom и так далее. Я в той или иной степени пользовался всеми ими, они легко настраиваются и запускаются в проекте; достаточно лишь написать скрипт для получения сгенерированных ими данных и создания игровых объектов в среде исполнения.
Однако для своих проектов я обычно люблю писать собственные редакторы уровней. Мне нравится, когда все данные моей игры привязываются непосредственно в редакторе, и никогда не углубляюсь в создание сложных фич, потому что обычно необходимые нам возможности специфичны, но ограничены.
Но мне не нравится писать UI — кодинг текстовых полей и раскрывающихся списков меня не особо радует. Мне нужен простой способ создания полей и кнопок, как собственные утилиты редактора, которые пишут для движка Unity.
И здесь нам на помощь приходит Dear ImGui. Это легковесный кроссплатформенный движок GUI с immediate mode, который можно легко добавить в любой проект. На показанном выше скриншоте редактора он используется для всего, кроме режима сцены, которую мы сами создали для отрисовки уровня. Существуют более функциональные (и тяжёлые) альтернативы, но если он достаточно хорош для множества игр, в том числе и для Tears of the Kingdom, то хорош и для меня.
Благодаря ImGui становится крайне просто писать инструменты редактора. Мне нравится, когда мои инструменты подтягивают данные непосредственно из игры, а при использовании ImGui вместе с рефлексией C# это становится очень удобным. Я могу обойти в цикле все классы Actor в C# и сделать их доступными в редакторе, написав всего несколько строк кода! В случае более сложных инструментов написание собственной реализации оказывается слишком большой тратой ресурсов, поэтому для выполнения специфических задач я применяю уже готовые инструменты (например, Trenchbroom для проектирования 3D-окружений).
Портирование игр ... ?
Главной причиной изучения C++ несколько лет назад стали мои опасения о портируемости. В то время было сложно запускать код C# на консолях, потому что он компилировался «just in time», что допускают немногие платформы. В нашей игре Celeste использовался инструмент BRUTE для транспиляции IL (промежуточных двоичных файлов языка) C# на C++ и последующей рекомпиляции под целевую платформу. У Unity есть очень похожий инструмент, выполняющий ту же задачу. Это сработало, но мне казалось неидеальным. Я хотел, чтобы можно было просто компилировать наш код под целевую платформу, поэтому изучение C++ казалось единственным реальным вариантом.
Однако с тех пор в тулчейне Native-AOT C# произошёл невероятный прогресс (по сути, это означает, что весь код компилируется «заранее», как это происходит на C++ и Rust). Теперь можно компилировать код на C# для всех основных архитектур консолей, и это очень здорово. Проект FNA активно развивал это направление, что привело к выпуску игр, написанных на C#, для всех крупных платформ.
Кроме того, у SDL3 есть консольные порты для всех основных платформ. Если использовать их, как слой абстракции платформы (при аккуратной обработке системных вызовов) всё будет работать без проблем.
Прощай, Windows
Под конец скажу, что теперь для разработки игр я не пользуюсь Windows (за исключением тестирования). Мне кажется, это вполне соответствует моей философии использования опенсорсных кроссплатформенных инструментов и библиотек. Меня всё больше раздражала работа с Windows, отвращали бизнес-практики и общая нехватка возможностей операционной системы. Я рос на Windows, но примерно три года назад полностью перешёл на Linux. И, если откровенно, при программировании видеоигр я совершенно о ней не скучаю. Она не даёт мне ничего, чего я бы не мог делать быстрее и изящнее в Linux.
Разумеется, некоторые процессы и инструменты не работают в Linux; просто такова современная реальность. Я и не полностью избавился от продуктов Microsoft — я использую vscode, пишу игры на C# и храню проекты на github... Но чем больше людей ежедневно пользуются Linux, тем больше необходимость в его поддержке и тем больше появляется поддержки опенсорсных альтернатив.
(Забавно, что сегодня я в основном играю в свои игры на SteamDeck, то есть на PC, игровой консоли, веб-сервере и в телефоне всегда используется платформа Linux.)
Прочие мысли
А как насчёт Godot?
Если вам нужны возможности, которые предоставляют более крупные игровые движки, то я определённо считаю, что Godot — это лучший из вариантов. То, что он опенсорсный и поддерживается сообществом, избавляет от множества проблем, которые у меня были с проприетарными игровыми движками, но обычно он всё равно не подходит мне для создания игр. Я намереваюсь поэкспериментировать с ним в будущем, чтобы проверить некоторые свои идеи.-
А как насчёт 3D?
Я считаю, что использовать большие движки более уместно для 3D-игр, но даже для любого моего 3D-проекта я бы создал собственный маленький фреймворк. Я хочу создавать стилизованные игры, не требующие современных технологий, и выяснилось, что делать их достаточно просто (например, мы разработали Celeste 64, почти не имея никаких знаний в 3D, менее чем за две недели).
Celeste 64 Для реализации моей идеи игры нужна только самая крутая технология
Тогда работайте в Unreal! В этом нет ничего плохого, просто моим проектам не требуются подобные фичи (и я считаю, что большинство того, что мне нужно, обычно можно достаточно быстро изучить).Вся моя команда знает [игровой движок XYZ]
Миграция всей команды на собственные движки может быть затратным и длительным процессом. Я поделился своим мнением исключительно с точки зрения маленькой команды/соло-разработчика. Тем не менее, судя по моему опыту, множество средних по размерам студий перешли на собственные движки, потому что потенциальный риск использования проприетарных движков показался им слишком большим, а затраты на миграцию и обучение себя оправдали. Думаю, крупным командам использовать собственные инструменты сегодня проще, чем в прошлом.-
Процессы разработки конкретных игр
Ассеты Aseprite загружаются автоматически Я загружаю файлы Aseprite, и движок City of None автоматически превращает их в игровые анимации, используя их встроенные тэги и тайминги кадров. Его формат на удивление прост. Если вы пишете собственные инструменты, добавлять в них подобные вещи очень просто!
Комментарии (49)
Mephi1984
21.05.2025 09:19Подтверждаю. Если раньше было влом писать кучу кода по загрузке ресурсов в форматах JPG, OBJ, подключение OpenAL и прочей рутины, то теперь можно навайбкодить всю второстепенную обвязку и сосредоточиться непосредственно на разработке игры.
Jijiki
21.05.2025 09:19надеюсь такой ИИ есть, мне модель не смогла слёту без ошибок сделать експорт/импорт из блендера/в блендер(там постоянно ошибки или експорт/импорт статики, а скелет не захватывает или не пишет) костной анимации
Mephi1984
21.05.2025 09:19У меня получилось написать с помощью ChatGPT скрипт на Питоне, который экспортировал скелет из Блендера + анимацию в текстовый файл. Получилось не с первого раза, но если с умом уточнить некоторые моменты, то ИИ напишет скрипт
Jijiki
21.05.2025 09:19ок то что она импортировала сеньор 3д дизайнер должен загружать в блендер, чтобы работать с моделькой исходной и с анимациями, которые прикреплены к родителю мешу по логической связи
тоесть проверкой служит хотябы фул перенос скелета с моделькой на диск/с диска в рамках блендера
(по пайплайну я делаю модельку, креплю скелет и анимирую, нужна возможность редактирования, чтобы выстраивалась последовательность из попыток у 3д дизайнера)
например клонирование родителя ради ввода кастомной анимации ну тоесть из Т позы(добавление одежды по размерам родителяс последующим мержем к анимациям либо через скрипт либо просто из нулевой точки через открывание редактирование ), но должна быть возможность открывания формата в блендере
Jijiki
21.05.2025 09:19вот типо такого, это я уже сам сделал
Скрытый текст
import bpy ob = bpy.context.object me = ob.data print ("vertices",len(me.vertices)) for i in range(len(me.vertices)): print(me.vertices[i].co.x,me.vertices[i].co.y,me.vertices[i].co.z) print ("indices",len(me.polygons)) for i in range(len(me.polygons)): print(me.polygons[i].vertices[0],me.polygons[i].vertices[1],me.polygons[i].vertices[2])причем моделька делает другой код а не такой, теперь буду делать анимационный формат
RigelGL
21.05.2025 09:19В блендере разделены: меш, арматура, анимация.
В арматуре у костей есть имена, у анимаций - тоже, поэтому переносить анимации между разными скелетами возможно (вроде менять веса у меша для разных арматур тоже).В 2021 году писал свой экспортер из блендера. Вспоминая размер контекста, который надо хранить в голове, нейронки вряд ли справятся (либо затратите х5 времени на объяснения и проверки, чем написали бы сами).
Дело не столько в объёме, сколько в понимании устройства блендера, так как получить нормали модно несколькими способами, но в первом они будут правильные, а во втором - (0; 0; 0;).
В итоге - да навайбкодить простой экспортер можно, а доводить до product-ready придётся вручную.
Jijiki
21.05.2025 09:19нормали(при условии что они настроены при моделировании в нужную сторону ) можно получить инверсной матрицей(если с математики начинать чутка можно понять как сделать) вроде после загрузки(они же нужны для света), чтобы загрузить надо меш, так что всё сходится главное меш, веса (кароче рабочий материал - чтобы запускаешь анимацию и визуально была как надо)
суть в том что когда анимация заработала(лично так делал несколько раз проследил паттерн) она войдёт в рабочий цикл(можно прикидывать что и как хочется), чтобы через свой формат уже гонять/клонировать и тп(тоесть можно и с нуля так делать полный цикл моделировать человека, потом крепить скелет), ну а можно хотябы к своей же модельке получить полную Т позу - то что в наше время дизайнер может получить Т-позу значительно прибавляет интерес(есть понимание что хоть лоу поли рабочий можно сделать) и там уже будет видно где косяки - это минимальный набор джентельмена
плюс свой формат убирает пласт ненужных библиотек и уже понимаешь что оптимизировать в модельках/ке, проще работать становится с данными
у меня через ассимп настроено, Т поза невидимая она root, далее пошли скелеты на нужные анимации (идти, бежать, танцевать и тд) так что наверно можно и так, это у fbx так через ассимп у меня
Jijiki
21.05.2025 09:19вот те нормали если я не ошибаюсь если они синие то полигоны смотрят наружу, нормали есть от полигонов и вершинные
Скрытый текст
Jijiki
21.05.2025 09:19у меня вот что получилось по арматуре и вершины-индексы )
Скрытый текст
import bpy ob = bpy.context.object me = ob.data #f = open("", "w") print ("vertices",len(me.vertices)) #f.write(str("vertices ")+str(len(me.vertices))) #f.write('\n') for i in range(len(me.vertices)): print(me.vertices[i].co.x,me.vertices[i].co.y,me.vertices[i].co.z) # f.write( str(me.vertices[i].co.x)+str(' ')+str(me.vertices[i].co.y)+str(' ')+str(me.vertices[i].co.z) ) # f.write('\n') print ("indices",len(me.polygons)) #f.write(str("indices ")+str(len(me.polygons))) #f.write('\n') for i in range(len(me.polygons)): print(me.polygons[i].vertices[0],me.polygons[i].vertices[1],me.polygons[i].vertices[2]) # f.write( str(me.polygons[i].vertices[0])+str(' ')+str(me.polygons[i].vertices[1])+str(' ')+str(me.polygons[i].vertices[2]) ) # f.write('\n') armature_obj = None for obj in bpy.data.objects: if obj.type == 'ARMATURE': armature_obj = obj break if armature_obj: print(len(armature_obj.data.bones)) for i in range(len(armature_obj.data.bones)): a=' ' str1=str(i)+a+armature_obj.data.bones[i].name # print(bpy.context.object.data.bones[i].name) if armature_obj.data.bones[i].parent: str1+=a+str(armature_obj.data.bones[i].parent.name) str1+="\n" str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[0].x) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[0].y) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[0].z) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[0].w) str1+="\n" str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[1].x) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[1].y) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[1].z) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[1].w) str1+="\n" str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[2].x) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[2].y) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[2].z) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[2].w) str1+="\n" str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[3].x) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[3].y) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[3].z) str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[3].w) str1+="\n" # print(bpy.context.object.data.bones[i].parent.name) else: str1+="\n" str1+=a+str(armature_obj.data.bones[i].matrix_local[0].x) str1+=a+str(armature_obj.data.bones[i].matrix_local[0].y) str1+=a+str(armature_obj.data.bones[i].matrix_local[0].z) str1+=a+str(armature_obj.data.bones[i].matrix_local[0].w) str1+="\n" str1+=a+str(armature_obj.data.bones[i].matrix_local[1].x) str1+=a+str(armature_obj.data.bones[i].matrix_local[1].y) str1+=a+str(armature_obj.data.bones[i].matrix_local[1].z) str1+=a+str(armature_obj.data.bones[i].matrix_local[1].w) str1+="\n" str1+=a+str(armature_obj.data.bones[i].matrix_local[2].x) str1+=a+str(armature_obj.data.bones[i].matrix_local[2].y) str1+=a+str(armature_obj.data.bones[i].matrix_local[2].z) str1+=a+str(armature_obj.data.bones[i].matrix_local[2].w) str1+="\n" str1+=a+str(armature_obj.data.bones[i].matrix_local[3].x) str1+=a+str(armature_obj.data.bones[i].matrix_local[3].y) str1+=a+str(armature_obj.data.bones[i].matrix_local[3].z) str1+=a+str(armature_obj.data.bones[i].matrix_local[3].w) str1+="\n" print(str1)
gleb_se
21.05.2025 09:19Основная проблема с ИИ в том, что есть мнение, что он уже сейчас может написать корректно работающий код под достаточно объёмную задачу с первого раза, даже если пользователь не имеет представления как это сделать. Это заблуждение, именно знания пользователя позволяют в запросе дать чёткие критерии, чтобы он не галлюцинировал и не выходил за рамки объёма токенов.
ripandtear
21.05.2025 09:19Ох как же много плюсов. Что вынес для себя из опыта взаимодействия с Unreal Engine (не претендую на истину последней инстанции), и использования готовых движков в целом:
Минусы:
- Никакого контроля над тем, куда плывет этот огромный корабль - в новых релизах могут сломать то что у вас работало, добавить то что вам не надо, поменять API, лицензирование, и т.п.;
- Весомая часть навороченного функционала скорее всего будет простаивать;
- Бэкпортить нужные вам фиксы и новый функционал - отдельный тяжелый пласт работ сверху;
- Разбираться в чужой философии как использовать движок, и чужом коде;
- Скорее всего особо новых знаний вы не получите, т.к. большая часть вопросов (особенно базовых) должна закрываться существующим уже написанным функционалом;
Плюсы:
- Масштабируемые знания - в теории можно в дальнейшем работать по найму, если разобраться полностью как работает та или иная чужеродная технология и сделать ее "своей";
- Сложные вещи могут быть реализованы гораздо лучше, чем если вы будете пытаться их делать сами (особенно по части рендера).
Jec13
21.05.2025 09:19Большой плюс таких игр без движков, это Р А З М Е Р !!! Он получается компактным!!!
Jijiki
21.05.2025 09:19не получится изза костной анимации, хотя я сужу по ассимпу, если его как-то ухитриться собрать конечно то может быть
со своим форматом получится наверно(а свой формат дотягивает до инструментария например блендер, от которого будут зависеть прогеры скрипта - хотя это проще если уже есть спецификация собственного формата, потом если есть формат свой значит уже есть визуализатор модельки, ну его можно сделать впрок отдебажить в блендере например ))
RigelGL
21.05.2025 09:19Достаточно глянуть на текстуры:
1024х1024 в формате ETC2_RGB займёт 0.5 МБ, плюс простейший MIP = 0.68МБ, условно 0.7 МБ. Brotli / z сожмет до 0.2-0.5 (а зависимости от данных).В одном материале: цвет, нормаль, металличность, шероховатость. Последние две - одноканальные, их можно сжать до RG, B оставить пустым.
Итого 3 текстуры на 1 материал = 2.1 (1.2 сжатый) МБ.100 материалов - 120МБ только на текстуры.
Если текстуры не 1к, а 2к, то размер больше в 4 раза (480 мб).Ещё меши, но они занимают 30-40% от размера текстур.
Анимации - зависит от игры. Может получиться сравнимо с текстурами, а может раз в 5 меньше.
Музыка занимает много, сравнимо с текстурами, возможно больше.
Jijiki
21.05.2025 09:19я пока делаю упор модельки и свет, с текстурами я уже понял что может много весить
пока сам их рисую в блендере
LAutour
21.05.2025 09:19Вспоминается .kkriger в 96кб.
RigelGL
21.05.2025 09:19.kkrigger, насколько я помню, так и не дошёл до релизной версии, а всё ради минимизации .exe, из-за чего игра гвоздями прибита к win api, и, скорее всего к какой-то конкретной версии винды, так как на win 11 запускается в режиме совместимости с некоторыми багами.
Портируемость - нулевая.
Расширяемость - околонулевая.
Популярность - вечная в сообществе минимизаторов.
Ценность для игрока - мизерная.LAutour
21.05.2025 09:19и, скорее всего к какой-то конкретной версии винды
А вот тут претензия скорее к Микрософт, которая в каждой новой винде обычно ломает что-нибудь из совместимости.
SadOcean
21.05.2025 09:19Мысли конечно во многом верные, но не универсально полезные.
Чтобы так делать, нужно подсобрать граблей, кроме того, это не универсальный ответ для команд и серьезной разработки игр.
Время - деньги даже для себя лично, а уж для других людей в случае найма - и подавно.
Любую фичу можно сделать, но современное разнообразие и сложность инструментов и фич такова, что сделать с нуля весь тулсет (или даже собрать из кусков) требует огромного количества времени.
Движки же обеспечиваются стабильную основу, понятные правила, множество специалистов, с ними знакомых и готовые решения.
Если не нравятся платные движки - можно стать энтузиастами для опен сурсных.
Единственное, что страдает - чувство контроля, но проблема в том, что свой движок тоже не то чтобы дает это когда что-то в очередной раз ломается во внешних API.
Обьективные проблемы движков, которые вылезают при долговременном использовании большой командой могут быть не релевантны проблемам разработчика-одиночки.Jijiki
21.05.2025 09:19неизменная математика поидее,отрисовка текста, примитивов, и далее грабли - формат(статика, анимация), тулсет на блендер, и вот уже вы можете сделать игру, мерж террейна и разбиение виртуально на квадранты не совсем подподает под сложность как только поймём как генерить что нужно,
тогда стоит вопрос что добавляют и изменяют в движкаха кажись понял, у движка стоит задача пром масштаба по доступности, плюс реализация фишек, а у студии стоит вопрос написать своё решение если его пишут с нуля например
SadOcean
21.05.2025 09:19Сделать игру можно конечно на спичках, простые головоломки можно написать за вечер вообще с нуля.
Но во первых на движках их вероятно можно написать еще быстрее (впрочем такого же можно достигнуть, имея свой джентльменский набор).
Но чтобы делать нечто серьезное - посмотрите на современные игры. Если вы хотите сделать не инди для себя, а коммерческий проект - игроки будут ожидать от него графики, количества уровней, музыки, других вещей. Да и вы не энтузиаст 80-х и знаете, как выглядят крутые игры.
Не всем подходит делать креативные инди платформеры (и хорошие инди платформеры тоже делаются не за 5 минут).
И как только нужно нормальное 3д, физика, какой никакой звук, или, к примеру, нормальный редактор для части контента (ведь делать нужно не только уровни, но и меню, и заставочки и интерфейсы) - ты спекся.
Банальная возможность купить набор 3д ассетов чтобы не делать заборы и бочки на уровне - великое благо, потому что тебе лично придется потратить времени в эквиваленте гораздо больше, чем 5 долларов стоимости ассета.Jijiki
21.05.2025 09:19знаю нужно около 3-4 тысяч моделек плюс определиться с точным ландшафтом, сложность только уи - тут соглашусь, но может чонить придумаю) на демку потянет )
aax
21.05.2025 09:19Время - деньги
В коммерческой игровой игровой индустрии это давно превратилось(исключения есть, но они лишь подтвержают общее правило), в то что игровой софт это наиболее кривой, глючный и отвартительно оптимизированный софт.
И коммерческие "супер-движки", тут пожалуй основная причина, так например руководитель одной из коммерческих игродельных компаний(не буду называть какой), на вопрос о поддержке мноядерных процессоров в играх, пояснил, что если события гейплея, как таковые, распаралеливаются, то поддерживаем многоядерность, если нет, то извините!
SadOcean
21.05.2025 09:19Время деньги - это всегда было так.
То, что сегодня считается "живой классикой" делали не только энтузиасты на коленке, но и вполне себе волчары капитализма со всеми атрибутами - сжатыми сроками, переработками, спорными компромиссами и т.д.
С качеством игр вопрос связан с развитием индустрии и рынка, а не с самописными движками. Просто потому что могут и это дешевле - продукты супер сложные, все не проверишь, патчи можно делать хоть каждый день. Цена ошибки низка, достаточно, чтобы критическая масса игроков была довольна. Раньше игры отвратительного качества тоже выходили, но цена была другой - тираж дисков не перепечатаешь.
Вообще ситуация характерна не только для игр, они лишь выпуклый пример. Весь софт стал сильно хуже, позасовывают модных веб фреймворков на виртуальный сервер со встроенным браузером - все, интерфейс утюга готов.
По поводу участия движков в этом, то конечно связь есть, но с другой стороны. Порог вхождения действительно низок и мы видим взрывной рост игр. Естественно не все они одинаково качественные. История ровно как и с другим хорошим инструментом - он не ведет к уменьшению и улучшению работы, он ведет к тому, что работы делают больше, потому что могут.
Копроэкономика. 2k. Это хорошая статья, иллюстрирующая происходящее.Jijiki
21.05.2025 09:19ну извините вы говорите об уровне дум, даггерфол, там и учили по другому, откройте описание формата файлов(есть 2 формата, которые показывают динамику изменения требования знаний к подходу) для интереса и вы поймёте разницу, те студенты вполне могли реально быть ентузиастами, просто так совпало все аргументы вместе в то время я считаю тем более не забывайте Skeletal_animation а еще если посмотреть глубже проводились исследования как её делать и до сих этот вопрос полу открытый отсюда и обилие форматов, по сути движок это окружение для создания движений моделей или их интерактивного проигрывания, но не такой как редактор(типо блендер или майя)
чтобы понять о чем я необходимо избавиться от слова анриал или юнити и взглянуть на это наивнее, тоесть буквально надо чтобы интерактивно проигрывались анимации вот то как наивно показалось это поидее то и есть буквально, движок и создан для этого, а рисование примитивов и математика подкрепляют это и дают уверенность
SadOcean
21.05.2025 09:19Вы говорите об определенном аспекте движка, прежде всего рендере (и это безусловно важная часть).
Движок в целом понятие довольно размытое - начиная от просто набора библиотек и заканчивая целым тулсетом.
И собственно ровно дум и показал, насколько это сложно и важно в смысле технологий, но в то же время как это можно отделить от игры и переиспользовать. Дум был одним из первых лицензируемых 3д движков, хотя библиотеки существовали и до этого.
В контексте требований и знаний, необходимых для разработки, они безусловно изменились. Еще в ранних нулевых была куча движкописателей по очереди имплементирующих самые вкусные штуки свежих релизов - от мощных 3д фич до симуляций на 10000 юнитов.
Проблема в том, что к играм это не всегда приводило.
Я не считаю либерализацию разработки игр злом, хотя безусловно проблемы создает.
Но и талантливейшие дизайнеры тоже прорезались сильно позже. Раньше, когда надо было быть обязательно программистом, а так же и швец и жнец и на дуде - было печальнее.
Игры безусловно развиваются, просто не всем нравятся направления. Но эволюция не так работает.Jijiki
21.05.2025 09:19потомучто сделать скелетку, это значительная часть(+математика) плюс если смотреть на формат и требования-технологию отрисовки 95(прямая отрисвка(листы(1 версия GL) или более старые технологии)) - один вид рендера, 2005 другой вид (более похожий на буфферный погуглите mdx ваще магия ) такой как щас, в контексте что загрузили пачку анимаций персонажа и вот уже можно симпровизировать сцену(а сцена это декорации всего лишь) ну еффекты по вкусу - это как раз частички, текстуры, кусочки полигона(у dx это где-то Effect где-то шейдер наверно, я пока частички делал только на GL)
конечно говорю об этом ведь кто-то юзает хавок чтобы не париться
Jijiki
21.05.2025 09:19не просто так завёл реч о формате, потомучто если посмотреть разные форматы, лично мне очень нравится 3ds, можно увидеть что формат - это выражение движка, в формате можно прокидывать штуки или определять что упрощает обработку в коде, тоесть опять приходим к подходам по работе с данными
Jijiki
21.05.2025 09:19Скрытый текст
потомучто пришлось столкнуться с этим чтобы разобраться как хранить данные, чтобы потом было удобнее
тоесть как через векторное пространство настроить скелет, да это задача формата, хранить данные чтобы удобнее было их прочитать, формат - интерфейс для человека чтобы прочитать и воспользоваться им
impwx
21.05.2025 09:19Пробовал такой подход. Делать игру на собственном движке первое время весело, а потом оказывается, что многие удобные вещи на коленке за пару вечером не делаются - сборка под разные платформы (особенно мобильные), поддержка разных разрешений экрана, создание атласов текстур, оптимизации отрисовки, системы частиц, столкновение различных форм, UI, внутриигровые покупки, профилировщик и т.д. - в других движках кто-то другой уже потратил сотни человекочасов, чтобы сделать всё как следует, а тебе только предстоит.
Jijiki
21.05.2025 09:19система частиц прикольная смотрите на то что вы выделили не как на тягость, а как на содержание книги, как на практики, тоесть всё заработает только вместе,
профилировщик это чаще RenderDoc, уи на первое время может помоч Imgui, столкновение надо разобраться с математикой и там определиться что точно нужно, оптимизация отрисовки надо смотреть практики и учиться, перенос кода на мобилку можно делать с sdl библиотекой, атлас достигается через понимание плоскости и переноса в шейдер данных, разные разрешения не сталкивался, с такой базой сложности начнутся только на этапе создания контента и 3д анимаций(улучшение через математику), да еще лоды не сказали и всякие новые практикипопробуйте начать с кубического мира через полигоны, там куб это точка может проще будет вьехать в тематику
impwx
21.05.2025 09:19Я не говорю, что это невозможно - но крайне утомительно и трудозатратно, особенно для хобби-проекта, который делает один или пара человек по вечерам
Jijiki
21.05.2025 09:19а зачем тогда программировать еще? тоесть где вы хотите научиться тому что есть и посмотреть какие бы вещи были бы для удобства реально нужны? тоесть не делать движок окей.
не делать утилит которые нужны? тоесть вы хотите только за деньги программировать или как?
нет ну конечно сложно, там всё как снежный ком по итогу, и не одна сфера участвует в создании код-визуализация, но не знаю
impwx
21.05.2025 09:19Простите, мне очень сложно следовать за мыслью в вашем комментарии, но попытаюсь ответить.
Метафорически говоря, если я хочу поесть салат и начну его приготовление с посадки семечек на грядку, то я умру с голоду быстрее, чем что-то вырастет. Вместо этого я пойду в магазин, сколько бы ни твердили, что выращенные своими руками овощи полезнее и вкуснее.
И в программировании точно так же. Я хочу получить готовую игру в обозримое время. Когда ресурсы ограничены, их лучше потратить на высокоуровневые вещи типа оттачивания геймплея и баланса, сюжет и т.д., а не ковыряние низкоуровневых проблем и поиска костылей для них. С нормальным движком можно рассчитывать на то, что эти скучные вещи уже решены.
alextrof94
21.05.2025 09:19Жду подобный пост от разработчика сколько-нибудь известной игры за год-два от начала создания, а не от разработчика узконишевых фан-проектов на протяжении 20 лет.
Да, естественно, такие бывают, но это исключения.
Вспоминается цитата с баша про "ненужный" широкополосный интернет: "канализационная труба такая широкая чтобы пики трафика пропускать". Современные комбайны-движки для того же: чтобы ты мог загуглить как сделать фичу в игре, которую захотел, а не для того чтобы ты неделю гуглил как программировать инструмент, который позволит эту фичу сделать. Поэтому почти все крупные студии, не имеющие собственный движок, дорабатывают существующие движки, а не изобретают велосипеды. А для 99% инди и дорабатывать ничего не надо.
Vaniog
21.05.2025 09:19Celeste, которую разрабатывал автор, мягко говоря, вполне себе известная игра.
aax
21.05.2025 09:19Плюсую и в закладки.
Коммерческие "супер-движки", по моим скромным наблюдениям, давно превратили игровой софт пожалуй в наиболее кривой, глючный и отвартительно оптимизированный софт.
Полностью согласен с автором, что на каждое обновление "супер-движков", потом необходимо ставить кучу заплат в софте их использующем, и это касаеться всех, а не только малых студий и соло-разработчиков.
Hypernoire
21.05.2025 09:19Желаю автору удачи, мотивации. Сам форкнул Quake 3 движок и занимаюсь переписыванием всего а также встраиваю obj формат моделей, физику пишу, скриптовый интерпретатор свой итд
cdriper
21.05.2025 09:19не, ну если это не про бизнес, а про то, что писать свои движки это так прикольно и речь идет о проектах масштаба Celeste...
yppro
21.05.2025 09:19Это пост не про игры как бизнес, не про деньги вообще. Человек любит программировать, всё сделать сам от начала до конца и рассказывает как это делает таким же, как он.
SADKO
Православненько!