Каких граблей стоит избегать при проектировании пошаговой клиент-серверной компьютерной игры?
Добрый день. Занимаюсь разработкой компьютерной игры вроде шахмат, ради знакомства с wcf, EF и многопоточностью в c#.
Цель: серверная служба, десктопные клиенты. Клиент регается (просто пара логин-пароль, без всяких примочек с безопасностью), получает возможность создавать игры, присоединяться к текущим (как игрок и как зритель), играть с ботами (бот уже есть), получать список игр. В БД хранятся логины пароли, истории игр, рейтинги игроков.
Основной вопрос: стоит ли как-нибудь поддерживать соединение с клиентом во время игры? Понятно, что можно заставить клиента требовать обновления ситуации каждые 5 секунд, но это породит множество бессмысленных запросов-ответов. Куда элегантней кажется решение сохранить данные о клиентском соединении, и отсылать туда инфу при OnGameChange().
Главный вопрос: какие еще тонкие моменты могут вылезти в процессе разработки?
При реализации возникнет много заморочек, особенно если писать на низком уровне абстракции. Решение вида OnGameChange красивое, но актуально для realtime игр, вроде экш и т.п. для пошаговой же послать запрос раз в 500мс не критично при правильной реализации, даже если на 1 сервере будет 1000 игр с 10 игроками на каждом, что врятли светит самопальной игре.
По моему опыту подобное легко и красиво реализуется с использованием Remoting.
Весь код клиента и сервера при этом легко уместится в 30 строк в худшем случае. Писал подобный клиент -сервер недавно.
Насколько я понял, WCF может восприниматься как надстройка над Remoting (при определенной конфигурации).
Низкий уровень абстракции - это сокеты? Как на них писать подобные вещи более-менее понятно, но рутина времени займет сильно много.
А какая реализация может считаться неправильной? В качестве нагрузки планирую подвесить на сервер какого-нибудь самообучающегося бота (возможно, для каждого из игроков).
Oxoron: в некотором смысле они похожи, но Remoting имеет некоторые "фичи", которые тут очень пригодятся, например возможность "расшарить" объект по сети, тем самым фактически полностью реализуется клиент-серверное взаимодействие. В том самом "объекте" и реализуется игровая логика. Сам объект существует на сервере, клиенты же с ним общаются как будто это локальный объект.
Писать на сокетах на порядок сложней и это породит много ошибок(все предусмотреть крайне сложно) и соответственно проблем и нестабильность.
На самом деле сокеты - это не сложно, просто нужно написать один-два раза клиент-серверный код чтобы понять как всё работает. Но тогда вам нужно будет заботиться о сериализации сообщений или протоколе.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
