Каких граблей стоит избегать при проектировании пошаговой клиент-серверной компьютерной игры?
Добрый день. Занимаюсь разработкой компьютерной игры вроде шахмат, ради знакомства с wcf, EF и многопоточностью в c#.
Цель: серверная служба, десктопные клиенты. Клиент регается (просто пара логин-пароль, без всяких примочек с безопасностью), получает возможность создавать игры, присоединяться к текущим (как игрок и как зритель), играть с ботами (бот уже есть), получать список игр. В БД хранятся логины пароли, истории игр, рейтинги игроков.
Основной вопрос: стоит ли как-нибудь поддерживать соединение с клиентом во время игры? Понятно, что можно заставить клиента требовать обновления ситуации каждые 5 секунд, но это породит множество бессмысленных запросов-ответов. Куда элегантней кажется решение сохранить данные о клиентском соединении, и отсылать туда инфу при OnGameChange().
Главный вопрос: какие еще тонкие моменты могут вылезти в процессе разработки?
Начну с ответа на ответ выше. Remoting - это не очень-то и красивое решение, его абстракции всюду текут. "Расшаривание" объекта по сети приводит к сложности с определением времени жизни объекта, а простота вызовов методов соблазняет делать кучу мелких запросов вместо одного крупного - что неизбежно приведет к тормозам.
WCF - идеальное решение. Оно куда проще, чем правильная работа с сокетами - и не страдает недостатками Remoting.
Транспорт в этой задаче лучше использовать NetTcp - на нем проще реализуется двусторонняя связь. Соединение с клиентом можно поддерживать средствами ReliableSession - тут только выставьте правильные тайм-ауты, а то результат будет странным. Так, тайм-аут на чтение тут лучше поставить вообще бесконечным, а время жизни сессии, напротив, небольшим.
ничего против WCF не имею, но хотелось бы знать что имеется в виду под "абстракции всюду текут"...
"определением времени жизни объекта" не особо актуально для объекта, который существует на протяжении всего игрового цикла, после окончания которого полностью удаляется. "делать кучу мелких запросов вместо одного крупного" пошаговая стратегия как раз подразумевает наличие кучи мелких запросов, все крупное будет исполняться на стороне сервера, у которого никаких задержек нет, тормозам тут тоже не откуда взяться, сами запросы легко вызываются асинхронно.
Если в 2х словах у WCF есть куча хороших фич, которые в рамках задачи не пригодятся, но при этом код с использованием WCF будет сложнее чем с Remoting.
Я бы тоже не стал связываться с Remoting - фактически он уже устарел и на смену ему и был представлен WCF. WCF имеет всё возможности Remoting - но представлены они немного в другом виде.
Да, в изучении он сложнее, но как минимум вы получите знания которые будут актуальны. Я бы сказал, что сложнее всего будет всё сконфигурировать и разбить на сервисы.
При реализации возникнет много заморочек, особенно если писать на низком уровне абстракции. Решение вида OnGameChange красивое, но актуально для realtime игр, вроде экш и т.п. для пошаговой же послать запрос раз в 500мс не критично при правильной реализации, даже если на 1 сервере будет 1000 игр с 10 игроками на каждом, что врятли светит самопальной игре.
По моему опыту подобное легко и красиво реализуется с использованием Remoting.
Весь код клиента и сервера при этом легко уместится в 30 строк в худшем случае. Писал подобный клиент -сервер недавно.
Насколько я понял, WCF может восприниматься как надстройка над Remoting (при определенной конфигурации).
Низкий уровень абстракции - это сокеты? Как на них писать подобные вещи более-менее понятно, но рутина времени займет сильно много.
А какая реализация может считаться неправильной? В качестве нагрузки планирую подвесить на сервер какого-нибудь самообучающегося бота (возможно, для каждого из игроков).
Oxoron: в некотором смысле они похожи, но Remoting имеет некоторые "фичи", которые тут очень пригодятся, например возможность "расшарить" объект по сети, тем самым фактически полностью реализуется клиент-серверное взаимодействие. В том самом "объекте" и реализуется игровая логика. Сам объект существует на сервере, клиенты же с ним общаются как будто это локальный объект.
Писать на сокетах на порядок сложней и это породит много ошибок(все предусмотреть крайне сложно) и соответственно проблем и нестабильность.
На самом деле сокеты - это не сложно, просто нужно написать один-два раза клиент-серверный код чтобы понять как всё работает. Но тогда вам нужно будет заботиться о сериализации сообщений или протоколе.
Ваш сервер должен использовать высоко нагрузочные технологии :). Забудьте про SQL, забудьте про генерацию разметки на строне сервера, забудьте про wcf, xml и прочие чудеса, только binary хардкор, советую делать на web платформе и webSocket'ах. SPA архитектура, HTML5 + JS позволит вам сделать как онлайн игру так и приложение под все мобильные платформы с помощью Apach Cordova.
