Re: Архитектура ИГРОВОГО движка
От: Forrest_Gump  
Дата: 20.06.06 16:30
Оценка:
Здравствуйте, alx771103, Вы писали:

A>Привет всем!


A>Я в этом деле новенький, но хотел бы (чиста, хобби) написать свой игровой движок... А идеи как это сделать — закончились...


A>Как бы так разбить движок на модули, чтобы при переходе на другую платформу не пришлось переписывать почти всё с нуля?..


A>Если есть идеи (или, еще лучше, проверенные идеи), пожалуйста, поделитесь...


Tim Sweeney "Building a Flexible Game Engine: Abstraction, Indirection, and Orthogonality"
Re[2]: Архитектура ИГРОВОГО движка
От: Forrest_Gump  
Дата: 20.06.06 21:52
Оценка:
Объектная система игры (игровой "движок")
Автор: Forrest_Gump
Дата: 26.01.04

http://www.gamearchitect.net/Other/archive.html

Как понять исходники Quake ?
Автор: Forrest_Gump
Дата: 25.01.05

http://developer.valvesoftware.com/wiki/SDK_Docs
http://wiki.beyondunreal.com/wiki/Unreal_Engine
Re[14]: Архитектура ИГРОВОГО движка
От: Аноним  
Дата: 21.06.06 06:54
Оценка:
Здравствуйте, neFFy, Вы писали:

FF>зачем Suspended?.


А, затем, чтобы, например, под Виндами, неактивное приложение не отъедало процессорное время.

FF>как я бы сделал а что то уже было

FF>есть стартовая функция main, в которой основной цикл.. которая создает
FF>я бы не стал делать один класс Platform, который работает с платформой, а вынес бы каждую деталь (видео, управление, звук, етк..) в одтельные классы.. они бы все вместе предоставляли некий API(вроде WTL) для работы всех остальных низкоуровневых классов..
FF>Например, Graph, Input, Sound/Audio.. каждый из этих классов был бы оберткой над различными низкоуровневыми библиотеками..
FF>почему несколько?. например OpenGL не дает работы со звуком.. нужно OpenAl или SDL например.. да и для управления какой нить glut.. это в DirectX удобно, а вдруг что..

Опять непонятка: до графики, звука, физики и логики я пока в своих разговорах не дошел... Это понятно, что графика, звук и т.д. и т.п. — отдельные модули. Опять же, некоторые классы этих модулей будут платформозависимы и связаны с Platform (для получения какой-то системной информации)...

FF>можно сделать Kernel, но имхо это некритично.. Kernel будет содержать в себе Sound и Input..А Graph..


Нет, нет и нет. Наверное, я объясняю как-то коряво ... Kernel содержит в себе основной цикл и всё... То есть, после запуска (пресловутый метод run), в его задачи входит вычислять (с использованием Platform, конечно) прирост времени (timeDelta) и запускать обновление каждого из модулей: Video, Audio, Physics, Logic, ... (последовательность неправильная)

FF>имхо можно сделать класс "Сцена"/View, которая будет содержать в себе Graph и сама обрабатывать всё видео..

FF>потом вынести работу с этими классами в отдельные потоки, и аналогами Running, Stopped будут критические секции.. имхо полностью останавливать цикл, чтобы обработать всю новую инфу не стоит..

А вот если правильно модули разработать, то и реализовать их можно в виде отдельных потоков (думал об этом, но не глубоко: смутно себе синхронизацию представляю)...

FF>не знаю точно.. но можно было бы попробовать создать свою подсистему обработки высокоуровневых сообщений..

FF>например, игрок ткнул на юнит, сообщение создалось (юнит ид, состояние: ткнут ), в главном цикле выбрали сообщение и передали в Graph и Sound.. юнит выделился и сказал что нибудь но это не для экшенов

FF>вот примерно моё видение.. вопросы принимаются


У-у-у... Это для меня еще далеко очень...
Re[15]: Архитектура ИГРОВОГО движка
От: neFFy Россия  
Дата: 21.06.06 08:17
Оценка:
Здравствуйте, Аноним, Вы писали:

FF>>зачем Suspended?.

А>А, затем, чтобы, например, под Виндами, неактивное приложение не отъедало процессорное время.

а оно вроде и так не должно отъедать..отрисовка точно не должна..

А>Опять непонятка: до графики, звука, физики и логики я пока в своих разговорах не дошел... Это понятно, что графика, звук и т.д. и т.п. — отдельные модули. Опять же, некоторые классы этих модулей будут платформозависимы и связаны с Platform (для получения какой-то системной информации)...


мне просто непонятен смысл создания Platform, который будет один(насколько я понял) работать с платформой..

FF>>можно сделать Kernel, но имхо это некритично.. Kernel будет содержать в себе Sound и Input..А Graph..

А>Нет, нет и нет. Наверное, я объясняю как-то коряво ...

нее.. это я не понимаю.. еще пара десятков сообщений и я соображу..

А>Kernel содержит в себе основной цикл и всё... То есть, после запуска (пресловутый метод run), в его задачи входит вычислять (с использованием Platform, конечно) прирост времени (timeDelta) и запускать обновление каждого из модулей: Video, Audio, Physics, Logic, ... (последовательность неправильная)


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

FF>>потом вынести работу с этими классами в отдельные потоки, и аналогами Running, Stopped будут критические секции.. имхо полностью останавливать цикл, чтобы обработать всю новую инфу не стоит..

А>А вот если правильно модули разработать, то и реализовать их можно в виде отдельных потоков (думал об этом, но не глубоко: смутно себе синхронизацию представляю)...

а зачем останавливать весь основной цикл?.
...coding for chaos...
Re[16]: Архитектура ИГРОВОГО движка
От: alx771103  
Дата: 21.06.06 08:40
Оценка:
Здравствуйте, neFFy, Вы писали:

FF>а оно вроде и так не должно отъедать..отрисовка точно не должна..


То есть как это не должно? Еще как отъедает... И если вовремя не оповестить тот же класс для работы с графикой (подрузамеваю винды) о том, что приложение стало неактивным, можно схватить немало ошибок в процессе отрисовки...
Уже не говоря об обстановке в игре: компьютерные вражины не будут знать о том, что надо подождать пока игрок вернется...

FF>мне просто непонятен смысл создания Platform, который будет один(насколько я понял) работать с платформой..


Не один: и графика, и звук, и пользовательский ввод будут тоже обращаться к платформе, но по-своему... Задача Platform обеспечить обмен сообщениями Kernel и ОС.

FF>а как он будет обращаться к модулям для обновления?.


Да метод какой-нибудь update вызывать с параметром...

FF>и вообще нафига целый класс с таким "сильным" названием, если он практически ничего не делает?.


А как? Тот самый while (Running) вложить в WinMain?

FF>а зачем останавливать весь основной цикл?.


Ну, то есть как это? Ведь у программы должен быть конец ...
Re[17]: Архитектура ИГРОВОГО движка
От: neFFy Россия  
Дата: 21.06.06 09:36
Оценка:
Здравствуйте, alx771103, Вы писали:

FF>>а оно вроде и так не должно отъедать..отрисовка точно не должна..

A>То есть как это не должно? Еще как отъедает... И если вовремя не оповестить тот же класс для работы с графикой (подрузамеваю винды) о том, что приложение стало неактивным, можно схватить немало ошибок в процессе отрисовки...

девайс же отключается вроде..

A>Уже не говоря об обстановке в игре: компьютерные вражины не будут знать о том, что надо подождать пока игрок вернется...


я просто не сталкивался в виндах с проблемой остановки..

FF>>мне просто непонятен смысл создания Platform, который будет один(насколько я понял) работать с платформой..

A>Не один: и графика, и звук, и пользовательский ввод будут тоже обращаться к платформе, но по-своему... Задача Platform обеспечить обмен сообщениями Kernel и ОС.

например?.

FF>>а как он будет обращаться к модулям для обновления?.

A>Да метод какой-нибудь update вызывать с параметром...

но все равно экземпляры классов будут принадлежать классу Kernel..

FF>>и вообще нафига целый класс с таким "сильным" названием, если он практически ничего не делает?.

A>А как? Тот самый while (Running) вложить в WinMain?

а почему бы и нет?.
я, чтобы не загромождать main, выносил в отдельную функцию..

FF>>а зачем останавливать весь основной цикл?.

A>Ну, то есть как это? Ведь у программы должен быть конец ...

всмысле зачем состояние Stopped ??.
...coding for chaos...
Re[18]: Архитектура ИГРОВОГО движка
От: alx771103  
Дата: 21.06.06 09:58
Оценка:
Здравствуйте, neFFy, Вы писали:

FF>девайс же отключается вроде..


Какой из них?

FF>я просто не сталкивался в виндах с проблемой остановки..


ALT-TAB

FF>например?.


Suspend/Resume

FF>но все равно экземпляры классов будут принадлежать классу Kernel..


Не очень понял...

FF>а почему бы и нет?.

FF>я, чтобы не загромождать main, выносил в отдельную функцию..

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

FF>всмысле зачем состояние Stopped ??.


Как альтернатива Running...
Re[19]: Архитектура ИГРОВОГО движка
От: neFFy Россия  
Дата: 21.06.06 11:43
Оценка:
Здравствуйте, alx771103, Вы писали:

FF>>девайс же отключается вроде..

A>Какой из них?

видео.. его потом и ресетить надо..

FF>>я просто не сталкивался в виндах с проблемой остановки..

A>ALT-TAB

всмысле у меня не продолжалось выполнение..

FF>>но все равно экземпляры классов будут принадлежать классу Kernel..

A>Не очень понял...

всмысле они у него будут членами..

FF>>а почему бы и нет?.

FF>>я, чтобы не загромождать main, выносил в отдельную функцию..
A>Идея глобальных функций мне не очень нравится...

а идея создания одного класса, который по сути заменяет эту функцию и ничего больше не делает, лучше??.
функция сделана лишь для удобства.. и ничего крамольного я в этом не вижу..
...coding for chaos...
Re[20]: Архитектура ИГРОВОГО движка
От: alx771103  
Дата: 21.06.06 12:44
Оценка:
Здравствуйте, neFFy, Вы писали:

FF>видео.. его потом и ресетить надо..


Это DirectX видимо... Ага, надо... А как ты определяешь момент, когда его надо ресетить?

FF>всмысле у меня не продолжалось выполнение..


Недостаток знаков препинания меня ввел в состояние ступора...
Попробуй так: запускаешь TaskManager, запускаешь прогу, даешь её немного поработать, затем ALT-TAB и в TaskManager смотришь...

FF>всмысле они у него будут членами..


Неее... у него указатели на интерфейсы... А классы — потомки интерфейсов... Причем интерфейс простой. Что-то типа:

class Process
{
    public:
        void    update( Double ) = 0;
};


FF>функция сделана лишь для удобства.. и ничего крамольного я в этом не вижу..


Лучше: есть еще конструктор/деструктор ...
Re[21]: Архитектура ИГРОВОГО движка
От: FR  
Дата: 21.06.06 13:21
Оценка:
Здравствуйте, alx771103, Вы писали:

A>Здравствуйте, neFFy, Вы писали:


FF>>видео.. его потом и ресетить надо..


A>Это DirectX видимо... Ага, надо... А как ты определяешь момент, когда его надо ресетить?


IDirect3DDevice9::TestCooperativeLevel
Re[22]: Архитектура ИГРОВОГО движка
От: alx771103  
Дата: 21.06.06 13:31
Оценка:
Здравствуйте, FR, Вы писали:

FR>IDirect3DDevice9::TestCooperativeLevel


То есть, на каждый проход основного цикла такую проверку выполнять?
Re[23]: Архитектура ИГРОВОГО движка
От: FR  
Дата: 21.06.06 13:35
Оценка:
Здравствуйте, alx771103, Вы писали:

A>Здравствуйте, FR, Вы писали:


FR>>IDirect3DDevice9::TestCooperativeLevel


A>То есть, на каждый проход основного цикла такую проверку выполнять?


Да.
Re[24]: Архитектура ИГРОВОГО движка
От: alx771103  
Дата: 21.06.06 13:55
Оценка:
Здравствуйте, FR, Вы писали:

FR>Да.


То есть, если приложение теряет эксклюзивный уровень, ты приостанавливаешь работу и ждешь, пока уровень не восстановиться?

Хорошо, а завтра тебе нужно будет переписать все под OGL и что будешь делать?
Re[25]: Архитектура ИГРОВОГО движка
От: neFFy Россия  
Дата: 21.06.06 14:01
Оценка:
Здравствуйте, alx771103, Вы писали:

FR>>Да.

A>То есть, если приложение теряет эксклюзивный уровень, ты приостанавливаешь работу и ждешь, пока уровень не восстановиться?

в некоторых игрушках его не восстанавливают вроде в Корсарах2 такое было.. на этом можно было читерить

A>Хорошо, а завтра тебе нужно будет переписать все под OGL и что будешь делать?


для этого и я предлагал работу с графикой обернуть во что нибудь свое.. чтобы можно было менять..
...coding for chaos...
Re[21]: Архитектура ИГРОВОГО движка
От: neFFy Россия  
Дата: 21.06.06 14:11
Оценка:
Здравствуйте, alx771103, Вы писали:

A>Недостаток знаков препинания меня ввел в состояние ступора...

A>Попробуй так: запускаешь TaskManager, запускаешь прогу, даешь её немного поработать, затем ALT-TAB и в TaskManager смотришь...

запустил TaskManager, запустил StarCraft.. дал поработать.. нажал ALT-TAB и посмотрел в TaskManager.. тишина.. я опять что то не так сделал? надо попробовать с начальными проектами..

FF>>всмысле они у него будут членами..

A>Неее... у него указатели на интерфейсы... А классы — потомки интерфейсов... Причем интерфейс простой.

разница не критична.. кстати, а сами эти классы где будут созданы?.
но я всё равно не понял смысл создания класса для основного цикла..

FF>>функция сделана лишь для удобства.. и ничего крамольного я в этом не вижу..

A>Лучше: есть еще конструктор/деструктор ...

и что?.
ну каждому своё, но одна функция это всё таки не нарушение всех норм и канонов
...coding for chaos...
Re[22]: Архитектура ИГРОВОГО движка
От: alx771103  
Дата: 21.06.06 14:39
Оценка:
Здравствуйте, neFFy, Вы писали:

FF>запустил TaskManager, запустил StarCraft.. дал поработать.. нажал ALT-TAB и посмотрел в TaskManager.. тишина.. я опять что то не так сделал? надо попробовать с начальными проектами..


То есть совсем тишина? Даже когда StarCraft крутился? Не может быть!..

FF>разница не критична.. кстати, а сами эти классы где будут созданы?.


Разница как раз очень критична: одно дело — объекты конечных классов (в которых через один — вызовы платформозависимых функций) и другое — указатели на объекты, причем создаются они снаружи, и передаются Kernel... Таже функция MAIN и может их создавать...

FF>но я всё равно не понял смысл создания класса для основного цикла..


Да вот я пятой точкой чувствую, что класс — правильно, а функция — нет... А словами объяснить не могу... Пусть это моим капризом будет, ОК?

А слова подберу — тогда и объясню все ...
Re[26]: Архитектура ИГРОВОГО движка
От: alx771103  
Дата: 21.06.06 14:41
Оценка:
Здравствуйте, neFFy, Вы писали:

FF>для этого и я предлагал работу с графикой обернуть во что нибудь свое.. чтобы можно было менять..


А что делать, если библиотека, под которую ты затачиваешь графику не предоставляет средств контроля потери уровня кооперации. Что, если ты не сможешь определить эксклюзивный у тебя уровень или нет?
Re[25]: Архитектура ИГРОВОГО движка
От: FR  
Дата: 21.06.06 14:53
Оценка:
Здравствуйте, alx771103, Вы писали:

A>Здравствуйте, FR, Вы писали:


FR>>Да.


A>То есть, если приложение теряет эксклюзивный уровень, ты приостанавливаешь работу и ждешь, пока уровень не восстановиться?


Лучше всего приостанавливать только расчет игры и отрисовку, цикл обработки сообщений должен крутится, ну и чтобы не кушало процессор сунуть Sleep(1)

A>Хорошо, а завтра тебе нужно будет переписать все под OGL и что будешь делать?


Переопределю одну виртуальную функцию.

Но дам совет, никогда ни делай фичи на "будущее" просто утонешь. Или сразу пиши хотя бы под пару целевых платформ или забудь о кроссплатформенности.
Re[26]: Архитектура ИГРОВОГО движка
От: alx771103  
Дата: 21.06.06 15:06
Оценка:
Здравствуйте, FR, Вы писали:

FR>Лучше всего приостанавливать только расчет игры и отрисовку, цикл обработки сообщений должен крутится, ну и чтобы не кушало процессор сунуть Sleep(1)


На мой взгляд, должен крутиться цикл обработки сообщений от платформы... А платформа решит, размораживать основной цикл или нет... А вызов Sleep, что он дает?

А звук тормозить не надо? А если что-то еще?

FR>Переопределю одну виртуальную функцию.


А как быть с эксклюзивностью-то по которой ты определаешь: спать или нет... У тебя, мне видится, одна из систем берет и тормозит все, когда её в голову взбредет... А если ты в разные потоки все пораскидаешь?

FR>Но дам совет, никогда ни делай фичи на "будущее" просто утонешь. Или сразу пиши хотя бы под пару целевых платформ или забудь о кроссплатформенности.


Я, наверное, очень неопытный еще... Но как количество платформ влияет на проектирование?

И какие, на твой взгляд, фичи я пытаюсь заложить на будущее?
Re[27]: Архитектура ИГРОВОГО движка
От: FR  
Дата: 21.06.06 15:25
Оценка:
Здравствуйте, alx771103, Вы писали:

A>Здравствуйте, FR, Вы писали:


FR>>Лучше всего приостанавливать только расчет игры и отрисовку, цикл обработки сообщений должен крутится, ну и чтобы не кушало процессор сунуть Sleep(1)


A>На мой взгляд, должен крутиться цикл обработки сообщений от платформы... А платформа решит, размораживать основной цикл или нет... А вызов Sleep, что он дает?


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

A>А звук тормозить не надо? А если что-то еще?


Звук восстанавливать только надо, но это можно отдельно сделать вне цикла.

FR>>Переопределю одну виртуальную функцию.


A>А как быть с эксклюзивностью-то по которой ты определаешь: спать или нет... У тебя, мне видится, одна из систем берет и тормозит все, когда её в голову взбредет... А если ты в разные потоки все пораскидаешь?


Тормозит ни когда в голову взбредет а тогда когда нужно.
В разные потоки я раскидывать не буду, мне гемморой на пустом месте не нужен.

FR>>Но дам совет, никогда ни делай фичи на "будущее" просто утонешь. Или сразу пиши хотя бы под пару целевых платформ или забудь о кроссплатформенности.


A>Я, наверное, очень неопытный еще... Но как количество платформ влияет на проектирование?


A>И какие, на твой взгляд, фичи я пытаюсь заложить на будущее?


Мне показалось что ты хочешь писать под одну платформу а в будущем дописать — портировать на другие. Если тебе охота пройтись по всем граблям то именно так и делай. Иначе или пиши только под одну платформу или если действительно нужны несколько, пиши сразу под все, обязательно учитывая все их тонкости, и постоянно делая сборки и тесты под каждую.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.