Pull to refresh

Comments 44

Клиент на флеше, сервер на scala? Точно тремя статьями отделаетесь? По-моему на один клиент можно три топика написать, что уж о сервере говорить.
Я же писал, что тема обширная. так что надеюсь меня не заминусуют, если я напишу не 3, а 5-6 статей на эту тему…
Я не знаю что вас так напугало, но смею предположить, что вас яро заплюсуют, так как тема интересная и scala интересен.
Черт подери! Буквально пару недель назад задумал попробовать себя в написании простенького игрового сервера. В качестве языка выбрал scala, так как выполняется на jvm и умеет выполнять java-код, а с джавой я знаком. Клиент собирался писать на флеше, поскольку флешер. Вы невероятно кстати со своими статьями! Просто ужастно удачное совпадение.
P.S. Знаю, что поплачусь за эти слова, но, блин, в такие моменты очень жаль, что нечем плюсануть!
Я правильно понял, что сервер будет сугубо реактивный, то есть никаких игровых циклов — только реакция на события?

Т.е. никаких летящих пуль и т.д.
Будет все. Но последовательно. От простого к сложному. Сначала простая версия, потом усложним задачу.
Рандомно выдаем координаты появления танка на карте.

По-хорошему, есть стены, враги и другие игроки. До 3/4 карты может быть занято этими препятствиями.

Ну и естественно, ваш сервер будет легко ломаться читерами. Например, можно будет легко увеличить скорость своего перемещения.
Вы не поверите, но спид-хак не то что в таких вот поделках на коленке, а и в MMORPG с мировым именем — большая проблема с разными хитрыми методами решения.
UFO landed and left these words here
Неа. В играх часто присутствуют всякие модификаторы скорости (зелья, лошади, грифоны, заклинания), так что определить превышения макс. скорости не так уж легко. Дальше — есть такая штука как телепорты — тут уж и вовсе за секунду игрок может прыгнуть через пол-мира. Кроме того, даже двигаясь с нужной скоростью можно двигаться под\над землей, через стены, над пропастью — это всё тоже нужно ловить. Особняком — замедленное падение и немотивированные полёты. И еще куча всего. Это нехилая такая задача — её решают с разной степенью успешности.
Почему же? Охотно верю. Про скорость задумываются в последнюю очередь, когда уже всё реализовано и внезапно появляются читеры.
А вариант передавать на сервер только сам факт того, что игрок начал движение и направление этого движения?
Может привести или к тормозам (клиент должен получить от сервера свои координаты) или к «телепортам» (клиент рисует картинку сам, а потом корректирует позицию по данным от сервера).
А может и не привести, всеж-таки. Тут вопрос грамотного отлова лага и программирования клиента в целом.

И с точки зрения безопасности данный вариант единственно верный. Нельзя доверять расчеты клиенту. ПОтому что в этом случае они могут быть скомпрометированы. (понятно, что не в рамках этой статьи об таких вещах говорить, но все же).
По хорошему вообще нужно монопольно захватить пользовательский ввод и его транслировать на сервер :)
Обычно пользователи более терпимы к ошибкам предсказания клиента (их вы имели в виду под «телепортами»?), чем к тормозам лагам или читерам. Чтобы снизить нагрузку на сервер (избежать тормозов), можно чтобы клиент посылал и дельту (направление перемещения) и конечную точку, а проверять их соответствие выборочно (например, каждый 100-й запрос) и банить при не соответствии.
сервер с картинками лег :( перезалейте.
Спрашивать у клиента координаты — способствовать читингу. Решение — спрашивать только направление перемещения, хоть это и дополнительные расчеты.
ой, пропустил последнее предложение в сообщении Oreolek'a, простите
Разборки с читерами в данных статьях не планировались. Хотя в дальнейшем возможно и коснемся этой темы…

Еще раз говорю статьи будут по принципу от простого к сложному.
«многопользовательская» — это какая? massive-multiplayer или просто multiplayer? Если второе, то как выше уже говорили, совсем не понятно зачем клиенту доверять так много. Да и в первом случае это имеет смысл только для оптимизаций(освободить сервер от «лишних» расчетов). Чаще всего под клиентом понимают просто какое-то примерное или приближенное отображение игрового состояния, т.е. абсолютно вся логика на сервере, а от клиента получаем только его действия/команды. И если уж все-таки посылать:
Клиент шлет свои координаты на сервер с какой-то периодичностью (Во время движения чаще)
Зачем так? Просто каждый кадр шлем с дельта-компрессией, соответсвенно если ничего не поменялось, нечего и отсылать будет.
Ну и TCP совсем не подходит для таких вещей, жаль что flash не поддерживает UDP сокеты. Хотя вон там у ребят получилось вроде неплохо :)
Если кому-то интересно, тут много информации по традиционному сетевому коду(не mmo):
* Source Multiplayer Networking
* Unreal Networking Architecture
* Quake3 Networking Model

Жду продолжения ;)
UFO landed and left these words here
tankionline.com — вычеркните. Они до сих пор не победили лаги и хаки.
UFO landed and left these words here
А там хак то один — сервер слишком доверяет клиенту. Вот и скорость любая и телепортация и невидимость и любой терраморфинг (кажется) возможны не смотря на шифрование и прочие попытки.
Да и лаг если судить по косвенным признакам тоже один — утечки памяти.
Это будет multiplayer прототип плавно перетекающий в massive-multiplayer… )))
Клиенту будем доверять как родному, по той простой причине, что это всего лишь прототип, а не коммерческий продукт.
Runtime Versions: AIR 2
Не флеш, air.
Однако флеш) Просто апи доступно исключительно при запуске в оболочке AIR.
Я би с удовольствием почитал подобную серию статей о реализации такой игры на JavaScript (HTML5 canvas, comet/websockets) + NodeJs (ну или PHP/Python/Ruby) + какой-то NoSQL (MongoDb, CouchDb etc).
Никто не хочет написать ?:)
А что мешает вам самому написать такие статьи?
Ведь необязательно быть экспертом по технологиям.
Достаточно будет если вы начнете в них разбираться и по ходу освоения писать статьи как и что у вас получается…

Люди будут благодарны…
Почему бы Вам сразу не публиковать исходники на github/bitbucket/code.google.com параллельно с разработкой? В статье можно будет сразу отсылать к конкретным коммитам. Вы ведь всё равно в конце покажете исходный код? Изначально репозиторий будет пустой, но по мере написания статей код будет нарастать, а наблюдать за разработкой, я думаю, многим будет интересно, особенно паралельно читая Вашу серию статей.
Я сейчас как раз над этим раздумываю… стоит ли…
а для меня github ненормальный… ;)
Так что не будем тут холивар разводить…

Выбрал то, что для привычней и удобней.
Сорри.

Выбрал то, что для меня привычней и удобней.
ну я просто подумал, что вы для читателей удобнее хотите. а если для себя…
А кто сказал, что ВСЕМ читателям будет удобнее github?

И вообще, хорош доматываться. Это всего лишь инструмент.
Я же вас не попрекаю, что пишете про javascript, а не про scala например…

Хотите github? Возьмите и выложите туда…
Спасибо, очень интересно!

Старая корректорская привычка:
«Часть первая. Действие второе: Архитетура сервера»

В слове «архитектура» пропала буква Ж)
Пропала буква К, а не буква Ж :)
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.