Я уже писал что мною было решено с нуля писать движок. Вот сейчас и начну. Времени у меня не много, так что писать буду медленно и неспешно.
Писать буду в некоем подобии урока, то есть буду пошагово пояснять что я сделал. Но это всеже не уроки, это мой процесс создания движка :).
Зачем это нужно: как то так получается что мне больше нравится писать механизмы, чем собственно игру. Ведь игра это не только код - это скрипты, ресурсы, графика, сюжет, тексты. Всем этим мне не особо интересно заниматься, а искать людей не имея готовых заготовок сложно и тем более не интересно. То есть когда начинаешь делать игру, обычно получается так что вместо написания кода, занимаешься тысячью и одной сторонними задачами. А вот когда пишешь движок, не отвлекаешься на остальное и только пишешь код. У меня нет цели быть круче крайзиса или анреала. Я просто буду клепать свой милый уютный игровой движок.
В этой статье я буду описывать принятые архитектурные решения. Для начала смотрим на это:
Здесь я простенько изобразил роль движка в игре. Игровой движок (Game Engine) - это такая сущность на основе которой и можно создать игру. Инструменты (tools) - это сущность которая позволяет облегчить работу с движком и работать в более удобных условиях, чем кодить. И в конце получается игра. При этом и инструменты и игра зависят от движка. То есть нельзя взять редактор от unreal engine и движок от crysis. Но я думаю это и так понятно.
Так вот, давайте теперь представим что каждая из этих сущностей представлена в виде файлов. И нас теперь интересует игровой движок. По каким-то причинам многие делают его монолитным. То есть весь движок, это одна библиотека. Хотя иногда и делят. Но лично меня не устраивает идея монолитности движка, уж очень сложно с монолитом работать. Я просмотрел множество движков, и заметил что среднее число строк чистого кода - 40 тысяч. Если все это писать в одной библиотеки, то получается каша. И тем не менее почему-то пишут в одной библиотеке.
Много ранее я уже показывал идею разбиения движка на отдельные составляющие. Теперь воспользуюсь этой идеей. Так что у нас стоит задача, разбить сущность "игровой движок" на меньшие сущности.
Будем думать. Яс дело нужно как-то выводить на экран, первая сущность - рендер. Пользователь как-то должен влиять на игру, значит вторая сущность - система ввода. Без звука ныне никуда, третья сущность - звук. И физика, это нынче модно, вот и четвертая сущность. Ну и конечно же, движок, не движок, если не держит мультиплеер, так что пятая сущность - сеть. Так. Теперь есть пять разношерстных сущностей. Мы должны их связать в один движок, который и будет с ними работать. Так что шестая сущность - движок. Изобразим на схеме:
Но на этом не останавливаемся и выделим еще несколько сущностей. Во-первых в ООП есть много общего кода - в основном всякие паттерны и классо-образующие интерфейсы. Сюда же можно отнести и базовые типы движка. Так что выделяется еще одна сущность - общая. Кроме того в процессе разработки и использования движка всегда имеется код, к движку не имеющий отношение, но очень важный (логи, профилирование, таймеры). Для него мы выделим еще одну сущность - утилиты. В любом движке очень важна математическая часть, и хотя обычно ее смешивают с рендером, я всеже ее выделю в отдельную сущность - математика. Кроме того мне еще пригодится файловая система и чтобы не загромождать предыдущие, для нее также будет выделена своя сущность.
Все, почти идеал :). Но добавим несколько штрихов. Обратимся к рендеру. Хотя я и решил что ограничусь DX 11, но ведь неизвестно что будет в будущем, да и потом неизвестно каким будет DX 12, может тоже совершит революцию и надо будет писать все по другому, как это стало с DX 10. Поэтому сделаем эту сущность как бы абстрактной и создадим дополнительную сущность для рендера DX 11. Также сделаем и с физикой. Я буду использовать physX. И возможно далее все остальные сущности тоже получат наследные сущности. Но ясно, что во-первых кто-то должен следить за всеми этими сущностями, а во-вторых "основа" никак не связана с ядром - нехорошо. Поэтому добавим еще одну сущность которая объединит движок, и которая и будет основой игр - приложение (Application). Кроме того в будущем мне захочется добавить каких-нибудь высокоуровневых фич над движком. Для этого выделю еще одну сущность - фреймверк (framework). Точнее это будет раздел а не сущность. Сущностями будет менеджер сцен, гуи и т.д.
Итог:
Вот как-то так.
Как же мы будем это осуществлять? Application как самый верхний уровень пусть будет в виде динамической библиотеки. А вот все остальные будут статическими. В идеале, пользователь должен подключить только Application к своему приложению, но это как получится, тут влияет специфика статических либ.
Собственно на этом вводная завершена. В следующей статье будет создано окно с дирексом и возможно выведен первый треугольник (или квадрат:) )
Также если вы считаете, что данный материал мог быть интересен и полезен кому-то из ваших друзей, то вы бы могли посоветовать его, отправив сообщение на e-mail друга:
Игровые объявления и предложения:
Если вас заинтересовал материал «Пишу свой игровой движок - 0», и вы бы хотели прочесть что-то на эту же тему, то вы можете воспользоваться списком схожих материалов ниже. Данный список сформирован автоматически по тематическим меткам раздела.
Предлагаются такие схожие материалы:
Если вы ведёте свой блог, микроблог, либо участвуете в какой-то популярной социальной сети, то вы можете быстро поделиться данной заметкой со своими друзьями и посетителями.
Ткните носом в полный учебник по движку... . в гугле меня забанили , яндекс неподдерживается браузером , остальные поисковики сбежали , тапками непулять. Есле можно то на ЯП С++ . 2 \ 3д без разнецы . на русском . Многие пишут , что уроков полно , но по факту мало.и те разрознены .
Я сейчас тоже пишу движок. Правда, между мной и им неприятная прослойка из того факта, что использовать буду новый для меня язык. А так - двухлетний опыт работы, знание ООП и паттернов. В силу обстоятельств, вопроса "нужно ли?" не возникает - учусь в боевых условиях, т.к. с геймдевом дела имела мало.
Спасибо за статью - было очень здорово посмотреть на это все другими глазами - свои уже давно замылились в собственных диаграммах. И, да, самый классный совет - смотреть другие движки и учиться на их опыте и устройстве. Спасибо.
в основном именно так. Движок это не инструмент, это универсальный код который может использоваться в множестве проектов. Вот например ты написал хорошую систему для лога. Но ты ее напишешь потому что тебе понадобится как-то удобно следить за ошибками а не потому что тебе пришла идея написать систему лога в вакууме. Но она может быть достаточно универсальной чтобы ты ее использовал во всех своих проектах. Вот также и движок. И да, можно и не писать игру (как я поступаю сейчас когда пишу 3D движок, не написав ни одной 3D игры). Но тебе надо иметь простое представление о том - что твоему движку будет нужно. Наиболее простой способ это понять - написать реальную игру и по ней понять что важно а что нет. Можно не писать а изучить чужую, но здесь нужен достаточный опыт, что обычно означает что с таким опытом ты легко и так напишешь игру. Например вот - нужно ли движку умение рисовать фигуры (линии, треугольники, квадраты). Ты можешь решить что нужно (некоторые и решают). Но на самом деле, это бесполезный функционал, потому что всю графику рисует художник а не программист. Но ты потратишь время на написание этого функционала.
Короче, я прочитал твою историю постов. рано тебе еще о движках думать, все равно путнего не получится. Извини, но это так. Я 2D движок начал писать имея трехлетний опыт c++, до этого я даже не собирался этого делать
Вообщем возьми учебники по c++ Я например советую учебник "освой самостоятельно c++ за 21 день" (как-то так, точное название не помню). Вообщем поищии поспрашивай по форуму хорошие учебники, я уже не помню. Поищи Андре Ламот: Программирование игр для Windows Там много полезной теории. Не смотри на устаревшие технологии, они тебе вообще не нужны. тебе оттуда нужна только теория - как делать. А не примеры
Далее, я когда начинал, стал изучать SDL. И тебе советую. Скачай. Ты кстати visual studio поставил? Даже если нет, то на dev-c++ сдл тоже был. Вот отсюда качай - http://www.libsdl.org/ тебе нужна та которая 1.2 (на вторую версию не смотри, ее еще не сделали, по ней нет документации)
Вот тебе на первое время http://plg.lrn.ru/doc/sdl/index.html Вот тебе больше уроков (на английском, скачай какой-нибудь промт, если не знаешь) - http://lazyfoo.net/SDL_tutorials/index.php Там кстати написано в первом уроке как ее подключать на любую IDE, в том числе и dev-c++ - http://lazyfoo.net/SDL_tutorials/lesson01/windows/index.php
Вот тут кое-какая подборка ссылок - http://www.gamedev.ru/community/sdl/forum/?id=141434 В том числе есть ссылка где показывают как сделать игру Space Shooter
Если не веришь что на SDL что-то хорошее можно сделать, то вот тебе http://www.wesnoth.org/ Сделали на чистом SDL без всяких движков
Если кому не трудно опишите по пунктам как написать игровой 2d движок: 1.Что потребуется (софт и прочие) 2.После приобретения нужного софта с чего начать
Эм, лично я свой 2D sapphire начал так. Сначала взял SDL, на нем пытался писать игры. Образовывался какой-то общий код. Потом я решил делать движок. Взял этот общий код и из него стал делать движок.
Вообще я посоветую сделать так - накачай кучу двухмерных движков. Постарайся изучить как минимум один движок (желательно самый популярный) чтобы просто понять какие задачи он выполняет. Проанализируй все остальные движки(и вот тут тебе уже нужны хорошие знания программирования, иначе ты просто половины не поймешь), что у них одинаково, чем они различаются. Потом сядь и начни думать (лучше всего создав специальный документ) чтобы ты хотел видеть в движке, и что оно должно делать, пиши этот документ, описывай каждый нюанс. То есть к примеру: Приложение - Должен создавать окно с возможностями изменять размер. - ... Изображение - грузится - рисоваться - менять размер менеджер ресурсов - хранить файлы - следить чтобы не было двух одинаковых файлов - удалять, когда они больше не нужны. Но опять же, все это требует нехилых знаний программирования и умение проектировать приложения (а это тоже целая наука, можешь погуглить UML) Так что лучше реши, через что будешь выводить графику (как я когда-то решил взять SDL), это может быть и OpenGL и DirectX и что-нибудь экзотичное (SDL, SFML). Начни писать тетрисы, змейки (ведь ты же 2D движок делаешь, а он должен уметь такие игры делать) У тебя будет создаваться какая-то кодовая база, вот в будущем это кодовая база и станет основой движка
спасибо за отзывы:) Диаграммы строил в замечательной программе http://www.softwareideas.net/ которая совершенно бесплатна для индивидуального пользования, а коме того на русском.
Ух ты, я вот только начал изучать Си++, очень интересна структура движка. Отдельное спасибо за оформление - оно - великолепно сделано, язык не напрягает, и картинки очень качественные. Обязательно продолжайте писать! С меня +.
0
http://quest3d.ru/?p=162 
Я сейчас тоже пишу движок. Правда, между мной и им неприятная прослойка из того факта, что использовать буду новый для меня язык. 
Очень интерестна жду новых уроков 
Пошли к нам на завод! Будем велосипеды делать 
нее, я делаю свои эксклюзивные велики 
А как собственно SDL подключить к Dev-C++ 
Ух ты, я вот только начал изучать Си++, очень интересна структура движка. 
