Проект переехал на Crystal. Несомненно, этот язык оптимален для динамичной ммо-игры по следущим причинам:
- не поддерживает многопоточность (!)
- не поддерживает винду (!!)
- регулярно нахожу баги в компиляторе
- и конечно же неотключаемый boehm-кто-то-там гц, с остановкой мира, без поколений и без возможности настройки.
Почему все-таки Crystal (минутка рефлексии):
Начать проект я решил с UDP-библиотеки вдохновленной статьями http://gafferongames.com/networking-for-game-programmers/, но по возможности без лишней универсальности - никаких движков, только то что нужно для игры, но чтобы было удобно.
Код библиотеки открыт: https://github.com/konovod/mysync, код игры пока не вижу смысла выкладывать чтоб не позориться (не то чтобы код библиотеки был поводом для гордости, но в игре совсем жесть)
Текущее состояние библиотеки:
+ маска подтверждения пакетов
+ возможность отправки unreliable ordered данных (данных для которых важны только самые актуальные значения)
+ возможность отправки reliable unordered данных (команд которые будут гарантированно выполнены и от которых вернется ответ)
+ RPC, т.е. предыдущий пункт выглядит так - на одной стороне пишем вызов команды, на другой стороне - реализацию, а библиотека сама упакует аргументы и результат и перешлет туда-сюда с подтверждениями и повторными отправками. Правда для компиляторной магии я использовал чужую библиотеку и упаковка там не очень оптимальная, по 4 байта для всяких длин и енумов для которых мне хватило бы и 1, но пока и так сойдет.
+/- синхронизируемые списки, например на сервере заводим итератор по видимым игроку объектам, а библиотека будет сама пересылать клиенту изменения, учитывая потери пакетов. Пока вместо реализации скорее заглушка, надо дорабатывать. С другой стороны, думаю что и заглушки хватит для игры на десяток игроков и толпу монстров и пули свистят.
+ современные алгоритмы шифрования и авторизации, c использованием стильной библиотеки шифрования от какого-то поехавшего криптовелосипедиста с расово верными взглядами на жизнь.
- стало ясно что даже для чата нужны не reliable unordered, а reliable ordered данные, но наверное можно забить и не давать отправлять новое сообщение пока не отобразилось предыдущее. Не то чтобы это было проблемой, но я за минимализм, а так надо лишний буфер заводить и туда сообщения складывать.
- есть еще несколько пунктов которые конечно необходимы но и без них работает (защита от реплея авторизации, защита от ддос-амплификации, контроль частоты приема\отправки сообщений, разбиение и собирание длинных посылок, шифровать inplace, избавиться от остальных аллокаций при обработке кадра, сделать структуру сообщения более однородной, ну и код распределить по неймспейсам)
Ну да, TCP бы дал почти всё это из коробки а его недостатков было бы почти незаметно, но самому делать интереснее.
Т.к. основной функционал библиотеки готов, то наконец-то смог перейти к игре.
С игрой пока больше вопросов чем ответов. От концепции "ночного террора" скорее всего отказываюсь, хочу полноценный открытый мир а не комнаты.
Свои идеи игры, чтобы не потерять:
Но для чужих идей и предложений я пока тоже открыт. В любом случае игра должна быть 2д, вид сверху и с динамичными объектами, а геймплей скорее всего состоять из перестрелок, поэтому для начала и буду делать просто перестрелки, с пве, чатом и регистрацией. Пока есть чат и начал подключать физдвижок:
VPS за это время подешевели и уже есть за 65 руб\месяц, пробовал на такой ставить и всё работало, для теста хватит.
Старый пост:
резерв будет
за мирников играть можно? выборы старост есть?
проще было сделать как варзес, гулялки всякие и квесты вид как у тебя, а махач в отдельной картинке - вид сбоку или изометрично.
это было бы намного эффектнее (если есть кому рисовать) + экономия для сервера.
но так как варзес все-равно ничего не сделает инфа сотка, то у тебя есть шанс)
ну как ничего, чето сделает пока не начнет тонуть в своем/чужом коде или не случится новая истерика.
впрочем если сможешь сделать геймплей залипательным при такой графике. то можно и так оставить.
Mira
> но так как варзес все-равно ничего не сделает инфа сотка, то у тебя есть шанс)
а вот вдруг возьму - и сделаю?
мул
А, да, про них забыл написать. За мирников играть нельзя, средневековья тоже не будет. Пока ориентируюсь на ту концепцию которую Epsilon выкатывал.
Mira
Нет, jrpg не по мне. Бой и остальная игра должны происходить в одинаковом режиме.
Рисовать так и так некому, поэтому графон останется примерно таким. Ну, разве что ещё анимацию персонажам сделаю.
А с геймплеем - да, идея была в том чтобы брать геймплеем. Посмотрим как в реальности выйдет.
kipar
> В общем, стоит ли тратить на это время?
Не стоит. Хотя если сейчас запилить физику и просто пока не использовать, а двигать тела просто трансформом, то на будущее будет задел когда физика на клиенте понадобиться :)
Кроме как детектор коллизий я не могу придумать применение физики на клиенте. Что ты там собрался предсказывать?
RadianTOR
Ну, бежим с разбегу на стену, с физикой он так красиво от нее отскакивает. И можно будет это отобразить еще до того как с сервера придет подтверждение, т.е. без лага.
Ну и если не ограничиваться физикой, а рассматривать логику - например с сервера пришла команда что противник рядом стреляет. И можно будет продолжать создавать пульки считая что он продолжает стрелять все это время, тоже не дожидаясь команды с сервера.
В общем, я еще подумал и физику наверное все-таки надо сделать. Но сначала откомпилирую под линукс и посмотрю какие в реальности лаги при игре по инету.
kipar
> И можно будет продолжать создавать пульки считая что он продолжает стрелять все
> это время, тоже не дожидаясь команды с сервера.
ну дык так и надо делать. Не слать же команду на каждую пульку. Только fireOn и fireOff.
RadianTOR
У меня сервер шлет координаты каждой пульки, т.к. это физические объекты.
Ну, чтоб можно было уклоняться от них или рикошеты ловить.
—-
Или это в принципе ущербный подход? Если тысяча игроков будет стрелять одновременно, будет ну скажем 10к пуль, физдвижок загнется.
Мгновенная стрельба видимо прилично сэкономит ресурсов. Надо подумать.
kipar
у тебя позиция персонажа то каким образом передается, в частности движение?
Mira
Клиент передает 4 флага движения от стрелок, угол и флаг стрельбы.
А сервер отвечает координатами и скоростями всех тел, включая игрока.
kipar
да, это многовато может по траффику влететь, в конце концов придется передавать еще больше данных.
kipar
> Или это в принципе ущербный подход?
Еще бы. Передавай хотябы только позицию и вектор направления пули в момент выстрела, а дальше ее уже не нужно вести, она спокойно симулируется на клиенте. Скорость пули же не меняется со временем.
RadianTOR
верно.
достаточно кинуть клиенту направление выстрела и скорость пули (если она не фиксированная), и после попадания кинуть ему результат через просчитанное время прилета, ну типа там взрывчик и дамаг.
если предполагаются всякие витиеватые траектории полета да еще с физикой - это вообще не server-like, этого лучше избегать. физику тел эмулировать на сервере не лучшая затея, нереалистичная физика пойдет для игр этого жанра и она впринцыпе норм просчитывается как клиентом так и сервом.
Тема в архиве.
