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

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

#0
3:49, 4 янв. 2018

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

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


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

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


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

+ Показать


#1
11:39, 4 янв. 2018

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

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

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

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

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

#2
13:15, 4 янв. 2018

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

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

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

#3
13:46, 4 янв. 2018

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

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

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

#4
14:24, 4 янв. 2018

Valedol
> , как обычно проектируют игровую логику, если игра сервер-ориентирована?
обычно по науке логике и проектируют.

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

#5
17:21, 4 янв. 2018

Хз как принято у других, я в  общий код dll для сервера и клента выношу игровую логику сущностей на уровне модели. Если надо пишу или прикручиваю физику. Все что надо по логике запускаю на сервере и на клиенте. Клиент шлет запросы типа дай мне инфу о моем персе, где я нахожусь, я хочу идти сюда, сервер это все считает и отдает результаты. Клиент рисует согласно состояниям моделей. По сути MVC

#6
19:57, 4 янв. 2018

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

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

+ Показать

#7
21:14, 4 янв. 2018

Valedol
Начни с лагокомпенсации - это самая злободневная проблема для новичков и она напрямую влияет на играбельность. Читпруфная логика и прочие масштабируемые архитектуры будут играть роль лишь в случае эфемерного успеха твоего проекта.

#8
14:51, 5 янв. 2018

Valedol

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

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

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

#9
23:21, 7 янв. 2018
Изображение

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

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