I've recently decided to start writing an engine for a card game. I'm not a big "cards" player, but a friend introduced me to the game (it's a spin on the game Danish), and I fell in love.

I want to develop the game in 3 segments:

  1. The basic engine, handles cards/decks/gamestate, etc.
  2. A user interface (in the form of a mobile/desktop web app.)
  3. An artificial intelligence with various strategies/difficulties, etc.

These are very distinct projects, in my mind... and I'm struggling with seeing how they'll all fit together in the long run. At first, I don't even want to be able to "play" the game using the engine. The engine will primarily be tested by its unit tests. Play testing won't start until a client exists. So there's something of a client-server relationship here.

The engine is a very large piece of the puzzle. What I'd like to know is: how would you go about developing the "public API" for this engine?

I was thinking the engine could be a very basic web service, that returns its state via queries to a RESTful API, but I'm worried that developing the engine itself as a web app may lead to poor programming decisions. (For instance, if I chose an MVC micro-framework, well, this API wouldn't really have views... it's just returning serialized objects via JSON, or something to that effect. Is it bad to use MVC for a service like this? )

My other idea was that the engine would just be a console app, and I would later write a bridge of some kind to pipe data between it and the web-app. (The bridge could really be anything. I mean, the web server and the game engine could both idle in an IRC server and share their state in channels.)

What approach would you take (develop as a web service, or develop as a standalone app and bridge it later), and why?

Thanks, Robbie.

EDIT: So I guess this belongs in Game Development. To clarify, I'm going to write a card game engine. I'm trying to figure out the best way to expose the engine's API so it can be integrated in the future with a web client, and an AI client.

I didn't even have an account here, so howdy :)

  • \$\begingroup\$ How many concurrent games does your engine need to handle? \$\endgroup\$
    – Darien
    Commented Jul 15, 2011 at 18:34
  • \$\begingroup\$ That's undefined at this point, but ... in a perfect world: lots and lots. There will definitely be concurrent games going on. If the project takes off, the idea is that it's going to be a multiplayer app where you can either play it by yourself (solitaire style), or join a room and play the game with humans/AIs (similar to Pogo, etc.) \$\endgroup\$
    – Robbie
    Commented Jul 15, 2011 at 18:43

2 Answers 2


The web service route is probably the best and most scalable.

I also see absolutely NO problem using an MVC framework to return JSON (asp.net mvc is great at this). If your controllers only return JSON at first that is fine, you can unit test without any views. When you are ready to add your game interface, you can add views. If their plain html/css or flash/silverlight, it doesn't matter because, as you've stated, you have already built the underlying engine.

I'm not sure what your development or hosting environments look like but I would not over engineer it. A simple set of php files that return JSON may be all you need. I am not familiar with the game you're building, so I am not sure how complex it will be.

In my opinion, if you're new to game development, and you're going it yourself, I highly recommend that you get something that is playable as soon as possible, because it will help keep you motivated to complete the game and polish it to a good level.

  • \$\begingroup\$ I am new to game development, and I'll be the only developer, but don't worry: the code will keep me more interested than the game ;) I was thinking of using Padrino, a lightweight MVC framework written in Ruby. What's nice is it has mountable apps. I'm not super familiar with them, but I think I could "mount" the engine and the UI apps side-by-side in the same processs, yet they're still separate apps with [potentially] their own databases and static resources. \$\endgroup\$
    – Robbie
    Commented Jul 15, 2011 at 21:44
  • \$\begingroup\$ That sounds like a good plan to me. If the code will keep you interested, I say go for it. \$\endgroup\$
    – Nate
    Commented Jul 17, 2011 at 18:01

A view is an entity that registers to a model to be notified when changes occour.

If your model resides to a web server, you have a problem because the HTTP does not implement an explicit way to let the server start a communication. You can use websocket to handle this but you will sacrifice some of your "RESTfulness"... I think that a good solution can be to let your web URL to identify a model and use the HTTP server push to let your views to be notified when needed.

Lets say you have a running game in


you can use the URL


to modify the model and


to wait for notifications.

Notify will wait - for some amount of time - to get news by the model: if something happends a message will be sent (what data are changed or what kind of event happends or whatever).

The client can do a long ajax request to /games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/notify and register a notification callback that will both update the view and repost the next notify request.

If games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/notify timeouts on the client, a new request is done, if it timeouts on the server, the allocated resources are freed.

You can build a quite generic notification system on your server and a notification library on your clients so you can build up a consistent MVC over a transparent notification layer.

If you are looking for a technology, you can consider to build your game engine upon the Couchdb server. Couchdb is a non-relational REST DBMS that uses HTTP as protocol and JSON as document format. It can also PUT and GET binary or HTML files as attachments so it is possible to write a full webApp using only the DBMS (a couchApp).

There exist a javascript library that make it possible to react to database updates among other things. A couchdbApp is simply a database so you can copy an application to another server by syncronization: your clients can copy your app to their local server and then playing over a offlined LAN.

  • 2
    \$\begingroup\$ Card placement should be a POST (or a PUT if it's idempotent, but that's unlikely and not well-supported), not a URL to GET. \$\endgroup\$
    – user744
    Commented Jul 16, 2011 at 9:58
  • \$\begingroup\$ @Joe Wreschnig you are right, that URL was for illustrative purpose only and i didn't mention what method should be used. \$\endgroup\$
    – FxIII
    Commented Jul 16, 2011 at 10:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .