Architecture and technologies

All projects that somehow make usage of code.
User avatar
Posts: 101
Joined: Thu Oct 13, 2011 11:50

Architecture and technologies

Postby xarn » Thu Nov 24, 2011 17:47



This follows the classical 3-tier architecture:

Client <-> Server <-> DB

It has been taken care to have all these components totally independent. At any time, you can swap the client with another, the server with another, and the database with another. As a consequence, we are not bound to a particular technology to implement any of the three pieces. In the same time, the server can be used by either web-clients or classical desktop applications.

The communication between client and server is defined by a protocol, so that any client sticking to the protocol can use the server, and vice-versa. Between the server and the DB, SQL is used, making a change in DB relatively easy.


Whenever a player makes an action, the event is propagated to the server.
The server then checks the validity of the action, and notifies both players of the consequences, or cancels an erroneous action. To do so, the server keeps track of the whole state of the game (which card is where, in what condition, etc).
Clients receive events and apply them.


It has following advantages:
- trivial to parse
- very readable in logs
- you can interact with a server using the command line

For complex structured data, like the whole game state, it will be encoded in JSON.


From playerA: move card_12 to sideA resources
To playerA: move card_12 downside to sideA resources false
To playerB: move card_12 downside to sideA resources false



Why use websockets? For three reasons:

1. Performance:
http requests require a 3 way trip to send a message to a server:
- a tcp roundtrip to establish a connection
- a tcp packet to send the information
Since a websocked is an open tcp connection, it requires only:
- a tcp packet to send the information
...which is of course 3 times faster

2. It is stateful and event-driven
once a connection is opened, you can keep the game state in memory and modify it along with incoming events. You can also push information to clients, which will then update their view. This avoids constant polling like in http solutions.


javascript (it's heavy on javascript, it will probably reach thousands of lines)
jquery (to a lesser extend right now)


Currently: ruby
But planned to switch to java also, there is a lot of code.

Return to “Code”

Who is online

Users browsing this forum: No registered users and 1 guest