Чи повинен двигун для можливої ​​веб-гри починати як веб-сервіс?

Нещодавно я вирішив почати писати движок для карткової гри. Я не великий гравець на "картках", але друг познайомив мене з грою (це спіна на грі Датська), і я закохався.

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

1. Основний двигун, обробляє карти / колоди / іграти тощо.
2. Інтерфейс користувача (у формі веб-програми для мобільних пристроїв / настільних ПК)
3. Штучний інтелект з різними стратегіями / труднощами тощо.

На мій погляд, це дуже чіткі проекти ... і я намагаюся бачити, як вони всі разом поєднуватимуться в довгостроковій перспективі. Спочатку я навіть не хочу мати можливість "грати" в гру за допомогою двигуна. Двигун буде в основному випробовуватися за допомогою його тестових агрегатів. Тестування на ігри не розпочнеться, поки клієнт не існує. Отже, тут є щось із стосунків клієнт-сервер.

Двигун - це дуже великий шматочок головоломки. Що я хотів би знати: це як би ви вирішили розробити "публічний API" для цього двигуна?

Я думав, що двигун може бути дуже базовим веб-сервісом, який повертає свій стан за допомогою запитів до API RESTful, але я переживаю, що розробка самого двигуна як веб-програми може призвести до поганих програмних рішень. (Наприклад, якщо я вибрав мікрорамку MVC, ну, цей API насправді не матиме переглядів ... це просто повернення серіалізованих об'єктів через JSON чи щось для цього. Чи погано використовувати MVC для такої послуги, як це?)

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

Який підхід ви б застосували (розробляйте як веб-сервіс або розробляйте як окремий додаток і перетворюйте його пізніше), і чому?

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

EDIT: Тож я думаю, що це належить до розробки ігор. Для уточнення я збираюся написати двигун карткової гри. Я намагаюся знайти найкращий спосіб розкрити API двигуна, щоб він міг бути інтегрований у майбутньому із веб-клієнтом та AI-клієнтом.

У мене навіть тут не було облікового запису, отже :)

Маршрут веб-сервісу, мабуть, найкращий і масштабований.

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

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

На мою думку, якщо ви новачок у розробці ігор, і ви самостійно збираєтесь, я настійно рекомендую якнайшвидше отримати щось, що можна відтворити, оскільки це допоможе вам вмотивувати завершити гру та відполірувати її. на хороший рівень.

Представлення - це сутність, яка реєструється до моделі, про яку потрібно повідомляти, коли відбувається зміна.

Якщо ваша модель розміщена на веб-сервері, у вас є проблема, оскільки HTTP не реалізує явного способу дозволити серверу починати спілкування. Ви можете використовувати веб-розетку, щоб впоратися з цим, але ви принесете в жертву частину своєї "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 

чекати сповіщень.

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

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

Якщо games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / сповістить про час очікування клієнта, робиться новий запит, якщо він вичерпано на сервері, виділені ресурси звільняються.

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

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

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