{"id":4009,"url":"\/distributions\/4009\/click?bit=1&hash=6ca492c3f83735606d9aedae9a61ec224ef2083f8beca590c50a2adcfd4adeee","title":"\u041f\u043b\u0430\u0442\u0438\u0442\u0435 \u00ab\u041c\u0438\u0440\u043e\u043c\u00bb? \u041f\u043e\u043b\u0443\u0447\u0430\u0439\u0442\u0435 \u043f\u043e\u0434\u0430\u0440\u043a\u0438!","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"4ea1e9ad-3a39-54d5-bfbf-ba7bfd1bb941","isPaidAndBannersEnabled":false}

Разработка собственного движка, напутствие

Для начала, всё ниже описанное лишь мой опыт, в целом это просто хобби. Я слишком странно могу описывать некоторые вещи, ибо пишу нечто подобное первый раз. Надеюсь всем всё будет понятно (=_=)

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

АТЕНШОН, МНОГА ТЕКСТА НЕТ ПИКЧ

Предостережение

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

Поясню - что бы написать минимально рабочую игру, тебе нужно: обработка ввода, вывод графики и игровой цикл с логикой. Можно сказать - "всего 3 компоненты и ты уже можешь делать свои крестики-нолики или тетрисы!". Но для звания "великого игрового движка", при мысли о котором ты возбуждаешься, явно не хватает всего 3х компонент. Различные механизмы подгрузки данных, гибкие системы рендера, система скриптов, встроенные редакторы уровней - всё это требует времени на реализацию, и чем больше ты хочешь, тем больше времени у тебя уйдёт на разработку "движка с 0", а сколько времени потратится на написание самой игры?

Будь реалистом, и подумай над тем, что бы написать свою игру на уже имеющихся инструментах. Это сэкономит тебе кучу времени и добавит пару галочек в твоё портфолио. Не бойся тратить деньги на коммерческие движки, если от этого зависит как быстро ты сможешь выйти на рынок. (есть риск что не окупится)

А как писать?

Для начала нужно подвести черту между двумя кардинально разными подходами в написании этих ваших "движков". Я обозвал их так...

  • "Динамические движи", это те в которых вся игровая логика содержится внутри объектов, которые можно передать в другие бинарные модули. (Прим - .dll библиотеки)
  • "Статические движки", это те в которых вся логика содержится внутри самого движка и определяется на этапе компиляции.

Какие нюансы я обнаружил при такой классификации?
"Статические движки"

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

"Динамические движки"

  • Требуют глубокого понимания матчасти, из-за виртуализации объектов.
  • Код можно разбить на независимые модули и подключать буквально на лету. В некоторых играх есть моды которые реализуют "движок в движке", которые используют другие подключаемые модули.
  • Большинство инструментов для отладки придётся писать самому, если это не встроено в сам язык. То есть, если ты не пишешь на .NET/JAVA/Lua?
  • "Скрипты" могут быть реализованы в виде скомпилированных бинарников обёрнутого в объекты, от чего "потанцевал" при добавлении контента может быть больше (в плане производительности).

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

Кроссплатформенность

Это боль. (вся глава моё нытьё...)
Первая мысль которая должна посетить твою голову — как распространить игру на максимально широкую аудиторию.
Ты можешь использовать кроссплатформенные библиотеки, но их функционал крайне ограничен, так как они пытаются создать абстракцию которая "будет жить на любой платформе". Ты конечно можете написать свою библиотеку... Но вот в чомъ мем
Проблема в том, что платформы достаточно сильно отличаются даже в самых базовых вещах. Как пример - Windows при старте программы не имеет потоков ввода-вывода и для этого ей нужно создавать консоль, но консоль можно создать 2 различными способами и у каждого способа есть куча параметров, для лююююбых потребностей. В Linux же всё проще, у тебя со старта приложения есть потоки ввода-вывода и что бы "увидеть их" нужно просто перенаправить их в файл или создать окно-терминал. КАК ты даже ТАКУЮ простую проблему будешь решать, я не представляю. (я это уже сделал)
Чего уже говорить о создании графического контекста...

Вот ты пытался в OpenGL на Windows? Знаешь что на официальном сайте написано использовать GetDC() при связывании контекста окна и OpenGL? А ты знал что это DC на самом деле может быть принтером? Может быть целым монитором? Видеокартой? Просто окном? "Ресурсом менеджера окон"? А то что в Linux ты должен ручками выбрать нужный тебе монитор для запуска? Всякие драйверы-сервера запускать? И не один. И это надо как-то собрать в одну единую абстракцию и непринуждённо дёргать по воле случая...

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

И всё же... Написать(наговнокодить) хотя бы простенькое приложение на API платформы, как по мне, важно. Так, ты будешь лучше понимать, что в конкретной системе значат абстракции которые дают фреймворки\языки.

Делаем игры, наивно

В начале статьи я ввёл понятие "компонента". На самом деле я называю так любую штуку "которая делает что-то другое" )))

Любой код можно разбить на некое число компонент-модулей. Самое примитивное приложение состоит всего из 3 модулей

  • Обработка ввода
  • Вывод изображения
  • Логика (зачастую на стейт машинах)

Уже это позволяет писать тебе довольно простые игры. Скажем крестики нолики или "давилку мух"? Давай вместе представим как оно может работать.

  • Загружаем нужные ресурсы
  • - В цикле...
  • Рисуем: фон > картиночки
  • Обрабатываем ввод
    - Если нажата мышка, проверяем хитбоксы объектов
    - Если прошли проверку, меняем "игровое состояние"
  • (для "давилки мух") Раз в Х циклов запускаем новую муху по некоторой траектории. И обрабатываем перемещение живых мух.

И это уже можно назвать игрой. "Погоди" - скажешь ты - "Но фактически тут 4 модуля, загрузка ресурсов!!". Хах, но если ты чуть-чуть разбираешься в линковке приложения, то ты можешь вшить данные в бинарник) И тебе не нужно будет загружать никаких данных. Поведение мух, также, вшито в движок и относится к логике, потому фактически тут именно 3 модуля.

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

Я бы сказал так - "движок занимается обработкой пользовательских данных и может иметь изменяемую логику"

Из такого определения давай же опишем некий "сферический движок для платформера".
Для начала, тебе потребуется описать больше чем один модуль, а логика самого движка будет гораздо сложнее.

  • Конкретная загрузка ресурсов
  • Обработка ввода, который конвертируется в абстракции
  • Вывод изображения, который обходит множество объектов
  • Игровая логика, которая уже разбита на несколько частей
    - Обработка загрузки-переходов уровней
    - Информация о сцене
    - Нахождение коллизий и проверки на триггеры
    - Обработка поведения ИИ?
    - Обработка ввода от игрока
    - Скриптовый процессор

Теперь, как прошлый раз, давай разберём поэтапно, что и как движок должен делать.
- Для начала опишем "минимальную" логику...

  • Информация о сцене (уровне)
    - Какой фон
    - Набор тайлсетов (2D матрица)
    - Предметы
    - Юниты
    *** Всё кроме фона должно иметь информацию о себе, типа - "текстура", "какие-то свойства", есть ли "триггер", "скрит" или "поведение"
  • Вшитые в движок "примитивы"
    - Триггеры (какие бывают, что проверяют, что вызывают. прим - если хибоксы пересекаются - запускает смену уровня)
    - Поведение (хардкодное поведение, что делает объект. прим - триггернутый предмет увеличивает свойство Х, у объекта который триггернул. Объект Х движется в одну сторону и случайное время меняет направление. Это можно оформить в виде "функций" для скриптового языка. )
    - Свойства (Что за свойства, определяемые скриптами свойства)
    - Процессор скриптов
  • Обработка передвижений-триггеров-физики?

Ну и сам игровой цикл будет состоять примерно из такой логики

  • Загружаем информацию об уровне (описание уровня)
  • Загружаем нужные ресурсы (текстуры и скрипты)
  • - В цикле...
  • Рисуем: фон > тайлест > предметы > юниты
  • Обрабатываем ввод
    - Абстрагируемся от кнопок и просто передаём "Идти влево"
  • Обрабатываем логику
    - Проходимся по всем единицам со скриптами
    - Проходимся по тем, у кого базовое поведение
    - Что-то делаем с игроком?
    - Проверяем коллизии-физику? (вызываем триггеры если что-то нашли)
    - Двигаем юнитов-предметы

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

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

Поясню за скрипты - для многих это будет открытием, но скрипты можно делать и в виде виртуальной машины-процессора. Твоя задача будет - написать парсер текста, описать виртуальную машину и придумать как именно получать информацию о сцене-объектах. В качестве примера, можно использовать многострадальные стековые процессоры, по типу forth. Они очень легко делаются, но к их логике нужно привыкать. По сути это единственный выход написать "быстро" ваш собственный "скриптовый процессор".
*** Обязательно сделай вывод логов при сборке скрипта, или при его работе.
*** Старайся избегать логики типа [INT a += "Lord"]. Писать нетипизрованный код опасно, но можно выделить отдельные команды для работы с конкретными типами.
*** ДА, ТЫ БУДЕШЬ ПИСАТЬ СКРИПТЫ НА АССЕМБЛЕРЕ.
*** Для написания простого ассемблера, хватит и знаний типа - Sting.indexof("ADD"); и подобного говнокода. Но что бы написать нормально, или хотя бы простенький язык, вам нужны знания о "регулярных выражениях" или "парсерных комбинаторах".
*** Не надо упарываться в "полноценный язык", посмотрите как писались языки программирования в бородатых 80х, даже тот же Pascal. Они работают просто и честно, такие реализации займут у вас в разы меньше времени, чем описание "очередного" ???C\Rust\Haskell???

Типа канец?

В целом написать некий "движок в вакууме" не такая сложная задача, как кажется. На ранних этапах большинство поведений-абстракций можно вшивать в движок. Да и в целом, большинство вещей работают довольно просто, и требуют от вас лишь знаний и понимания. Но я напомню, написать свой движок для игры - плохо. Это отнимает огромное количество времени, которое вы можете потенциально потратить на разработку самой игры. А любая гордость проходит, после осознания того, что ты делал свою игру примерно 20% времени пока писал код.

Изначально, решился написать эту статью, ради привлечения инвестиций, на время разработки своей «базовой +18 новеллы». (инициатива друга)
Так что ты это, кнопочку то нажми, а?

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

  • Как лучше работать с памятью-данными.
  • Проблемы STL библиотек. (C++)
  • Детали виртуализации объектов, микро рекомендации.
  • Как можно делать "моды".
  • Профилирование и Логирование, почему это важно.
  • Что нужно знать о многопотоке, вводные-подводные.
  • Асинхронно или параллельно? Как это работает?
  • Работа с текстом-кодировками, и почему это настоящий ад.

На счёт моего кода - не будет опенсорса. Когда я релизнусь, я выложу лишь API к бинарнику. По сути, я использую "динамический" подход, который описывал выше. Потому запустить свою игру, можно будет просто собрав .dll и запустить бинарник запихнув либу в аргументы строки. Но вот когда это случится... Когда я перестану морить себя голодом? Кто знает

PS - Под конец получилось немного сумбурно, ибо я писал всё за один заход. В целом я описал лишь поверхностно многие вещи. Если будет спрос, могу углубится.
PPS - Мне тут говорят что бы я сделал бусти и публиковался впредь там, раз в месяцок публикуя "фри контент". Может в следующий раз? Я просто не знаю о чём там можно писать, лол.
PPPS - "Статья слишкам длинная устал читать, пиши кароче"

Так что… Ещё свидимся?

0
121 комментарий
Написать комментарий...
Товарный супер_стар

Выложил Лонг в то время, пока сайт спит. Ещё и картинок мало.

Статья полезная, спору нет. Надеюсь ее кто то найти сможет утром

Ответить
Развернуть ветку
Alexander Gunko

Действительно, это же дтф. Тут чтобы пост открывали, надо его оформить как щитпост, а внутри хоба - и полезный контент.

Ответить
Развернуть ветку
1 комментарий
Евгений Романовский

Лонг и без котов, мдааа

Ответить
Развернуть ветку
2 комментария
vnkslv

Этот парень прав ☝️

Ответить
Развернуть ветку
Black Jack

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

Ответить
Развернуть ветку
Dark Project
Автор

Ну я первый раз что-то подобное писал, потому спасибо за совет.

Я вообще по угару писал себе всякий софт. Типо "компилятор для процессора Х" или "Визуализация шумов от измерений датчиков". Всё на нативном API. Ударила в голову идея объединить всё, и как раз знакомый хочет игру сделать, типо "ууу круто свой движок, так взлетим".
В целом вся история.

А статью написал чисто попробовать. Если будет время окупать, буду ещё писать.

Ответить
Развернуть ветку
5 комментариев
Ярослав
решился написать эту статью, ради привлечения инвестиций, на время разработки своей «базовой +18 новеллы».

Перечиал статью. Он что реально пишет движок что бы прозрачные png картинки показывать по порядку?визуальной новелл?

Ответить
Развернуть ветку
8 комментариев
Предвыборный ихтиандр
для дтф переигрывает

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

Ответить
Развернуть ветку
7 комментариев
Евгений Романовский

Не читал нихуя, но желаю тебе всего, что ты задумал

Ответить
Развернуть ветку
Becka Beckon

Все правильно написали. Пишу сейчас свой движок для портфолио чтобы собесы проходить без тестового задания, правда в моем случае проще, пишу веб движок на canvas + typescript, не нужно так заморачиваться с кроссплатформой и памятью как в плюсах.
Написал уже систему рендера, коллизий, звук, камеру, инпуты, тайловый редактор и нахождение путей. Самое сложно пока что нахождение путей. Получил большой опыт в оптимизации, шаблонах проектирования и математике, такой опыт в обычных рабочих задачах редко получаешь. Библиотеки не использовал кроме реакта для UI.

Ответить
Развернуть ветку
Ненавижу dtfеров

О кайф, ты по гайдам каким-нибудь делал или всё сам?

Ответить
Развернуть ветку
1 комментарий
Виви

Писать свой игровой движок, это как самому строить инфраструктуру, которая построит автоматом ракету к Марсу. Хотите стройте соло конечно, но выйдет из этого мало, или за 1000+ ваших же жизней. Без других людей никак, без денег никак. Все настолько сложно, что даже не хочется и начинать, никакого смысла.

Ответить
Развернуть ветку
Предвыборный ихтиандр

Да не, чего бы нет. Это как свой компилятор/язык/ОС писать - полезно в некоторых случаях для развития

Ответить
Развернуть ветку
3 комментария
Danil Dm

А зачем делать это с нуля есть великие Id tech движки с открытыми исходниками. Свой движок нужен для независимости и бесплатности сделав форк idtech движка автоматически можно получить уже функции все нужные так еще и инструменты в также модульность если q3

Ответить
Развернуть ветку
4 комментария
Ярослав

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

-То что подойдёт для открытого мира а-ля космические рейнджеры . Потребует прописать логику НПС пока они в соседней системе и игрок их не видит на загруженным уровне.
Что то такое же потребует и игра типа сталкер/ скайрим - работу с НПС вне зоны уровня возле игрока.

-То что подойдёт для Ртс потребует максимально разобраться с поиском путей для тысяч юнитов на карте.

И т д.

Так что вопрос. Что за игра. Для чего тебе движок

Ответить
Развернуть ветку
Dark Project
Автор

Я забыл об этом написать. В целом согласен что архитектура пилится изначально вокруг конкретного жанра. В целом мой "микропример" в конце показывает что мы именно вокруг платформера строим функционал.

Но у меня движок именно для низкоуровневых манипуляций, что бы софт писать. А то что на нём игры работать будут, уже другое.

Ответить
Развернуть ветку
44 комментария
Алексей

Беги в минцифры, лутай бабло) Галенкин еще в ранних "как делают игры" говорил что для прогера это шикарная практика запилить свой движок, даже самый примитивный, на многое глаза откроет

Ответить
Развернуть ветку
Dark Project
Автор

Очищает мозги от наивных фантазий)

Ответить
Развернуть ветку
WannaBe2D

Ещё один никому нахуй не нужен движок которых полон гитхаб, ура

Ответить
Развернуть ветку
Black Jack

Так он же сказал, что фиг нам, а не исходники на гитхабе. Ремот фасад, правда, посулил, если ему купят поесть.

Ответить
Развернуть ветку
1 комментарий
wolik

Обычно в свои движка заморачиваются, потому что имеющиеся полное дерьмо.
Почему дерьмо?
Ну это целый лонг.

Ответить
Развернуть ветку
Максим

Разработка собственного движка, напутствие: никогда не разрабатывайте собственный движок!

Ответить
Развернуть ветку
Ярослав

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

Ответить
Развернуть ветку
MGDS Studio

Уважаю таких людей. На извечный вопрос - "зачем тебе это нужно?", отвечать бесполезно. Это задают люди другой породы. Я сам пилю почти два года свой движок и игру на нем. Как положено - с редактором уровней. Сейчас правда пересел на другой проект - уже тошно смотреть на это сборище костылей и пластырей и хочется сделать все с нуля и по уму. Добавлю еще 7 уровней и сражение с боссом и все. Отмотай два года назад - сделал бы все то же самое и считаю, что время потратил не зря. Это время, которое могло пройти в просмотре сериалов или полуголых девок в инстаграме. А тебе видимо как и мне доставляет удовольствие процесс и это главный критерий того, что ты делаешь все правильно.

Ответить
Развернуть ветку
Dark Project
Автор

К тому же это бесценный опыт) Пока пишешь код понимаешь что раньше твои мысли были "формами костылей". А сейчас с гордостью понимаешь что вырос за это время.
Я изначально взялся за это, почитав как всё работает в разных фреймворках, спойлер - криво. Единственное что хорошо работало, был SDL, но там тебя анально ограничивали со всех сторон, не давая ничего сделать сложнее вывода картинки. Поразмыслив я подумал что смогу лучше и вот пилю какие-то вещи. Типо свой загрузите, свой манагер окон, свой планировщик задач. И это вот всё.

Ответить
Развернуть ветку
2 комментария
Александр Драгунов

Были у меня тоже мыслишки написать свой движок just for fun и даже чё-то получалось, но в основном дальше вывода какой-то 3D сферы или что-то в этом духе на OpenGL не уходило и забивал. Единственное, что я до ума доводил, это типичиную змейку на чистом С++ с графикой в консоли (с системой рейтинга; какое-каким редактором уровней в блокноте, где каждый символ отвечал за какую-то сущность на уровне; с саундтреками и прочими ненужностями, но как грится молодая кровь, времени вагон...)

Ответить
Развернуть ветку
Dark Project
Автор

Ооо, у меня был подобный проект, я рисовал в пеинте по пикселям сцену, а потом запускал "типо шутер" на рейкастенге, аля "Wolfenstien3D". Использовал разные техники, занимался матаном. Весело было)
(Оно рисовалось попиксельно на GDI, потому дико лагало на высоких разрешениях)

Ответить
Развернуть ветку
Иван Чернов

1. где картинки?
2. где видео с поделием на двигле? (змейка is fine too)
3. ну и последнее, но не самое маловажное. ГДЕ ССЫЛКА НА БУСТИ!?
4. ах да. Аниме-девочка маскот это +10 к привлекательности проекта. Где нейросетки, думаю, найдёшь.

Да, я понимаю, что до первой публичной альфы шанс что твоё двигло хоть кому-то нужно примерно околонулевое, но если дашь фреймворк (типа RTS+VN) - то уже на какое-то комьюнити расчитывать можно, а там и донатики.

И вот тогда это будет просто...

Кстати, а чего форт для скриптов не прикрутишь? Он конечно упорот, но новичкам что js, что fotrh зубрить.

Ответить
Развернуть ветку
Dark Project
Автор

Тот самый форт, который форт, не нужон. Это конечно весело ручками набивать, и очень сильно "меняет твоё восприятие реальности", но может сделать что-то... гибридное? Упростить какие-то детали?))

Крч мне нужна технодемка движка, вот что я понял с коментов. И объяснять темы по порядку. Увы, буду до нового года работать, потому времени делать что-то почти не будет. Ибо деньги у меня ВСЁ

Она за маскот зайдёт? ахаха) (на каком-то сайтике нагенерил и забыл где блъ)

Ответить
Развернуть ветку
6 комментариев
Никита Лукьянов

Это всё здорово, но лучше не еби мозг и используй юнити/анрил в зависимости от того что вы там за игру хотите сделать. Ну разве что ты бессмертный и тебе чисто похую что вместо месяца ты будешь 3 года игру делать.

Ответить
Развернуть ветку
Виктор Петровичев

месяца ?! мы третий год работаем.

Ответить
Развернуть ветку
1 комментарий
Андрей Михайлов

Сей спичь о чем? Мальчик с полом определиться не может?

Ответить
Развернуть ветку
Виктор Петровичев

спасибо за контент. мы когда думали над этим вопросом, просто взяли Unreal 4, а потом 5)

Ответить
Развернуть ветку
Dark Project
Автор

2 раза написал, в начале и в конце что не надо делать свой движок. Хах, так что да

Ответить
Развернуть ветку
Danil Dm

Есть ID Tech изменив которые можно сделать многое как это сделали Activision, Id software и многие другие кто делают AAA проекты сейчас. Также есть ioquake3 модульный который можно моддировать бесконечно

Ответить
Развернуть ветку
Владислав Румянцев

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

Ответить
Развернуть ветку
Читать все 121 комментарий
null