Своя многопользовательская он-лайн игра

[ndemidov]

Такие вопросы:
- я так понимаю для защиты данных (чтобы нельзя было взломать) нужно постоянно отсылать запросы на сервер и там делать проверку (на случай подделки javascript'а либо flash'а)?
- данные надо где-то хранить, значит записывать в БД. Т.к. игра он-лайн, то, получается будет много запросов от js к серверу и много обращений к БД в каждом запросе? Либо надо пытаться хранить всю инфу с данными (локациями, игроками, предметами) в оперативке и только временами сохранять это в БД?
- можно ли назвать игру "Затерянный мир" или "Властелин колец"? Не будет ли это нарушать авторские или другие права?

[FireFenix]

- я так понимаю для защиты данных (чтобы нельзя было взломать) нужно постоянно отсылать запросы на сервер и там делать проверку (на случай подделки javascript'а либо flash'а)?

смотря что понимать под взломом.

если мультиплеер - то никак не обойтись от передачи данных. Если говорить о проверки скажем попадания, то тут всё больше зависит от игры и и ситуации. Конечно в fps лучше все предсказания делать на клиенте и уже потом синхронизировать с сервером, только потому что, полноценная синхронизация с сервером даст неиграбильную задержку

тут нужны подробности....

А вообще от взлома защищает только правильно написанный софт

- данные надо где-то хранить, значит записывать в БД. Т.к. игра он-лайн, то, получается будет много запросов от js к серверу и много обращений к БД в каждом запросе? Либо надо пытаться хранить всю инфу с данными (локациями, игроками, предметами) в оперативке и только временами сохранять это в БД?

зависит от игры и данных, чем меньше запросов - тем лучше.

Вначале нужно реализовать хотя бы 1 из способов, пусть даже он медленный, а уже потом наворачивать кеширование или прочие оптимизации, так или иначе - всё в памяти держать невозможно

- можно ли назвать игру "Затерянный мир" или "Властелин колец"? Не будет ли это нарушать авторские или другие права?

Есть реестр зарегистрированных торговых марок, через юриста или кого-то там можно подать запрос оффициально. А так возможно где-то есть и сайт проверок на территории твоей страны

[ndemidov]

- данные надо где-то хранить, значит записывать в БД. Т.к. игра он-лайн, то, получается будет много запросов от js к серверу и много обращений к БД в каждом запросе? Либо надо пытаться хранить всю инфу с данными (локациями, игроками, предметами) в оперативке и только временами сохранять это в БД?

зависит от игры и данных, чем меньше запросов - тем лучше.

Вначале нужно реализовать хотя бы 1 из способов, пусть даже он медленный, а уже потом наворачивать кеширование или прочие оптимизации, так или иначе - всё в памяти держать невозможно

Мысли какие: допустим играет одновременно 100 игроков. И раз в секунду клиент посылает запрос на сервер для обновления игровой среды. Плюс ещё "игровой цикл" крутится и обновляет среду (не знаю с какой частотой). Если данные хранить в БД и каждый раз загружать и сохранять их через ORM не будет ли это всё плохо? Я даже не знаю как это в играх делают - хранят ли в оперативке это всё и периодически записывают в БД или как....

[Хакер]

Я даже не знаю как это в играх делают - хранят ли в оперативке это всё и периодически записывают в БД или как....

В играх это делают так: напрягают мозг и придумывают что-то оригинальное и куда более мудрёное, чем тупой выбор между хранением всего в БД или хранением всего в памяти.

Например строят сбалансированное дерево игровых объектов по принципу группировки близких игровых объектов. Делят игровой мир на своеобразные пространственные кластеры. Каждый кластер относится относится к группе игроков по принципу их нахождения в нём.

Отдельный кластер «обрабатывается» отдельным процессом на одной машине (если машина одна) или одной машиной из кластера машин (если машин много) — зависимости от того, как ты будешь масштабировать систему. Разбиение на кластеры и построение сопоставления между группами игроков и кластерами делается исходя из системных возможностей единиц твоей инфраструктуры.

[Debugger]

Используются иногда "шардинг" по клиентам: каждый клиент привязан к конкретной "ноде" (процессу на машине), который обрабатывает его данный и действия. Действия, не связанные с конкретным игроком, обрабатываются по такому же принципу: каждый объект должен однозначно обрабатываться одной "нодой" (например, как написал Хакер, да).

Для повышения отказоустойчивости есть специальный сервер, который знает о состоянии нод, если какая-то машина умерла - умеет их запускать ноды на запасной машине и перенаправлять все запросы туда.

Информация по клиентам хранится в памяти, периодически синхронизируется с БД. БД периодически реплицируются между собой.

При такой схеме запросы на диск минимальны (нам же не нужна БД с гарантией записи, на самом деле), трафик обмена между машинами тоже небольшой. Если случится катастрофа и одна из машин выйдет и строя, то её сразу подменит другая, и будет максимум ~10 секунд "лага" и потери последних ~5 минут игровых событий для части игроков и игрового мира.

И вообще, сейчас прогресс дошел до того, что обращения к памяти считаю медленными: "память - это второй диск". Да и скорость современных дисков приближается к обращению к памяти. Да и есть кеш БД - она знает, что тебе может понадобиться. Да и вообще, это не должно быть проблемой, тем более на первых порах. Есть менее технические, и более важные вопросы. Есть дизайн-документ? Ты понимаешь, что будет заставлять игроков снова возвращаться в игру? Как будет выглядеть прокачка игрока? Наброски карт? Читал про "compulsion loops"? Как игра будет оплачиваться? Я думаю, все более-менее компетентные программисты способны создать MMORPG за конечное время. Однако, не у всех находится достаточное количество времени, энтузиазма, и главное - компетентности в остальных областях, чтобы получить готовый продукт.

[ndemidov]

... Есть дизайн-документ? Ты понимаешь, что будет заставлять игроков снова возвращаться в игру? Как будет выглядеть прокачка игрока? Наброски карт? Читал про "compulsion loops"? Как игра будет оплачиваться? Я думаю, все более-менее компетентные программисты способны создать MMORPG за конечное время. Однако, не у всех находится достаточное количество времени, энтузиазма, и главное - компетентности в остальных областях, чтобы получить готовый продукт.

А что такое compulsion loops? Не читал, всё на английском(

Знаешь, это мне давно хотелось попробовать набросать свою игру. Готовой идеи нет. Есть мысль на тему что привлекает людей: людям нравятся соревнования (турнир, возможность улучшить себя).

Думаю также есть смысл сделать игру, как бы сказать, "начинающейся заново". Например, шахматы, шашки, домино - каждый раз начинаются заново.
Ну вообще я планировал сделать текстовую игру (без картинок даже, т.к. не знай где их достать), перемещаться по лабиринту по типу вампуса. И, не знаю какую придумать задачу, цель игры, допустим дойти из точки А в точку Б. Даётся две недели. Кто придёт раньше, тот победил. Через две недели показываются результаты, и игровой мир генерится заново. Не знаю что из этого выйдет\вышло бы и попробую ли реализовать. Было б неплохо ещё, чтоб люди не соперничали, а им было бы выгодно помогать друг другу (не знаю как сделать; например, несколько первых мест, если вошли одновременно).

Ещё сделать ограничение на игру в день, допустим три раза по 40 минут. За счёт введения параметра энергии, которая расходуется. Одновременно и игрок не успеет "насытится" игрой, будет держать его на привязи, и время пользователей сэкономим, чтоб сильно не "тупили". Ну и нивелируем результат у тех кто на игру может выделить мало времени с теми кто сидел бы много. А если игрок выходит из игры, то на него автоматом накидывается "волшебный плащ", который скрывает его от всех.

Сути не хватает. Если б была одна или несколько вещей, где можно было бы подумать, тогда сюжет можно любой - было бы уже интересно.



Представляю реализацию так:
1. Сервер:
а) Бесконечный цикл игрового мира крутится каждые 1-5 секунд. Хранит все данные данные в оперативной памяти (со всеми игровыми объектами). Периодически сохраняется в БД.
б) API - принимает запросы от клиентов. Наверное - у меня прога видимо небольшая - можно только из оперативки читать данные, а бд чисто на случай перезапуска сервера.

2. Клиент:
просто html с javascript. Обращается к серверу через API, наверное.


Вообще писал только сайты на python, и не очень представляю как именно игру сделать через веб + многопользовательскую.
Вероятно для моей реализации можно будет сделать и "полную синхронизацию с сервером" (с приостановкой процесса, пока идет запрос-ответ), т.к. игра пошаговая.

Еще непонятно как сделать, чтобы на сервере (сервер на python\django) крутился "бесконечный цикл" из пункта а). И "вьюхи" (функции-обработчики запросов url) имели доступ к глобальным переменным этого цикла. Когда делал сайт всё было гораздо проще: стандартно вызывалась функция для определённого url, в которую передавался объект запроса.

[alibek]

Представляю реализацию так:

Отсюда вытекает, что ничего из сказанного ты не понял.
И совет бросить это занятие и не тратить время ты скорее всего проигнорируешь.


— Хочу построить ракету и слетать на Луну.
— Построить ракету — это довольно сложно, нужно определиться с задачами, определить полезную массу, а затем по ней уже проектировать ракету.
— Записываю, масса. А чем лучше красить корпус, порошковой краской или акриловой?

[Хакер]

alibek, +1

[ndemidov]

Вобщем-то да, не понял. Особенно как на конкретный процесс "подвесить" определённый кусок своего кода (кластер)

Ну попробовать-то можно хоть что-то сделать, почему нет

[alibek]

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