Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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 :)

share|improve this question

migrated from programmers.stackexchange.com Jul 15 '11 at 19:56

This question came from our site for professional programmers interested in conceptual questions about software development.

    
How many concurrent games does your engine need to handle? –  Darien Jul 15 '11 at 18:34
    
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.) –  Robbie Jul 15 '11 at 18:43
add comment

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.

share|improve this answer
    
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. –  Robbie Jul 15 '11 at 21:44
    
That sounds like a good plan to me. If the code will keep you interested, I say go for it. –  Nate Jul 17 '11 at 18:01
add comment

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

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

you can use the URL

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

to modify the model and

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

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.

share|improve this answer
2  
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. –  user744 Jul 16 '11 at 9:58
    
@Joe Wreschnig you are right, that URL was for illustrative purpose only and i didn't mention what method should be used. –  FxIII Jul 16 '11 at 10:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.