Воскресенье, 15 Сентября 2019, 09:06

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 1 из 2
  • 1
  • 2
  • »
Форум игроделов » Программирование » Общие обсуждения программистов » Помогите развить архитектурное решение игрового движка (Моя вариация (data-centered + многослойка + mt) концепции)
Помогите развить архитектурное решение игрового движка
SaiteiДата: Воскресенье, 05 Октября 2014, 12:10 | Сообщение # 1
старожил
Сейчас нет на сайте
Захотел испытать судьбу и придумать что-то своё. Хотел бы услышать ваши пожелания и замечания...
Руль всего в моей архитектуре - базы данных. В чём достоинства и недостатки этого?

Достоинства:
1)Все системы движка независимы друг от друга - следовательно движок гибок
2)Раз уж системы независимы, то они могут работать в параллель (асинхронные потоки, идея многопоточности)
3)Когда мы работаем с той или иной системой, то мы не задумываемся о работе других систем. Мы просто работаем с информацией из таблиц в БД и знаем, что к той или иной информации может получить доступ другая система
4)Приятный бонус - SQL запросы. Они решают много головняка и будут нашими помощниками в дальнейшем : )
5)Нужная информация будет сохраняться даже после завершения работы программы
6)Движок получится куда меньше. Это связано с тем, что не надо больше ломать голову над проложением взаимосвязей систем.

Недостатки:
1)Новизна идеи. В движке можно запутаться, всегда в голове нужно держать чёткое понимание работы движка
2)Много SQL-запросов. Лично я не считаю что их будет много, но некоторые выразили своё мнение, мол вся система загнётся и лучше использовать СЯПы. Я же считаю, что запросов будет не так много + СЯПы будут сильнее давить на тормоз из-за виртуалки
3)Синхронизация. В некоторых ситуациях гонка потоков может привести к тому, что очень важная инфа не дойдёт к той или иной системе (попросту успеет перезаписаться)
4)Перед началом разработки игры или чего-нибудь ещё нужно подумать какая информация будет храниться в той или иной таблице

Меня больше всего пугает третий пункт недостатков. Думаю как это решить
XakepДата: Воскресенье, 05 Октября 2014, 14:34 | Сообщение # 2
めちゃくちゃちゃ
Сейчас нет на сайте
мне все же кажется лучший вариант многопоточности в играх - делать через job'ы. Вот есть статья хорошая по этому: click.
OpenGOOДата: Воскресенье, 05 Октября 2014, 16:58 | Сообщение # 3
почти ветеран
Сейчас нет на сайте
Saitei, ты бы схему приложил, а то в чем новизна твоей идеи непонятна.

Мои проекты:
- Свободный и открытый клон World Of Goo
- TrueEngine2D (2D игровой фреймворк основанный на FreeBASIC)

[GameMaker: Studio v1.4.1772]
SaiteiДата: Воскресенье, 05 Октября 2014, 17:33 | Сообщение # 4
старожил
Сейчас нет на сайте
OpenGOO, если очень грубо:

Вся фишка в независимости и гибкости. Можно даже удалить систему - и оно будет работать. Так же добавлять новые системы очень легко
vanvanichДата: Воскресенье, 05 Октября 2014, 17:46 | Сообщение # 5
почетный гость
Сейчас нет на сайте
Цитата Saitei ()
Вся фишка в независимости и гибкости. Можно даже удалить систему - и оно будет работать. Так же добавлять новые системы очень легко


Но платишь скоростью взаимодействия .


Сообщение отредактировал vanvanich - Воскресенье, 05 Октября 2014, 17:48
SaiteiДата: Воскресенье, 05 Октября 2014, 17:50 | Сообщение # 6
старожил
Сейчас нет на сайте
Цитата vanvanich ()
Но платишь скоростью взаимодействия .

Думаете, скорости не хватит?
OpenGOOДата: Воскресенье, 05 Октября 2014, 19:39 | Сообщение # 7
почти ветеран
Сейчас нет на сайте
Saitei, сколько будет запросов к бд за 1 цикл, например для логики?

Мои проекты:
- Свободный и открытый клон World Of Goo
- TrueEngine2D (2D игровой фреймворк основанный на FreeBASIC)

[GameMaker: Studio v1.4.1772]
VinchensooДата: Воскресенье, 05 Октября 2014, 19:44 | Сообщение # 8
Злобный социопат с комплексом Бога
Сейчас нет на сайте
По сути, схема стара как мир, только вместо разделяемой памяти вы хотите использовать sql. Или я не прав?

SaiteiДата: Воскресенье, 05 Октября 2014, 19:47 | Сообщение # 9
старожил
Сейчас нет на сайте
Vinchensoo, в зависимости от того, что вы называете разделяемой памятью : )
OpenGOO, можно ужать в 1 запрос) Ну а вообще зависит от игры, так-то
OpenGOOДата: Воскресенье, 05 Октября 2014, 20:30 | Сообщение # 10
почти ветеран
Сейчас нет на сайте
Цитата Saitei ()
OpenGOO, можно ужать в 1 запрос) Ну а вообще зависит от игры, так-то
Ну если так, то жду конкретной реализации )


Мои проекты:
- Свободный и открытый клон World Of Goo
- TrueEngine2D (2D игровой фреймворк основанный на FreeBASIC)

[GameMaker: Studio v1.4.1772]
OrdanДата: Понедельник, 06 Октября 2014, 02:33 | Сообщение # 11
Главный зомби
Сейчас нет на сайте
Цитата Saitei ()
1)Все системы движка независимы друг от друга - следовательно движок гибок

Для этого движок делают модульным и все.

Цитата Saitei ()
4)Приятный бонус - SQL запросы. Они решают много головняка и будут нашими помощниками в дальнейшем : )

В чем то да, в чем то делают новую головную боль.

Цитата Saitei ()
5)Нужная информация будет сохраняться даже после завершения работы программы

Это да но если работа прервалась во время заноса данных в таблицу, то запишутся не все данные.

Цитата Saitei ()
6)Движок получится куда меньше. Это связано с тем, что не надо больше ломать голову над проложением взаимосвязей систем.

Категорически не согласен, тут все зависит от навыков.

Цитата Saitei ()
1)Новизна идеи. В движке можно запутаться, всегда в голове нужно держать чёткое понимание работы движка

Свою превую игру (рпг) делал с использованием СУБД и по мне в модульном движке гораздо проще ориентироваться, меньше гемора и удобнее.

Цитата Saitei ()
2)Много SQL-запросов. Лично я не считаю что их будет много, но некоторые выразили своё мнение, мол вся система загнётся и лучше использовать СЯПы. Я же считаю, что запросов будет не так много + СЯПы будут сильнее давить на тормоз из-за виртуалки

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

Цитата Saitei ()
3)Синхронизация. В некоторых ситуациях гонка потоков может привести к тому, что очень важная инфа не дойдёт к той или иной системе (попросту успеет перезаписаться)

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

Цитата Saitei ()
4)Перед началом разработки игры или чего-нибудь ещё нужно подумать какая информация будет храниться в той или иной таблице

Геморно.

В целом могу сказать одно - геморно, под новую игру придется писать тонны новых запросов, создавать базу и тд. Чисто ради эксперимента почему бы и нет.
Saitei, На каком СУБД будешь делать базу?


Цитата недели: Из-за леса, из-за гор, кишки, месиво, хардкор. (Берсерк ТВ-2)

Мои проекты ТЫК
Мои видяхи на ютубэ ТЫК

Если ты споришь с идиотом, вероятно тоже самое делает и он.
SaiteiДата: Понедельник, 06 Октября 2014, 11:22 | Сообщение # 12
старожил
Сейчас нет на сайте
Ordan, встраиваемая СУБД: sqlite.
HPlusDieseДата: Понедельник, 06 Октября 2014, 12:35 | Сообщение # 13
участник
Сейчас нет на сайте
Цитата Saitei ()
Все системы движка независимы друг от друга - следовательно движок гибок

Это просто модульная структура. Так обычно всегда делают - абстрактный интерфейс каждой подсистемы, независимый от реализации.
Цитата Saitei ()
Раз уж системы независимы, то они могут работать в параллель (асинхронные потоки, идея многопоточности)

Сейчас это должно быть главной идеей. Как будет многопоточность реализована? И чем это лучше концепции job,ов?

Saitei, Я думаю, что выйдет бяка из-за главной идеи - бд.
Слишком большая абстракция и полная независимость систем вдарят по производительности.
SaiteiДата: Понедельник, 06 Октября 2014, 12:42 | Сообщение # 14
старожил
Сейчас нет на сайте
Цитата HPlusDiese ()
Это просто модульная структура. Так обычно всегда делают - абстрактный интерфейс каждой подсистемы, независимый от реализации.

Можете на примере показать модульную структуру?
HPlusDieseДата: Понедельник, 06 Октября 2014, 13:16 | Сообщение # 15
участник
Сейчас нет на сайте
Цитата Saitei ()
Можете на примере показать модульную структуру?

А что тут собственно показывать?
Есть у нас, допустим, абстрактный рендер:
Код
class Render
{
public:
           virtual bool Init() = 0;
           virtual void RenderFrame() = 0;
           virtual void ShutDown() = 0;
};


Его конкретная реализация(например, ogl рендер):
Код
class RenderOGL
{
public:
           bool Init()
           {
               //Инициализируем(создаём контекст и т.д.)
           }
           void RenderFrame()
           {
               //Рисуем кадр.
           }
           void ShutDown()
           {
               //Чистим за собой.
           }
};


Затем в коде, при старте приложения, создаём нужную реализацию и работаем только с абстрактным интерфейсом:
Код
Render* render = new RenderOGL(); //Лучше класс синглетоном сделать
render->Init();
while(true)
{
render->RenderFrame();
}
render->ShutDown();
delete render;


Ну, как-то так.


Сообщение отредактировал HPlusDiese - Понедельник, 06 Октября 2014, 14:53
OpenGOOДата: Понедельник, 06 Октября 2014, 13:31 | Сообщение # 16
почти ветеран
Сейчас нет на сайте
Пример: герой наступил на бомбу, теперь нужно как минимум 2 запроса, чтобы услышать звук взрыва. Зачем логика и звуковой движок должны общаться между собой через такого медленного посредника?

Saitei, какую задачу ты решаешь, чтобы тебе понадобилась так использовать SQL DB?


Мои проекты:
- Свободный и открытый клон World Of Goo
- TrueEngine2D (2D игровой фреймворк основанный на FreeBASIC)

[GameMaker: Studio v1.4.1772]


Сообщение отредактировал OpenGOO - Понедельник, 06 Октября 2014, 13:34
HPlusDieseДата: Среда, 08 Октября 2014, 17:48 | Сообщение # 17
участник
Сейчас нет на сайте
Второй момент:
Цитата Saitei ()
СЯПы будут сильнее давить на тормоз из-за виртуалки

Ошибочное мнение. Хотя с твоей архитектурой выйдет огромный оверхед.
Большинство движков имеют примерно такую структуру(если не считать зависимостей модулей между собой.):

|-->->->--Core
|
|--<-<-<--Render
|--<-<-<--Sound
|--<-<-<--Logic--<-<-<--Scripting
|--<-<-<--Physics
|--<-<-<--Input

Модули взаимодействуют между собой через ядро.
Saitei, Почитай литературу по архитектуре игровых движков(да, есть такие книжки).
Вот ещё неплохой пример полной архитектуры движка:
C4 Engine Architecture

Добавлено (08.10.2014, 17:48)
---------------------------------------------
Saitei, Куда пропал? Какие изменения в архитектуре будут?

Сообщение отредактировал HPlusDiese - Понедельник, 06 Октября 2014, 15:03
wcptДата: Среда, 08 Октября 2014, 23:03 | Сообщение # 18
постоянный участник
Сейчас нет на сайте
помню, когда писал для огл, пытался запихнуть в класс всё нужное для рисования. Программа крашилась при собственно рисовании. Так и не понял, почему. Давно было.

Сообщение отредактировал wcpt - Среда, 08 Октября 2014, 23:04
HPlusDieseДата: Среда, 08 Октября 2014, 23:12 | Сообщение # 19
участник
Сейчас нет на сайте
Цитата wcpt ()
помню, когда писал для огл, пытался запихнуть в класс всё нужное для рисования. Программа крашилась при собственно рисовании. Так и не понял, почему. Давно было.

Как это к теме относится?
wcptДата: Среда, 08 Октября 2014, 23:15 | Сообщение # 20
постоянный участник
Сейчас нет на сайте
Цитата HPlusDiese ()
Как это к теме относится?

никак, просто вспомнил sad


Сообщение отредактировал wcpt - Среда, 08 Октября 2014, 23:15
Форум игроделов » Программирование » Общие обсуждения программистов » Помогите развить архитектурное решение игрового движка (Моя вариация (data-centered + многослойка + mt) концепции)
  • Страница 1 из 2
  • 1
  • 2
  • »
Поиск:

Все права сохранены. GcUp.ru © 2008-2019 Рейтинг