Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Как принято проектировать логику на стороне сервера?

Как принято проектировать логику на стороне сервера?

ValedolПостоялецwww4 янв. 20183:49#0
Добрый день!
Меня интересует вопрос, в том, как обычно проектируют игровую логику, если игра сервер-ориентирована? Например игрок лишь получает координаты объектов и отправляет координаты кликов мыши, а клиент накладывает спрайты на объекты.
И в правильном ли направлении я двигаюсь? (см. ниже, под спойлером набросок схемы)

Интересует так же вопрос, как бы не изобретать велосипед. Что нынче есть для такой задачи?
В планах cocos2D юзать для клиента. А вот на сервере что юзать - не особо понимаю, из готового. Франкенштейна собирать из box2d (или самому физику пилить). Свою систему GameObject пилить или есть уже что-то готовое, свою или готовую state Machine и т.д.


Всю жизнь писал прикладное ПО, в основном для всякого оборудования, скада системы и прочее.
Я привык к классическому ООП подходу. Но понял что игры, это не программы с кнопками писать, при проектировании логики у меня начались откровенные абстрактные облака. А глубина наследования все только начало усложнять, плюс дублирование кода из за перекрестного функционала. Нашел в интернете "Game Programming Patterns", начал дробить все на компоненты. Но уже столкнулся со сложностью организации общения между компонентами.

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


Базовый набросок схемы. На нем уже прописана часть компонентов. Частично описан stateMachine и т.д.

+ Показать

TiendilУчастникwww4 янв. 201811:39#1
> как обычно проектируют игровую логику, если игра сервер-ориентирована
Не торопясь и по-разному. В зависимости от налагаемых ограничений: что за игра, какая нагрузка ожидается, какой бюджет, какая команда. Нет единственно правильного способа запилить хороший сервер.

>Нашел в интернете "Game Programming Patterns", начал дробить все на компоненты. Но уже столкнулся со сложностью организации общения между компонентами.
По-моему, там было написано как в таких случаях поступать :-)

>Что лучше. На прямую обращаться к компонентам, либо юзать систему событий в ущерб производительности?
Зависит от конкретной ситуации, нет единственно верного решения. Но в Game Programming Patterns должно быть более подробно рассписано про это.

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

>Базовый набросок схемы.
Смысла его смотреть без знания контекста нет.

ValedolПостоялецwww4 янв. 201813:15#2
Tiendil
> По-моему, там было написано как в таких случаях поступать :-)
Там написано было, что можно юзать command, observe, event, queuevent (по мере уменьшения связности). Но идеальная изоляция компонентов - это недостижимый идеал.

Tiendil
> По моему опыту лучше делать управляющие сущности
это как? Сущность имеет метод, который и управляет всеми компонентами.

Tiendil
> Смысла его смотреть без знания контекста нет.
Она вроде сама за себя говорит.
Есть gameengine, в котором запускается игровой цикл exec.
В нем есть ObjectPull, с методом update, вызываемый каждый тик
В ObjectPull лежат Object с методом update, вызываемый у каждого object.
Object - это и есть игровые сущности, в нем хранится unorder_map компонентов, где ключ - некий идентификатор типа компонента, для быстрого доступа и поиска по типу.
Компоненты говорят сами за себя. Исключение разве что Status, в который надо указывать StateMachine с паттерном ObjectType.

TiendilУчастникwww4 янв. 201813:46#3
>> По моему опыту лучше делать управляющие сущности
>это как?
Конкретные реализации могут быть разными, не всегда нужно даже классы-объекты делать. Главное чтобы связанность уменьшалась.

>Она вроде сама за себя говорит.
Абстратктная диаграмма абстрактной игры в вакууме. Я по ней не могу на 100% сказать это RTS или FPS (разве что могу предположить, что не пошаговая). Не говоря уже о том, что архитектура игры напрямую будет зависеть от размера карт, наличия автоподгрузки, количества динамических объектов на карте, наличия NPC, возможности NPC действовать согласованно, требований к качеству поиска пути и прочему.

А чтобы сделать бегающего по пустому пространству человечка любая архитектура пойдёт.

RikkПостоялецwww4 янв. 201814:24#4
Valedol
> , как обычно проектируют игровую логику, если игра сервер-ориентирована?
обычно по науке логике и проектируют.

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

Правка: 4 янв. 2018 14:25

MANABПостоялецwww4 янв. 201817:21#5
Хз как принято у других, я в  общий код dll для сервера и клента выношу игровую логику сущностей на уровне модели. Если надо пишу или прикручиваю физику. Все что надо по логике запускаю на сервере и на клиенте. Клиент шлет запросы типа дай мне инфу о моем персе, где я нахожусь, я хочу идти сюда, сервер это все считает и отдает результаты. Клиент рисует согласно состояниям моделей. По сути MVC
Sh.Tac.Постоялецwww4 янв. 201819:57#6
Valedol
> Сущность имеет метод, который и управляет всеми компонентами
не метод, но систему
были даже предложения считать системы first-class
In particular, Martin's work popularized the ideas of "Systems" as a first-class element, "Entities as ID's", "Components as raw Data", and "Code stored in Systems, not in Components or Entities".
https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system

> В ObjectPull лежат Object с методом update, вызываемый у каждого object.
ObjectPool наверное, но это не система, непонятно что она делает кроме хранения, и оно даже не cache-friendly

вообще вот тема:
http://www.gamedev.ru/code/forum/?id=232552

З.Ы. могу рассказать как я делал, хоть это и антинаучно : )

+ Показать

Правка: 4 янв. 2018 20:41

nonamezeroxПостоялецwww4 янв. 201821:14#7
Valedol
Начни с лагокомпенсации - это самая злободневная проблема для новичков и она напрямую влияет на играбельность. Читпруфная логика и прочие масштабируемые архитектуры будут играть роль лишь в случае эфемерного успеха твоего проекта.
innuendoПостоялецwww5 янв. 201814:51#8
Valedol

почитай доки UE4 про клиент-сервер

nonamezerox
> Начни с лагокомпенсации - это самая злободневная проблема для новичков

новичкам лагокомпенсацию ? пусть сначала просто сделает простой клиент-сервер

Правка: 5 янв. 2018 15:05

JerryLetehenПользовательwww7 янв. 201823:21#9
Изображение
Attak или Attack?

/ Форум / Программирование игр / Игровая логика и ИИ

2001—2018 © GameDev.ru — Разработка игр