Как создать движок для программы

Комментарии

Популярные По порядку
Не удалось загрузить комментарии.

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ

ТОП-10 книг по C++: от новичка до профессионала

Книги по C++ на русском языке с лучшими оценками. Расставлены в порядке возрастания сложности, обобщены указанные читателями преимущества и недостатки.

Лучшие инструменты и советы начинающему C++ программисту

Хотите изучать C++? Делимся важными навыками, фреймворками и советами, которые помогут начинающему C++ программисту устроиться на работу.

Подборка книг по C++ для любого уровня

Хотите начать изучать C++, но не знаете с чего начать? Или подтянуть свои знания в С++? В статье приведен перечень полезных книг.

Источник: proglib.io

Как создать движок для программы

Вчера я определил, какие у движка должны быть библиотеки. Но то была больше теория. Сегодня я создал проект и применил теорию на практике. Вот что у меня получилось:

Как я писал ИГРОВОЙ ДВИЖОК | Разработка игр | GameDev

Вот так вот я организовал структуру своего движка. Давайте я рассмотрю подробней. Начну с папок. Всего создано шесть папок. Первая — _Doc, будет содержать ссылки на используемую документацию по движку (история, лист задач и т.д.). Фишка: обратили внимание на подчеркивание?

Так вот, это сделано специально чтобы папка была в самом вверху и не смешивалась с папками движка (папки сортируются по имени).
Application — это уровень приложения. Как вы видите в ней всего один проект с тем же именем. Данный проект — это динамическая библиотека (подробнее о видах библиотек можете прочитать http://ru.wikipedia.org/wiki/Библиотека_(программирование)). Пользователь в идеале должен будет работать только с этой библиотекой.
Папка Core — это основа из схемы. Она содержит 4 проекта. Каждый проект — это статическая библиотека.
Папка Engine — это ядро из схемы. Все проекты из папки, также являются статическими библиотеками.
Папка Framework пуста, потому что пока нет смысла в ней что-то делать.
И папка Test будет хранить приложения для тестирования частей движка.

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

Я не стану пояснять как я создал такой проект, так как это долго. Да и не расчитанно на новичков.

На этом подготовка завершена. Продолжим.

Любое приложение должно с чего-то начинаться. Это называется точкой старта (или входа) приложения. Обычно это или main() или WinMain(), а также все их производные. Но в движке нет точки старта, потому что движок не запускается сам по себе. Точку старта задает пользователь при создании приложения. Но я начну именно с нее проектировать и писать код.

Наша точка старта будет в приложении test.

Пользователь должен при старте, создать наследника от класса Application, полиморфировать нужные методы, инициализировать наследник, запустить его на выполнение и затем очистить ресурсы.

ЛУЧШИЕ 2D КОНСТРУКТОРЫ ИГР — ЭЧ2D

То есть получается так:

Поясню. Start — это условный момент запуска приложения. End — это условный момент завершения приложения. WinMain и MyApplication — это уровень приложения. Данные сущности пишутся пользователем. iApplication — это интерфейс из библиотеки Application.

Как вы видите, я выделил их цветом согласно схемы из предыдущей статьи. Я так буду поступать и дальше чтобы вам было легче ориентироваться.

Начнем писать код. Для начала создадим класс приложения. Находим Application и пишем:
Application.h

class ENGINE_DLL Application
<
public:
Application();
virtual ~Application();

// Инициализация приложения.
bool Create();

// выполнение одного кадра
bool RunOneFrame();

// Выполнение приложения.
void Run();

// Завершение приложения.
void Shutdown();

Application::~Application()
<
// чистим за нерадивым программистом
if (_isinit==true)
Shutdown();
>

bool Application::Create()
<
/*
Инициализация всех систем движка
*/

// пользовательская инициализация
if (_init() == false)
return false;
// сообщаем что приложение инициализировано
_isinit=true;
// сбрасываем флаг сообщающий о выходе
_exit = false;
return true;
>

bool Application::RunOneFrame()
<
// следим чтобы не было попытки рисовать при неудачно инициализации
if (_isinit == false)
return false;

void Application::Run()
<
// Инициализируем
if(_isinit == false)
Create();

// очищаем ресурсы
Shutdown();
>

void Application::Shutdown()
<
_isinit = false;
>

Если вам нужен файл export.h, то он такой:

#ifdef WIN32
#ifdef _BUILD_ENGINE
#define ENGINE_DLL __declspec(dllexport)
#else
#define ENGINE_DLL __declspec(dllimport)
#endif
#else
#define ENGINE_DLL
#endif

При этом, где-то в Application должен быть объявлен _BUILD_ENGINE. В проекте на который я дал ссылку выше, все это уже есть.

Теперь вернемся к приложению:
main.cpp

#include
#include «../Application/Application.h»

class MyApp : public Application
<
private:
protected:
// пишем пользовательские классы
virtual bool _init() < return true; >
virtual bool _frame() < return true; >
virtual void _close() <>
>;

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR pScmdline, int iCmdshow)
<
MyApp app;

Собственно вы уже можете собрать (но не забудьте прилинковать Application). Но запускать не советую — уйдет в бесконечность:) Мы ведь еще условий выхода не написали.

Так, теперь двигаемся дальше. Вспомним для чего нам был нужен Application — для обертывания остальных сущностей. Среди которых главной была Engine. Значит теперь ее нужно создать. Далее, по текущей задаче мы должны создать окно и инициализировать рендер.

Значит в модуле рендера появляются два класса — Window и Render. Но так как мы решили что сущность рендера абстрактна, то тогда нужен еще один класс RenderDX11 и WindowWin32, которые будут выполнять реализацию использования в рендере DirectX 11 в окне операционной системы Windows.

Схема усложняется:).
Начнем выполнение с конца. Находим библиотеку рендера и пишем код:
Window.h

class Window
<
public:
Window();
virtual ~Window();

/// Закрыть окно.
virtual void closeWindow()=0;

/// Вернуть заголовок окна
virtual const std::wstring _caption)=0;

Window.cpp

Window::Window()
<
_width = 800;
_height= 600;
_caption = L»Engine»;
>

Теперь нам нужен класс Render. Но тут я хочу сказать вот что — наш рендер должен быть единственным. Реализуем мы это через паттерн синглтон (погуглите, кому интересны подробности, прям по запросу «паттерн синглтон»). Так что сначала надо написать сам паттерн. Переходим к библиотеке Common. и пишем:
macros.h

#define Assert(a, b) assert(a b)

Singleton.h

virtual ~Singleton()
<
Assert(s_pSingleton, «Singleton class not instantiated.»);
s_pSingleton=0;
>

/** Returns pointer to a singleton.
*/
static T* getSingletonPtr()
<
return s_pSingleton;
>

/// A static pointer to an object of T type.
/// This is the core member of the singleton.
/// As it is declared as static no more than
/// one object of this type can exist at the time.
static T* s_pSingleton;
>;

template T* Singleton ::s_pSingleton=0;

Паттерн не мой, поэтому сохранен язык оригинала 😀

• Пишу свой игровой движок — 0
• Написание Своего игрового движка: Часть 1
• Написание Своего Игрового Движка: Часть 2
• Quest 3D движок
• Про Game Maker
• Немного об игровом движке Panda3D
• О сайте UralDev.ru
• The Free Country
• Обновился сайт NeoAxis Group
• Обновилась справка по движку LOVE
• Nir Hasson принят в OGRE Team
• DirectX 10 — скачать
• Сайт движка LOVE частично не доступен
• FPS Creator опасен для нашего PC!
• Как подмарафетить няшку, или критика конкурсной игры «Проклятый остров».
• Заметочка о программистах
• Какой выбрать язык для изучения?
• Программирование игрового движка на C#
• Как создать хорошую игру?
• Интересные функции Game Maker. Введение

Источник: gcup.ru

Game Engine своими руками #1

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

Если ты решил написать игровой движок, то значит ты уже хоть что-то знаешь, а как минимум неплохо владеешь тем или иным языком программирования. Если ты вынес со школьной скамьи основы Бейсика, то тебе, конечно, выбирать не приходится, но я, все же, не советовал бы тебе браться за игру, пока ты не овладеешь более совершенным инструментом. Если ты пишешь только на Delphi, и пишешь довольно долго, то у тебя есть хоть какие-то шансы выжить, но в идеале желательно овладеть языком Си, все-таки все солидные игры пишутся сегодня именно на нем. Лучше всего для нашего дела подойдет Visual C++ от Microsoft, желательно шестой версии, хотя это и не принципиально. Если ты долгое время общался с другими компиляторами, например от Borland, то тебе, конечно, имеет смысл оставаться в родной среде.

Прежде, чем приступать к бурным дискуссиям, я хочу убедиться, что твои представления о понятии «игровой движок» совпадают с моими. И так, игровой движок или game engine — это небольшая ОС в рамках игры, которая предоставляет набор базовых функций с помощью, которых игра устанавливает интерфейс с пользователем т.е. движком называется весь тот код, который отвечает за вывод графики, воспроизведение звуков, работу с сетью и т.д. , и который не касается правил самой игры. Надеюсь, с этим все ясно.

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

Первое, о чем стоит задуматься так это тип игры, для которой твой движок будет предназначен: будет ли это продвинутая RPG, либо гоночная аркада, либо это будет очередной шутер аля Quake. Будет ли твой движок поддерживать моды или он будет абсолютно закрытым. Стоит ли писать поддержку сети или можно обойтись сингл-плейером с глубоко проработанным сюжетом. Разберемся со всем этим по отдельности.

Специализация движка

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

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

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

При создании 3D движка для шутеров вроде Анрыла и Квейка, очевидно, в первую очередь стоит позаботиться о рендере, т.е. той части движка, которая будет отвечать за прорисовку (рендеринг) окружающего мира. Ты должен заранее определиться с системой, которую ты планируешь использовать. Будут ли это BSP-деревья (Quake), портальный движок (Unreal) или quad-деревья (Tribes). Особо ярые энтузиасты могут заняться строганием воксельного движка.

Следует строго разделить вещи, которые просто необходимы движку, которые играют ключевую роль (например, поддержка мультиплейера) и вещи, которые хотелось бы видеть (например, продвинутая система частиц или объемный туман). И прежде всего следует браться за реализацию именно необходимых вещей, все остальное может вообще не потребоваться в будущем.

Поддержка модов

Уверен, что про моды ты слышал не раз. Может быть, даже сам принял участие в их создании и уж точно попробовал клепать уровни для любимой Кваки или Халф-лайфа. Сейчас инет просто расходится по швам от обилия модов для игрушек, есть люди, которые до сих пор пишут моды для первоквака. С помощью мода первоначальную игру можно просто-таки вывернуть наизнанку, поменять не только внешний вид, но и
кардинально перевернуть гейм-плей, а можно просто слегка изменить правила, например замедлить практически до нуля скорость снарядов от BFG и так вот резвиться. Всей этой романтики
не было бы вообще, если бы умные программеры, такие как Джон Кармак, не предусмотрели бы поддержку этих самых модов в своих движках.

Ты можешь спросить, почему большинство игр все же не поддерживают моды если это так круто? Ответить однозначно на этот вопрос довольно сложно, но можно привести несколько основополагающих доводов. Во-первых, поддержка модов дело довольно сложное, а порой совсем и не нужное, представь себе мод «Rocket Arena» для Сапера. Во-вторых, поддержка модов может нанести, не очевидные сначала, как моральные, так и финансовые убытки разработчику, если какой-нибудь Вася из Таганрога выложит в сеть мод, форматирующий винт при каждом запуске игры. Поэтому-то Кармак и пишет собственные компиляторы, чтобы еще на этапе создания мода присечь попытки деструктивной деятельности.

Существует вариант, когда движок поддерживает не моды, а внешние ресурсы в виде самодельных карт к игре, моделек, текстурок, звуков и т.п. Но в этом случае стоит серьезно задуматься о написании собственных утилит или о поддержке существующих бесплатных редакторов, потому что не у всех юзеров на компе стоят лицензионные 3D Studio MAX и Photoshop (ха-ха).

ОК, ты окончательно и бесповоротно решил писать поддержку модов, тогда давай обсудим как это все дело можно обустроить. Если ты хочешь разрешить пользователям модифицировать только ресурсы, то тебе не о чем беспокоиться, всего лишь нужно предусмотреть чтение небольшого файлика из каталога с модом, в котором будет сказано, как сам мод называется и какую карту нужно запустить первой, этого достаточно (в Half-Life этим файликом был ‘liblist.gam’).

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

DLL (Dynamic-Link Library) или динамические библиотеки это файлы в которых хранится набор некоторых функций, которые затем могут быть вызваны из любой другой программы при условии, что программа знает имя функций содержащихся в DLL. Когда моды организуются в виде динамических библиотек, заранее оговаривается какие функции по умолчанию должны содержаться в коде мода, а затем движок просто вызывает эти функции, не задумываясь над тем с каким именно модом он работает и где расположены функции, которые он вызывает. Причем код самой «родной» игры также можно выполнить в виде мода.

Сетевые игры

Программирование движка для игр поддерживающих мультиплейер — дело архисложное. Тут мало уметь написать код отправляющий пакет данных, нужно хорошенько обдумать как будет организован сам процесс общения компьютеров.

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

Ну что, надеюсь ты понял, что написание движка дело довольно ответственное и это тебе не под «Ya mama» зажигать. Но я верю, что у тебя все получится, а если ты еще не почувствовал силы в своих руках, тогда не расстраивайся, мы сделаем все что сможем, чтобы помочь тебе в твоих девелоперских начинаниях. Главное не останавливайся перед трудностями и у тебя все получится!

Источник: xakep.ru