Часть 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 для проекта
