Должен ли двигатель для возможной сетевой игры запускаться как веб-сервис?

Недавно я решил начать писать движок для карточной игры. Я не большой игрок в «карты», но друг познакомил меня с игрой (это игра на датском языке), и я влюбился.

Я хочу развить игру в 3 сегмента:

1. Основной движок, ручки карт / колод / игровых состояний и т. Д.
2. Пользовательский интерфейс (в форме мобильного / настольного веб-приложения.)
3. Искусственный интеллект с различными стратегиями / сложностями и т. Д.

На мой взгляд, это очень разные проекты, и я изо всех сил пытаюсь понять, как они все будут сочетаться друг с другом в долгосрочной перспективе. Сначала я даже не хочу иметь возможность «играть» в игру, используя движок. Двигатель будет прежде всего проверен его тестами. Тестирование игры не начнется, пока клиент не существует. Так что здесь есть что-то вроде отношений клиент-сервер.

Двигатель очень большой кусок головоломки. Я хотел бы знать следующее: как бы вы разработали «публичный API» для этого движка?

Я думал, что механизм может быть очень простым веб-сервисом, который возвращает свое состояние посредством запросов к RESTful API, но я обеспокоен тем, что разработка самого механизма как веб-приложения может привести к неправильным программным решениям. (Например, если бы я выбрал микро-фреймворк MVC, у этого API действительно не было бы представлений ... он просто возвращает сериализованные объекты через JSON или что-то в этом роде. Плохо ли использовать MVC для такой службы, как это? )

Моя другая идея состояла в том, что движок будет просто консольным приложением, и позже я напишу какой-то мост для передачи данных между ним и веб-приложением. (Мост может быть действительно любым. Я имею в виду, что веб-сервер и игровой движок могут бездействовать на IRC-сервере и обмениваться своим состоянием по каналам.)

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

Спасибо, Робби.

РЕДАКТИРОВАТЬ: Таким образом, я думаю, это относится к разработке игр. Чтобы уточнить, я собираюсь написать движок карточной игры. Я пытаюсь найти лучший способ представить API движка, чтобы он мог быть интегрирован в будущем с веб-клиентом и клиентом AI.

У меня даже здесь не было учетной записи, так что привет :)

Маршрут веб-службы, вероятно, является лучшим и наиболее масштабируемым.

Я также не вижу абсолютно никаких проблем при использовании MVC-фреймворка для возврата JSON (asp.net mvc хорош в этом). Если ваши контроллеры вначале возвращают только JSON, это нормально, вы можете тестировать модуль без каких-либо представлений. Когда вы будете готовы добавить свой игровой интерфейс, вы можете добавлять виды. Если это обычный html / css или flash / silverlight, это не имеет значения, потому что, как вы заявили, вы уже создали базовый движок.

Я не уверен, на что похожа ваша среда разработки или хостинга, но я не стал бы чрезмерно проектировать это. Простой набор php-файлов, которые возвращают JSON, может быть всем, что вам нужно. Я не знаком с игрой, которую вы создаете, поэтому я не уверен, насколько она будет сложной.

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

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

Если ваша модель находится на веб-сервере, у вас есть проблема, потому что HTTP не реализует явный способ позволить серверу начать связь. Вы можете использовать websocket, чтобы справиться с этим, но вы пожертвуете частью своей "RESTfulness" ... Я думаю, что хорошим решением может быть позволить вашему веб-URL идентифицировать модель и использовать HTTP-сервер, чтобы ваши представления были уведомлены при необходимости.

Допустим, у вас есть беговая игра в

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/

Вы можете использовать URL

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/playCard?id=3&place=stack 

изменить модель и

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/notify 

ждать уведомлений.

Notify будет ждать - некоторое время - чтобы получать новости от модели: если что-то случится, будет отправлено сообщение (какие данные изменены, или какое событие произошло или что-то еще).

Клиент может выполнить длинный ajax-запрос к / games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notify и зарегистрировать обратный вызов уведомления, который одновременно обновит представление и отправит следующий запрос на уведомление.

Если игры / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notify timeout на клиенте выполняются, то новый запрос выполняется, если на тайм-аутах на сервере выделенные ресурсы освобождаются.

Вы можете создать довольно общую систему уведомлений на своем сервере и библиотеку уведомлений на своих клиентах, чтобы вы могли создать согласованный MVC поверх прозрачного слоя уведомлений.

Если вы ищете технологию, вы можете построить свой игровой движок на сервере Couchdb. Couchdb - это нереляционная СУБД REST, которая использует HTTP в качестве протокола и JSON в качестве формата документа. Он также может PUT и GET двоичные или HTML-файлы в качестве вложений, так что можно написать полноценное веб-приложение, используя только СУБД (couchApp).

Существует библиотека javascript, которая позволяет, помимо прочего, реагировать на обновления базы данных. CouchdbApp - это просто база данных, поэтому вы можете скопировать приложение на другой сервер с помощью синхронизации: ваши клиенты могут скопировать ваше приложение на свой локальный сервер и затем воспроизводить его по автономной локальной сети.