Pull to refresh

Пьеса «Разработка многопользовательской сетевой игры.» Часть 1: Архитектура

Reading time 3 min
Views 21K
image

Часть 2: Протокол
Часть 3: Клиент-серверное взаимодействие
Часть 4: Переходим в 3D

В общем, как и обещал, публикую серию статей по разработке многопользовательской сетевой игры. Изначально я хотел просто накатать статейку по разработке серверной части на интересном языке Scala. Но понял, что одной статейкой для развертывания темы не получится обойтись. А писать очередной топик обо всем и ни очем, не хотелось изначально. Поэтому встречайте пьесу в трех действиях. В течении которой мы разработаем архитектуру проекта, реализуем серверную и клиентскую части…
Все помнят прикольные танчики на денди?
Ну вот на примере этих танчиков и будем разрабатывать сервер и клиент.



Для любителей халявы и жестких копипастеров сразу скажу, что полных исходных кодов не будет. Буду выкладывать только отдельные интересные(сложные?) моменты как сервера так и клиента.

Итак приступим дорогие зрители.
В процессе нашего повествования вы окунетесь в мир технологий сетевых игр… познаете сладкий плод запретного scala кода и получите возможность вкусить кодинг под flash… и в качестве финального действия попробуем устроить хабраэффект готовому проекту, который я запущу на отдельном сервере для проверки получившейся архитектуры на реальном железе.

Часть первая. Действие первое: Общее описание проекта.


Распишем по порядку что же мы будем делать.

Так как перед нами не стоит задача сделать свой BigWorld (это движок такой для тех кто не в курсе) и мы делаем прототип, то упрощаем себе задачу везде где только возможно. Ибо наша основная задача показать как вообще разрабатываются сетевые игры. На конкретном, работающем примере. А не сделать готовый коммерческий продукт.

Задача: Сетевая игра типа «танчики на денди». Клиентская часть на Flash, сервер на Scala. Соединение через сокеты. Дабы убрать многие заморочки будем делать асинхронный сервер по принципу «Кто раньше встал — того и тапки».

Что в общем случае подразумевается под клиент серверным взаимодействием в игре?
1. Логин пользователя
2. Обмен с сервером (Отправка команды от клиента к серверу, Получение ответа на команду от сервера, Получение команды от сервера)
3. Адиминская часть управления сервером

Логин пользователя — это первичная аутентификация в игре. Мы делаем все по простому и проверка будет идти только на этапе логина. А вообще авторизацию надо периодически проверять в игре на всякий пожарный от читеров. При первом входе с новым логином игра заносит его в базу вот и вся регистрация.

Админская часть — тоже примитивная. Будем отображать список пользователей онлайн. Пригодится для нагрузочного тестирования.

Обмен с сервером — это и есть протокол игры. Его распишем когда будем делать реализацию сервера.

Сервер

В реализации сервера не будем заморачиваться ни с какими синхронными вариантами синхронизации клиентов ( воспроизведение истории, предсказание и т. д. и т. п. ). (Вот это я загнул — синхронная синхронизация… — прим. автора)
Т.е. Принцип очень простой. Меряем пинг до клиента и таким образом знаем задержку каждого клиента. Это позволяет нам убрать влияние клиентов с плохим соединеним на всю игру да и реализация проще чем у синхронных вариантов. Да, при таком варианте возможен вариант, когда пинг очень долгий, получить слайд шоу. Но при этом все корректно будет обрабатываться. И слайд шоу будет только у клиентов с большим пингом. В нагрузку получим необходимость хранить актуальное значение пинга для каждого клиента.

С общим описанием проекта все вроде ясно.

Часть первая. Действие второе: Архитетура сервера.



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

Общая схема получается такая:



В общем делаем по классической схеме с пулом тредов. Игра у нас простая, физики в ней нет никакой, да и вообще расчетов на сервере мало.

Общая логика работы сервера получается такая.
1. Получаем от клиента запрос авторизации.
2. Рандомно выдаем координаты появления танка на карте.
3. Клиент шлет свои координаты на сервер с какой-то периодичностью (Во время движения чаще).
4. При выстреле на сервер отсылаются координаты точки откуда он произошел.
5. Сервер вычисляет полет снаряда и решает есть попадание или нет.
6. Так же во время движения сервер определяет препятствия. И не дает двигаться танку в этом направлении.
7. По запросу клиента сервер передает количество клиентов онлайн.

Вот в общем-то и все что задумано.

В дальнейшем, если хабровчанам будет интересно эту схему можно расширить до нормальной архитектуры с разнесением частей сервера по разным машинам.

Через пару дней будет следующая часть, в которой мы разработает протокол обмена, реализуем TCP сервер и произведем первый коннект сервера и клиента.

P.S. На самом деле тема очень обширная. Поэтому если есть какие-то пожелания на чем заострить внимание или есть что-то, что я упустил из виду при описании — велкам в каменты.
Ваши пожелания и критика позволят в следующую часть повествования сделать более полезной и конструктивной.

upd. По просьбам хабравчан открыл Github для проекта
Tags:
Hubs:
+91
Comments 44
Comments Comments 44

Articles