Building a Turn-based Strategy Game

My current side project is a small-unit turn-based strategy game. If you've ever played Advance Wars or Final Fantasy Tactics that's what I'm shooting for.

It's a niche, but it has a number of things to recommend it as a side-project.

  • Since it's turn-based, it's easy to model and you don't need to be overly concerned with client-side performance (or server-side performance, outside of AI / pathfinding).

  • The necessary artwork is limited, but it can be made as elaborate as you want.

Further down the road, my plan is to experiment with building multiple games using the same engine. This is feasible because you can change the game enormously by switching out what actions are available on what units and when those actions can be taken.

The first step though, is to get the whole thing working. The necessary pieces can be broken up pretty clearly.


The client is only responsible for rendering animations, displaying the status of the game and doing some basic UI logic (e.g., choosing & targeting actions).

The goal is to keep the client as thin as possible so it is implemented with only two states:

  1. Animating - this is where we play back any pending animations to the player

  2. Waiting for Input - this is where we accept new commands from the player

Eventually, the input will involve some sophisticated logic so that we can provide a pleasant UI for the user but, in general, the client has no idea what is going on.

In case any one is interested, I'm using Angular to manage the standard web server UI and communication with the server and phaser.js for writing the actual game rendering and UI.


The server handles everything else. This includes all of the standard web server stuff (authentication, rendering HTML) as well as actually performing the logic for the game.

A more sophisticated architecture might split things out a bit more and put the logic for the game into a separate service. I might go that route eventually and it will be easy to split off, but I think that would be over-engineering at this point.

I'll leave out the specifics on the standard web server stuff aside from mentioning it's running on Scala Play 2 and using the SecureSocial library for handling all of the user management logic (e.g., signing up for accounts).

The actual game implementation is more interesting. We accept commands from players and collect them in the database. When we detect that all commands are available, we read the current game state from the database and process the commands to create a new game state.

In a nut shell, that's the whole thing. The next article will deal with modeling the game state and commands.