Войти
ПроектыФорумОцените

Программирование 3D-движка для FPS (3 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#30
15:33, 19 авг. 2003

Джо

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


#31
15:51, 19 авг. 2003

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

Если ты считаешь, что движок это просто загрузчик БСП, моделей из Макса и проигрывание
скелетной анимации (а ну а, еще и физика - тоже левая, сейчас этого добра навалом), то ты почти прав.
Но просто дело в том, что это НЕ движок. Ну никак это не движок, а скорее лажа полная...

Движок должен уметь грузить еще и кучу разных графических форматов, поддерживать там текстуры
разных типов (DXT3, например). Он должен иметь свои форматы материалов, эффектов, частиц.
Помимо всего этого, движок - это набор классов и систем для работы с ГЕЙМПЛЕЙНЫМИ объектами,
SceneGraph и т.д. Попробуй создать систему добавления\удаления\управления игровыми
объектами через Сцену, чтоб все было гибко, не приходилось каждую мелочь в игре кодить отдельным набором ф-ий и т.д.
Чтоб работали системы взаимодействия объектов, триггеров, скриптов, игровых сообщений и ивентов... Да много чего еще!

Помимо всего прочего движок это также набор редакторов, инструментов для работы с игрой. Редаутор уровней,
редактор актеров, частиц, вьювер моделей, редактор скриптов, чтоб все это объединить вместе, и чтоб оно все работало
СТАБИЛЬНО и в то же время было гибким и легко-сопровождаемым...

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

#32
16:22, 19 авг. 2003

Resolver
Я сказал "Граф. движок в данном случае - это загрузчик и проигрыватель того что сделают моделлеры".
Граф. - это значит графический (движок). Речь не шла о физике, взаимодействии объектов, тригерах, скриптах, и уж боже упаси - геймплее. Речь шла только о выводе текстурированных полигонов с освещением, то есть те 80% всей графики.

Что касается "сделать за пару дней", ну если заморачиваться с библиотеками, классами, и прочим ООП, но на это много времени уйдет. Можно ограничиться простыми структурами описывающими объект и функцией читающей все фишки этого объекта (например, для установки state'ов графического API).

Если же говорить о "движке в целом", то тут работы конечно не мерянно, я с тобой полностью согласен. Один только редактор (даже проще - компоновщик ресурсов) можно пол года делать.

p.s.
Кажись DevIL может работать с пожатыми текстурами. В хедере там вроде че то было :)

#33
16:45, 19 авг. 2003

Вот так всегда - стоит выложить скрин, и сразу тема оживает :)
terror
>Сделать такое может один человек, за пару дней, без превлечения толпы программистов
<:O
Да там только кода столько, что если шуровать без перерыва, нужен только месяц на слепой набор. И на компиляцию пара дней как минимум.

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

Resolver
>Все правильно ты говоришь
Ну это только вода. Когда дело дойдёт до серьёзного - вот тут будет туго.

>просто красиво и правильно
>отстроенные уровни.
Конечно, тем более что никакие шейдеры не планируются (пока).

Я согласен с terror в том, что движок в большей своей части - это проигрыватель. Ну там, ввод и другой ран-тайм не в счёт. Основная идея такая - у нас навороченный редакторище, там мы моделируем игровой мир и задаём скрипты - например, откуда и куда едет лифт, задаём позиции источников звука и их звуковые файлы, моделим, анимируем, бацаем на скриптах AI. Scene Builder разбивает (octree) и компилирует сцену, записывает её в файл. Ну а движок - грузит всё это и запускает на выполнение, например, разбитая на подсцены сцена отсекается по алгоритму порталов.

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

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

#34
16:45, 19 авг. 2003

2terror

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

Ладно, не будем флеймить, пусть тред живет и, может через пол-года - год увидим еще один "свой" шутер ... 8)

#35
17:08, 19 авг. 2003

elf-nm
Ну, философия, это так, к слову. А ведение - как мы будем разрабатывать интерфейсы к объектам, как будем документировать код, согласовывать версии файлов, выкладывать в качалку и т. д.

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

Ну, например, вот ты используешь Direct3D, я OpenGL. Намылилсь мы писать multi api render, хотя это уже под вопросом, мы вдвоём а я надеялся на большее кол-во людей. Так вот, решили мы писать под оба API, ты D3D, я OGL. Ты думаешь, я буду вмешиваться в твой код? Ни-а. Мы разработаем общие элементы, а данном случае:

1) Названия файлов и классов
2) Набор идентичных приват-переменных в классах (bool m_valid, например)
3) Паблик-методы классов
4) Общее описание, что делает каждый метод класса.

Всё. Дальше каждый приступает к кодингу, сторого следуя разработанному интерфейсу. И вот тут каждого из нас абсолютно не колышет интернал-реализация классов другого. Ты пиши как знаешь, я пишу как знаю. Т. е:

1) Можешь определять свои дополнительные приват-переменные в классах
2) Добавлять в класс приват-методы, требуемые по специфике для данного API (Direct3D).

Главное - разработанный интерфейс неприкасаем.
Т. е., конечно, по ходу может выявиться, что мы чего-то не учли - обсуждается, документируется. Неважно, что ты там на<ш>кодил, интерфейс правильный. Это ведь и есть концепция чёрного ящика.

В общем, я не вмешиваюсь в твой код. Но если твои файлы у меня не компилятся или ошибка в процессе выполнения - извини брат, придётся конечно переделывать :(

В чём недосток такого подхода? Движок будет в той или иной мере напоминать Франкештейна, сшитого из разных лоскутков. НО! Этим надо пожертвовать - во имя той правды, что движок, пишущийся по умной схеме многими людьми, имеет гораздо больше шансов дожить до релиза, чем тот, что пишется в одиночку!

#36
17:08, 19 авг. 2003

Джо

-> топик 30

#37
23:05, 19 авг. 2003

elf-nm

-> топик 35

#38
8:58, 20 авг. 2003

http:/www.gamedev.ru/download/?id=142

Сделал первый набросок структуры, пока очень немного, но начинать надо.

#39
12:15, 20 авг. 2003

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

Ладно, док я скачал и посмотрел. Но ты бы лучше сюда писал мысли, а не в док.
Я не согласен с такой постановкой. Такое впечатление, что ты это выдрал из собственного движка и нате вам. Я тоже вот могу выдрать из своего и нате вам. И вообще в некотором смысле детский сад.

>DirectX – поддержка DirectX (в т.ч. рендерер)
>Engine – общие функции движка (ввод, лог-файл, консоль, счетчик FPS и т.п.)
>GEngine – реализация графического движка (без привязки к конкретному API)
>Math – реализация математических функций
>OpenGL – поддержка OpenGL (в т.ч. рендерер)
>Resource Files – иконки, курсоры и т.п.
Это называется короли и капуста :)

Например, при чём тут Engine к вводу , лог-файлу, консоли, а счётчик FPS это вообще отпад! Я как-то думал, что Engine это вся совокупность компонентов. А зачем нам Resource Files, мы же не MFC, упаси бог, юзать будем? Даже ещё не решили, будем ли писать через два API...

Двигаться надо П-О-Э-Т-А-П-Н-О. Т. е. необходимо начать с самого низа. Сначала - самая общая договорённость о движке (как пишем - ООП или нет, через оба граф. API или через один). Потом идёт разработка общей структуры. Затем, возможно, правила оформления кода  и наконец, приступаем к отдельным простейшим компонентам.

Ну ладно, возьмём твой док. Читаем:
>К именам файлов и классов добавлять префикс группы (DX, GE, GL) смысла нет, имена >классов пишем строчными и прописными буквами (читать проще), т.е. не DX_DXRENDERER, >а просто CDXRenderer (“C” – Microsoft приучил).
DX_DXRENDERER - слава богу, ты так не пишешь.
(“C” – Microsoft приучил) - а у тебя своя голова на плечах есть? Засунь технику Microsoft знаешь куда?

Лично я пишу так:
class GLRender
class D3DRender (не дх, дх это дх, а д3д это д3д)

>Файлы DirectX.h, DirectX.cpp
Это не так надо делать.

> private:
> IDirectInput8* m_lpDI;
> IDirectInputDevice8* m_lpDIKeyboard;

> unsigned char m_nKeys[256];
Хорошо, а если так:

private:

IDirectInput8 *m_di;
IDirrectInputDevice8 *m_keyboard;
byte m_keys[256];

>private:
> bool m_bLogEnabled; // признак “запись разрешена”
> char m_szFileName[256]; // имя файла
> FILE* m_fLogFile; // дескриптор файла
И так:

private:
bool m_valid;
char filename[80];
FILE *fp;

А вообще-то лог, еррор и консоль надо делать в виде обычных функций, что бы не было заморочек

g_log.add( "Ку-ку" );
а просто
Log( "Ку-ку" );

Так не хочется обсуждать эти вещи сейчас, но вынудил.

#40
13:09, 20 авг. 2003

лучше.
class thisobj
{
...
void Log(...);
}

thisobj::Log
{
g_log.add("%s: %s",ThisObjectName,ThisMessage);
}

...
Log("КУ-КУ");
вывод - Какойто обьект: Ку-Ку
логичнее?

#41
19:47, 20 авг. 2003

Джо, elf-nm
Здорова.

>> Вежливо попорошу без критики
А как таки обсуждать?
Другое дело, что там откровенно издевались.

Топик 23, 35 - respect
Приятно слушать умные вещи. Особенно если они совпадают с моими мыслями :)

Вместо того, чтобы подымать тему через $*#()$*@_()$(@ может посоветоваться с админом?


В общем если нихто не против, я connect.

И для затирки пару вопросов( в скобочках это мое предложение ):

1.

Программирование движка:
Целевая ОС( Microsoft Windws XP )
Тип: ( ANSI )
Tools( Microsoft Visual Studio 7.0 )
Базовые технологии( Win32, OpenGL(версия?, расширения?), DirectX 8, UML, музыка( DirectMusic vs EAX ), звук( DirectSound vs EAX ) )

Программирование utils:
Целевая ОС( Microsoft Windws XP )
Тип: ( ANSI )
Tools( Microsoft Visual Studio 7.0 )
Базовые технологии( Win32, MFC, XML/XSLT, UML ), в принципе ограничений при написании utils я не вижу. Но желательно чтобы эти самые utils использовали функции engine подсистем.

Форматы файлов: OGG vs MP3, WAVE, 3DS(text vs bin) vs Lightwave

2.
Предложение по базовым типам( я так понял начинаем с zero ):
// Unsigned base types
// *************************************************************************
typedef unsigned char    DB;   // 8-bit unsigned
typedef unsigned short    DW;   // 16-bit unsigned
typedef unsigned long    DD;   // 32-bit unsigned
typedef unsigned __int64  DQ;   // 64-bit unsigned

// Signed base types
// *************************************************************************
typedef signed char      SB;   // 8-bit signed
typedef signed short      SW;   // 16-bit signed
typedef signed int        SD;   // 32-bit signed
typedef signed __int64    SQ;   // 64-bit signed

// Other base types
// *************************************************************************
typedef void              VD; // Void
typedef signed int        BL; // 32-bit boolean 0 (false) or !=0 (true)
typedef float            FL; // 32-bit IEEE floating point
typedef double            DO; // 64-bit IEEE double

// Ansi( default )
typedef TCHAR            TH;  // Text char
typedef TH*              ST;  // String pointer

Венгерскую нотацию использовать очень не хотелось бы.
Я разъяряюсь от этих m_p_хрен_знает_что_Texture. :))

3.
Игровой движок понятие емкое. Предлагаю высказаться по поводу: какие фичи мы хотим реализовать посредством движка.

Так же предлгаю проанализировать вопрос:
Low level function stub как основа engine - надо или нет?

ЗЫ: Предлагаю вести некий журнал/лог проекта.

ЗЗЫ: И давайте что ли название придумаем проекту в самом деле.
Например проект Grom

elf-nm
На твой взгляд почему развалился GAMEdat?

#42
5:07, 21 авг. 2003

извиняюсь за реплику со стороны:

есть такая удобная вещь как ANSI sized types: __int16, __int32 и далее.

typedef uint08 unsigned char;
typedef uint16 unsigned __int16;
...
typedef uint128 unsigned __int128;

typedef sint08 signed char;
typedef sint16 signed __int16;
...
typedef sint128 signed __int128;

по-моему намного логичнее, сразу виден размер и полностью нейтрально и масштабируемо до произвольного размера данных. чем вспоминать, что такое SD и SQ. А 128 бит (хорош для SSE)? DDQ? DT?

Тип bool уже давным-давно поддержается всеми компиляторами. BOOL - отрыжка 80-х годов прошлого тысячелетия.

а венгерскую нотацию - на помойку! однозначно... m_ - сакс.


скалярные типы  - только строчными, макросы всеми прописными, сложные типы с заглавной, классы с префиксом c, C, t, T по вкусу. енумы с префиксом е, мемберы с маленькой буквы... Ну это один из вариантов стиля, дело ваше, конешно...

#43
13:25, 21 авг. 2003

Kashey
>логичнее?
Логика так и прёт. Для каждого метода определять собственную лог-функцию - зачем?

bool Material::Load( char *filename )
{
log( "Загрузка материала из файла %s", filename );
//...
}

Короткая запись и никакого гимора.

Altalert
>Другое дело, что там откровенно издевались.
Всякие люди есть. Кто-то говорит, что я шутник, кто-то доказывает, что нужны моделлеры, хотя я и не говорил, что они вообще не нужны.

>В общем если нихто не против, я connect.
Не против. Наконец-то кто-то знающий С++ присоединился. А то я бывший паскалист-процедурщик, сейчас штурмую особенности классов.

>И для затирки пару вопросов( в скобочках это мое предложение ):
Думаю, необоснованно повышать систребования неуместно.
Должно работать под 98 на 64-128 МБ памяти. Например, на моём компе XP сядет конкретно, так как он уже давно не новый. Если хочешь убить систребованиями проект... :)

Тулз - какой кому нравится, хоть 5. В качалке будут только имплементы и хедеры. Нужна совместимость. Лично я сижу на .NET, всё остальное неудобная тормозная гадость (IMHO).

>Базовые технологии( Win32, MFC, XML/XSLT, UML ),
Я тут даже половины словей не знаю, о каких технология речь? Сорри.
MFC - лучше уж редакторы писать на Delphi. Во всяком случае, я с MFC связываться не хочу (мне дорого моё время, чтобы тратить его на формирование серо-белых пикселей, из которых сделаны кнопки и менюшки). Если другие готовы взяться - юзаем MFC.

>typ! edef void VD; // Void
Вот тут бы объяснить поподробнее...

>ЗЗЫ: И давайте что ли название придумаем проекту в самом деле.
Ну, уж если с чего и начинать, так это с названия. Только не проекта, а движка.

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

Вопрос, что лучше:

LightMap g_lm; // Класс для расчёта карты теней для текущей
                        // подсцены

g_lm.Method1();
g_lm.Method2();
g_lm.Method3();
g_lm.Method4();
g_lm.Method5();
g_lm.Method6();

или так:

СLightMap *g_lpLightMap;

g_lpLightMap->Method1();
g_lpLightMap->Method2();
g_lpLightMap->Method3();
g_lpLightMap->Method4();
g_lpLightMap->Method5();
g_lpLightMap->Method6();

#44
15:42, 21 авг. 2003

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

Страницы: 1 2 3 4 5 6 7 Следующая »
ПроектыФорумОцените

Тема в архиве.