Категория: Gamedev
Просмотров: 4044
    Ахой! Для начала расскажу чем мы будем заниматься в данной рубрике. Нет, ну из названия конечно понятно, что мы опять будет делать игры. Это так, но есть одно «НО». Оно всего одно, зато весьма существенное: здесь вы не увидите пространных рассуждений о создании КИ, здесь мы будем заниматься конкретной игрой, сначала произведём декомпозицию основной задачи «Создать игру» на более мелкие и более простые части и будем в каждую в своём уроке реализовывать.

    Для начала определимся с игрой – это будет не тетрис и не пинбол, как многие могли подумать (я надеюсь каждый из вас уже пачку таких игр написал) это слишком просто. Конечно можно и Lines навернуть до такой степени что технологии HL2 померкнут, но это уже извращение. Поэтому делать мы будем РПГ. Не надо смеяться ибо это будет предельно упрощенная РПГ, в которой моделька главного героя под управлением игрока будет бегать по подземелью и крошить врагов, плюс ближе к концу добавим поддержку мультиплеера (выпустим официальный аддон с мультиплеером как это сейчас принято )) ), что бы можно было подключиться к серверу найти братьев по оружию и устроить замес в на несколько персон. Вот собственно программа минимум. Приступим?

    Хе-хе-хе. Вижу вы ответили утвердительно на поставленный вопрос ). Однако не спешите составлять список фич, которые будет поддерживать игра, какие шейдеры 10.0+ версии будут в игре. Сейчас не это главное. Писать код мы сейчас тоже не будем. А просто поговорим об объектной модели нашей КИ. Для этого как раз самое время, поскольку даже реализация такого простого проекта, который описан выше, может превратиться в ад для программиста. Итак...

    В одной книжке, которая недавно была мною прочитана была такая фраза:

    «Игра по сути является базой данных, которая работает с игровым контентом (загружает модели, текстуры, музыку и шейдеры) и представляет его в нужном виде.»

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

    Пойдем прямо по пунктам - «загружает модели, текстуры, музыку и шейдеры». От того как хорошо вы создадите систему загрузки ресурсов и их представления в движке, будет зависеть очень многое: прозрачности кода, легкость с которой вы сможете добавлять новые фичи, скорость кодирования в конце концов. Поэтому я решил остановиться на такой концепции – все ресурсы делятся на несколько групп: аудио/видео ресурсы, текстуры, шейдеры, модели, элементы управления, игровые объекты. Загрузкой каждого такого ресурса занимается отдельный менеджер. По сути менеджер является совокупностью массивов загруженных данных и кода для доступа и оперирования этими данными. Подобная организация позволит сделать движок более модульным, и при правильном проектировании интерфейса менеджеров изменение кода для оперирования ресурсами не повлияет на остальную часть программы (конечно если это не какая-то радикальная доработка). Обязательным элементом каждого менеджера будет массив загруженных ресурсов. Доступ к конкретному ресурсу будь то текстура или шейдер будет осуществляться по курсору этого элемента в массиве. То есть вместо кода

struct CGameObject{
	LPDIRECT3DDEVICE9	*texture;
};
У нас будет
struct CGameObject{
	int 			texture_id;
};

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

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

    Следующая идея, которой мы будем придерживаться, заключается в том что абсолютно все настройки будут грузиться из файлов. То есть у нас будут xml-ные файлы, в которых будут прописаны настройки рендера, списки используемых текстур, моделей, шейдеров etc. (это позволит нам создать некоторое подобие data driven engine – движка управляемого данными).

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