Padaboo

Как думаете иммет ли смысл шифровать пакеты например:
* Формат пакета клиента: [time,user_id/session_id,controller_id,skill9-target]
* Формат пакета клиента: [time,user_id/session_id,controller_id,barter-target]

• Формат пакета сервера: [time,кому,['object1','move' => 'xyz'],['object1' => 'object2','effect32']]

В формете грабить корованы "Архитектура"

Архитектура

• Клиент
• Сервер
• База данных
• Сайт

Клиент

• Посылает и принимате сообщения от сервера.
• Отображает графику и объекты
• Отображает интерфейс пользователя и диалоги

Сервер

• Принимает и отправляет сообщения.
• Осуществляет контроль версий клиента.
• Отвечает за безопасность.
• Игровая механика и взаимодействия игроков.
• Играет за монстров AI.
• Отвечает за целостность и сохранность данных.
• Держит необходимые данные в памяти и совершает репликации в базу
• Крон задачи
• Чат
• Бэкапы

Сайт

• Регистраци
• Авторизация
• Настройки
• Форум
• Новостная лента
• Медиа
• Админка
• Библиоткека
• Обратная связь

Админка

• Управление пользователями
• Обратная связь
• Управление новостями
• Управление бд

Особенности и узкие места

• Разделение логики:3д движок jmonkey,клиент-сервер.
• Сущьности и модели:3д движка,игровые сущьности, сущьности базы данных.
• Грид: для разделения на локации.
• Шаблон Observer: Для оповещения близконаходящихся объектов.
• Очередь сообщений: для оповещения клиентов.
• Сбор сообщений: сбор сообщений от близко находящихся игроков.
• Игровые вычисления: вычисление игровой механики для близко находящихся игроков и объектов
• Отправка: рассылка общего пакета с вычислениями для близко находящихся игроков и объектов
• Синглтон: создание единичного экземпляра объектаю
• Фабрика: для получения типовых объектов
• Абстракции: для определения полей и методов типовых классов.
• Модульность: 1)гибкость подгрузки вспомогательных классов. 2) разделение на модули. 3)роутинг.
• MVC: отделение логики базы данных, представления, и бизнес логки.
• AI монстров: модуль управления монстрами.
• DAO/ActiveRecord: 1) для работы с базой данных 2) ленивая загрузка
• Балансировка и масштабируемость: запуск нескольких экземпляров приложения, возможность запуска на разных физ машинах.
• Jar библиотеки, оптимизация.
• Сервер авторизации.

Игровые особеноости клиента и сервера

• Чат (отдельный демон принимающий и передающий очереди сообщений по тикам - таймеру)
• Инстансы (подземелья с отдельной логикой, с таймаутом посещения, физически отделены от общего игрового мира)
• Локации - грид (hex grid coordinates) - оповещение о действиях только рядом стоящих игроков и объектов
• БД: во время старта демона приложения делаются выборки из базы, все объекты находятся в памяти.
  во время авторизации игрока создается формирующий запрос в бд и создается объект игрока. Переодически демон сбрасывает данные обратно в бд и чистит память.
• Гвард: проверяет целостность данных клиента, проверяет code-injection, key-press, speed-hack,map hack,drop hack, подмену пакетов.
• Апдейтер: проверяет контрольные суммы файлов и папок, вычисляет разницу, заменяет и докачивает необходимые файлы.
• Установщик: ставит все необходимые библиотеки,создает папку назначает права, распаковывает архив или закачивает файлы, запускает апдейтер, запускает игру.

Дополнил идею
Многопользовательская онлайн игра – передача пакетов и обмен сообщеями между клиентами и сером(client-server,p2p,tcp/upd, графы)
Представьте себе многопользовательсукую игру по типу lineage

Описание процесса и поставновка задачи:

1)каждый игрок совершает действие у себя на клиенте и должен оповестить об этом игроков монстров и игровые объекты в определенном радиусе.
2) Игрок должен видеть 3d объекты и монстров только в опреденном радиусе.
3) Сервер выполяя действия за мир и монстров и оповещает об этом всех игроков или игроков в опреденном радиусе от объекта.
4) игрок монстры и сервер выполняя действия формируют сообщения или пакеты
5) формат игрового сообщения или пакета псевдокод

[player1,player2,server][time_stamp][client/server][geo_location][game_map_location][net_key][player_id][visible_radius]–
[player1,player2,server]Где каждый элемент это серриализованный объект
player[
actions[ [hit,player2,fireball],[run,vector],[rotate,radius] ],
player[param1,param2],
items[item1,item2],
message[string,chat],
gruops[clan,party],
time[time_stamp]
]

Если отправлять сообщения от клиентов на сервер и формировать большой пакет.

Проблемы:

1) Синхронизация игроков
2) Клиент серверная синхронизация
3) Низкая скорость передачи tcp/upd, низка скорость передачи clien-server
5) Обо всех пакетах должен знать только сервер,
6) Игроки находятся на разном расстоянии географически – что снижает скорость передачи
7) Необходимо посылать пакеты только соседним объектам
8) Пакеты могут потеряться, пакеты можно подменить

Варианты решения на уровне игры:
1) Двумерный массив [][] который соответсвует физической карте игрового мира
2) Добавление игровых объектов в этот массив
3) Добавление радиуса видимости для каждого объекта который может посылать пакеты
4) Объект посылает пакеты только объектам которые находятся в определенном радиусе от него
6) Формируются группы объектов
5) Один из объектов назначается главным
6) Каждый из группы объектов посылает каждому пакет
7) Создается эталонный пакет
8) Главный объект группы посылает всем эталонный пакет

Решение на уровне сети и сервер:
1)Берется карта мира и создается двумерный массив, ячейка содержит в себе информацию о регионе[country][city] и обо всех клиентах находящихся в регионе
2)По этим точкам строится граф и просчитываются кратчайшие пути до каждой точки
3)В каждом регионе выбирается несколько клиентов с самой высокой скоростью
4)Один из клиентов становится сервером передачи данных для всех остальных в регионе
5)Сервера региона передают сообщения по цепочке и по кратчайшему пути между собой и до сервера

1)Клиенты посы лают сообщения по таймауту
2)На сервере создается поток который формирует очереди сообщений
3)На главном сервере так же создается очередь сообщений

Доброго времени суток! В голову пришла мысль создать игру на Java, так как играть одному неинтересно - игра будет многопользовательска.
Движок выбран Jmonkey на базе jogl.
В голову приходит клиент серверная архитектура с небольшими поправками - из того что я нашел в интернете:
1. Клиент посылает сообщения на сервер.
2. Сервер их принимает и оповещает остальных игроков - изменение координат, нажатие клавиш, etc.

Тут у нас сходу появляется несколько проблем:
1. У всех разная скорость соединения нужно как то делать поправку на пинг, даже не знаю как можно сделать корректировку.
2. Непрерывный флуд, пользователи асинхронно посылают сообщения на сервер и при каждом сообщении нужно оповещать всех остальных игроков.
Решение: 1) посылать сообщения не каждый раз при нажатии, а по таймауту. 2) На сервере составлять очереди сообщений и высвобождать их одновременно, так же по таймауту.
3. Игрок нажал кнопку ходить и начал двигаться в определенном направлении у себя на клиенте, но сообщение еще не поступило на сервер и к другим игрокам тут у нас происходит рассинхронизация, пока сервер не будет оповещен и другие игроки не получат его новые действия и координаты с поправками.
Если кто то сталкивался с такими проблемами в играх или в подобных приложениях.
Подскажите направление решения задачи, какие еще проблемы могут встретится в подобной архитектуре. Спасибо.