Обзоры игр, статьи, программы, обои, игры, общение...

  

Статьи

.: НАВИГАЦИЯ 3D

--- 3D Touch ---

 

.: СЧЁТЧИКИ

Рейтинг@Mail.ru

 

.: БАННЕРЫ

Rambler's Top100

 

.: РЕКЛАМА

По вопросам размещения Вашей рекламы обращаться ко мне.

 

.: ПРИКОЛЬНОЕ ФОТО

Пишем графический движок с нуля!!!
Итак, мы хотим разработать собственную компьютерную игру, но не знаем, с какой стороны подойти к решению данной задачи. Именно вопросом "С чего же начать?" обычно задаются начинающие разработчики. Первое, что нам предстоит - выбрать инструмент разработки. Это очень важный этап, ведь именно от этого зависит эффективность создания игры. Здесь всё зависит от поставленной задачи: если это простенькая аркада с плоской графикой, то подойдёт практически любой язык программирования, даже Turbo Pascal. Но если мы замахнулись на создание игры с современной 3d графикой - нужно как следует подумать, прежде чем делать свой выбор.

Существует огромное количество конструкторов игр - программ, позволяющих в одиночку и в краткие сроки собрать вполне презентабельную игру с приятным внешним видом без особых усилий. Примерами конструкторов игр могут послужить Game Maker, Dark Basic и другие. Но у всех этих языков программирования имеется существенный недостаток - ограничение функциональности. Такие конструкторы игр по сути являются готовым графическим движком и интерпретатором к нему. То есть, разработчик будет всегда ограничен возможностями данного графического движка.

Второй путь - разработка игры на любом из универсальных языков программирования Visual Basic, C++, Delphi, C# и другие. Свой движок я писал на Delphi. Выбор основывался на этой системе, т.к. скорость всех C++ компиляторов просто удручает, а по функциональности Delphi практический не ограничивает разработчика. Но сразу сесть и начать писать игру всё равно не получится - для этого должен быть определённый фундамент, с помощью которого можно разрабатывать игру, так называемы графический движок. В недавних номерах Игромании Константин Артемьев подробно рассказывал, что такое графический движок и с чем его едят. Но если вы по каким-либо причинам пропустили этот номер, то скажу коротко, что движок схож с операционной системой в рамках самой игры и отвечает за низкоуровневые операции вывода графики, звука, обработки сигналов игрока и мультиплеер. Нужен он для повышения уровня абстрагирования программиста. Без движка далеко не уедешь, и это не удивительно: сложно одновременно думать о технической стороне вывода такой-то модели и проектировать физику игры, например.

Таким образом, у нас есть выбор: взять готовый графический движок или разработать свой. У обоих подходов есть свои положительные и отрицательные стороны. Так, разработка собственного, пусть очень простого движка - совсем не простая задача. С другой стороны, у бесплатных решений есть свои слабые стороны. К тому же, я с трудом представляю, как можно быстро разобраться в сотнях и тысячах килобайтах чужого кода. Это ещё один повод написать всё самому от начала и до конца. Если вы решили писать свой графический движок, тогда эта статья для вас. Я буду рассказывать о том, как лучше организовать этот, один из важнейших этапов разработки игры. Сразу оговорюсь, что всё, что будет сказано ниже основывается на собственном опыте, а подкрепляться сказанное будет скриншотами из собственного графического движка New Fantasy, на который я потратил больше полугода. Скоро срины появятся в разделе "Обои".

После выбора языка программирования следует определиться с графическим API. На сегодняшний день имеется две альтернативы: OpenGL и Direct3D, входящий в DirectX. Помимо этого, можно разработать собсвенную графическую библиотеку, но здесь появляются сложности. Если производители видеокарт не поддержат новую графическую библиотеку, то скорость даже простых сценок на мощных компьютерах будет просто ужасной (несколько кадров в секунду). Думаю, что разработка конкурентоспособной уникальной графической библиотеки не рациональна и под силу только крупным командам разработчиков. Поэтому считаю этот "особый путь" не для нас. Я остановил свой выбор на OpenGL по той причине, что эта графическая библиотека более стандартизирована, в новых версиях OpenGL сохраняется обратная совместимость со старыми версиями. А ведь это очень важно для разработчика. По функциональности данные графические библиотеки приблизительно равнозначны, поэтому выбор остаётся за самим разработчиком. По сути дела, это никак не меняет качество будущего проекта.

Следующий шаг - продумывание будущей структуры графического движка. Нужно также определиться со стилем написания: будет ли это полностью процедурный или объектно-ориентированный стиль? ООП считается рациональным для написания действительно крупных проектов - свыше 100000 строк. Объектно-ориентированное программирование позволяет разделить код на независимые блоки с собственными переменными и методами (подпрограммами). Механизм наследования позволяет использовать уже существующие классы для построения новых. Приведу пример своего опыта - движок New Fantasy писался с применением и процедурного и объектно-ориентированного стиля. Разбиение на классы не всегда удобно. Иногда проще в коде написать просто DrawSky(x, y, z, r);, чем писать что-то такое:

var
Sky: TDirectSky;
...
Sky:=TDirectSky.Create;
Sky.Init;
Sky.Draw(x, y, z, r);

Здесь приведён пример для Delphi. В конкретно этом случае добней воспользоваться обычной процедуры, чтобы не загромождать код проекта. Но в некоторых случаях ООП более удобно. Например, лучше реализовать отдельный класс рендеринга ландшафта со внутренними переменными и методами. Это позволит изолировать этот участок кода от остальных. Да и механизмы наследования позволяют сделать несколько вариаций-наследников класса рендеринга территории.

Допустим, вы уже выбрали подходящий язык программирования, выбрали графическую библиотеку (Direct3D, OpenGL или решили писать свою), решили писать весь движок от и до самостоятельно. Если вас не пугает Collision Detection (проверка столкновений), AI (искусственный интеллект), реализация физики, визуализация всего этого (непосредственно графический движок), тогда давайте преступим к обсуждению, с чего же начать.

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

Следующий шаг - освоение графической библиотеки, её принципов. На поверхностное знакомство уходит от недели до месяца. Для программистов Delphi существуют отличные книги Михаила Краснова по OpenGL и DirectX, которые можно приобрести в ближайшем книжном магазине или заказать в Интернет-магазине. Стоит отметить, что OpenGL-код выглядит одинаково что в Visual Basic, что в Delphi, что в C++, чего не скажешь о DirectX.

И только после освоения конкретной графической библиотеки можно преступить непосредственно к написанию самого графического движка. Здесь уже на всё воля и фантазия самого разработчика. Обычно реализуют такие возможности как управление камерой, рендеринг территорий, загрузка моделек, небо, вода и т. д.

Если вам эта статья оказалась интересной, пишите в редакцию Игромании или мне на ящик ( onicolaev@yandex.ru ); если позитивных отзывов будет достаточно много, мы откроем цикл статей "Пишем свой графический движок с нуля".

Автор: Николаев Олег   e-mail: onicolaev@yandex.ru 

 

 

 

 Worlds3D by Nicolaev Oleg Copyright © 2005

© 2002-2005 , Nic Soft Arts All Rights Reserved

© 2005 , Dream Software All Rights Reserved

Дизайн: Студия web-mast www.igropad.narod.ru

Hosted by uCoz