Archive for the ‘Game Design’ Category

One game a month

Saturday, April 13th, 2013

This year, I’m taking part in the One Game A Month challenge, in an attempt to build a habit of finishing games. I’m not quite a game making machine yet, but even if some parts are rushed I’ve already produced far more in terms of gameplay than I did in the whole of last year. Having a short, enforced deadline for each game helps avoid the temptation to procrastinate with planning or polishing as an excuse.

So far, I’ve managed to get three playable games done and submitted:

Pipeline – An endless Pipe Mania.

Arc Breaker – A very simple, stylised shmup.

Rain or Shine – A puzzle game, and my first ever HTML5 / canvas project.


Monday, July 19th, 2010

I got a little stuck on a project this weekend, so for a change of pace I decided to remake an old puzzle game experiment and polish it up a bit.

Play Skiagraph
Drag the small bars at the bottom to try and make the two graphs match up.
For more (or less) of a challenge, you can change the number of blocks using the boxes along the top. One or two blocks is obviously trivial, but it can get very challenging from six upwards.

A six block puzzle.

The patterns the blocks make reminded me of paper chromatography experiments we did back at school, and my brother suggested they were a bit like X-rays, which apparently were once called “skiagraphs“. “Skia” comes from the Ancient Greek for “shadow”, which seemed appropriate, and in any case it sounds a lot better than “Block Puzzle”.

I wanted the interface to look like an LCD screen, so I’ve experimented with adding a couple of slightly unnecessary full screen effects. They eat quite a lot of CPU, so you can turn them off in the context menu if you prefer.

Designing Entanglement

Wednesday, July 14th, 2010

Entanglement is a board game idea I came up with a couple of months ago, with a Flash implementation that lets you play with another person locally or against the computer. I think the seed for it came from a dream I had one night, although all I managed to actually recall of it in the morning was “Mancala on a chessboard“.

Mancala is a very old family of board games whose basic move involves taking a pile of pieces, then placing them one at a time in a row as if you were sowing seeds. In the version of the game that I know best, the board is made up of two parallel rows of depressions — one row belonging to each player — along with large spaces for each player at the ends. You move around the board in a loop, always in the same direction. If the last piece in your move lands in an empty space on your side, you capture all of your opponent’s pieces in the dip opposite. There are only one or two special rules beyond this, making it a very simple and satisfying game.

I took the counters from a little travel Connect Four set and started experimenting with transferring this movement to a grid. At first I tried allowing movement in any direction, but this quickly became confusing, with chains overlapping and squares containing piles of both colours. Restricting movement to squares of your own colour meant that you could now only move diagonally, and kept the two sides permanently separated.

The board at the start of a game.

Mancala style capturing didn’t make much sense on a checkerboard, so I tried out a rule inspired by Go (or by my simple understanding of it), capturing your opponent’s pieces by surrounding them with your own. However, with the pieces restrained to their own squares, it’s not possible to simply surround a group of squares without there being an empty square of your own colour inside. Disallowing this reduced the possible capturing formations down to diamonds made of four squares around a single square, or partial diamonds against the edges of the board.

To resolve situations where diamonds overlap and multiple squares are surrounded, whichever diamond has the most pieces captures first, and diamonds with equal populations capture simultaneously. This means you can safely capture a square that is part of a diamond as long as you build a stronger diamond, and it’s possible to sacrifice a piece to break a diamond if you can only match strengths.

White has just formed a diamond within a black diamond. Both pieces within the diamonds would be captured simultaneously.

Finally, the layout of the board — which squares have pieces on and which don’t, ignoring the actual number of pieces on each square — must change with each move. This is probably the least clear of the rules, but it’s the most elegant way I’ve been able to come up with to help avoid easy stalemates.

These rules (which are listed in the Flash game as well) seem to allow for a lot of strategy and interesting situations. I haven’t had a chance to really test the game with anyone apart from my brother though, so any suggestions or improvements would be very helpful.

Play a work in progress version of the game here.
(The computer opponent is still a little buggy, and can become extremely slow if you build large towers. If you run into problems, the easy difficulty level is much faster, if a bit less smart.)