×   Home   Blog   Newsletter   Privacy   Contact Us   About

Writing a Game

During this shut in, I decided to write a multiplayer turn-based game using simple tools. Why? Just for the fun of it.
It’s like doing a jigsaw puzzle. Ultimately it seems like a futile and pointless exercise, and it would be, if it were not for the enjoyment of doing it, and the sense of achievement on completion.
I set myself some restrictions. I was going to use Notepad++ as my sole development environment, and use FTP to deploy files to the server. I elected to use PHP on the server side (I’m a masochist), MySQL for the database, and vanilla HTML (with a little JavaScript) for the client. If I needed graphics, I was going to use Paint.NET

Space Miner

The game is now out on beta release. If you want to skip the rest of this article and jump right in you can do so here. It’s called Space Miner.


A long time ago I wrote a small game “Lowest Distinct Integer” based, in part, on an idea that I read about in a paper.
That game was pretty simple; a bunch of people select a number with the goal of selecting the lowest number out of all the submissions. The catch is that the winner will be the lowest number that is distinct (unique). If you guess very low, there’s a really good chance someone else will have picked the same number. Guess too high and you’ll probably be unique, but way out of the running. It’s a classic Nash Equilibrium problem. If you think that others will think that you will think that they will think that …
For the Space Miner game, I wanted it to be able to be run continuously, and for people to be able to jump in and out as they had time. I also wanted people to be able to join in progress, and adapt based on how others were playing. To make it a little more interesting, I moved it to 2D, a little bit like a multiplayer Battleship game.

Other design criteria

I wanted to optimize the design so that it would run neatly on mobile, and this dictated much of the CSS and the viewport.
I needed a persistent ID to serialize each players' data. Rather then rolling my own login/password system (always a bad idea), and having to worry, not just about security, but account maintenance, and lost password issues, I decided to leverage facebook login. Integration was pretty easy. I know there are some facebook haters, but I’m also biased (having worked there for six years), and IMHO this is one of those situations where it is orders of magnitude better to leverage than rolling your own. If you are building a house, you buy bricks at the hardware store, you don’t buy mud and a kiln and try to make your own. My game only uses facebook to login and provide a unique identity; it does not post to your feed, nor access your friend list. I don't even store your email address.

Game Rules

You can read the final game rules here:

Space Miner

Space Miner is an online synchronous game. You are competing with all other players to harvest energy from Dilithium deposits buried deep underground.

To extract radiated energy you control the position of a remote satellite harvesting drone. You position your drone over the deposits and, once per time epoch, it will extract all the energy underneath it's collection array. The collection array of your satellite is a grid of (5x5) units.

You have a detailed map of the deposit densities, and these are displayed on your control panel. The brighter the colour on the scan, the stronger the deposit, and the more energy you will extract if your array is over that location.

If you were the only miner in the quadrant, this would be an easy optimization. However, all players are trying to harvest the same resources. If competing arrays overlap, the energy extracted is shared amongst the satellites. If two satellites are harvesting a grid location the energy extracted by each player is 50% of that grid. If ten players are harvesting the same location, they each only get 10%!

This creates a dilemma; but also allows for strategy. Do you position your array over a poor density location and extract 100% of a meager yield?, or boldly harvest a high yield area, knowing you will share your bounty? Maybe you'll take a middling strategy?

As the game progresses, more players will join and send in their satellites; efficiencies will decrease with the congestion. All players are able to move their satellites between harvesting epochs to a fresh location, so it's a moving shell game of Nash equilibria. In a previous epoch you might have been in a congested area; do you move to a potential new virgin location, or do you think everyone else will be thinking the same thing, so you should just stay put and reap the benefits of their defection?

You can move your satellite as frequently, or rarely, as you wish between harvest epochs without consequence. However, when the clock ticks to the end of an epoch all satellite positions are frozen, the harvesting happens instantaneously, the bounty divvied up, and control is released again.

If you do not move your satellite between epochs it will remain on station at the same location.

To assist you, your scan shows the location of your last harvest (in silver), and the red reticle shows the current location of your satellite (where you will harvest on the next epoch).

At the bottom right of the scan is an indication of the theoretical yield from your satellite array, if positioned over that region with no other players competing. Drag the red reticle around then hit the button to 'Lock Coordinates'.

At the end of each epoch you are able to run an analysis to see how efficient each grid of your array was, the bounty obtained from that grid, and the potential. This will give you feedback of the congestion and hints on how to manage where you elect to harvest on the next epoch.

When a player first joins the game, their satellite will be initially positioned at a random location. Satellites are autonomous, unmanned, and will remain on location even for inactive players (so if a player joins, plays, then never logins in again, their satellite will remain on-station at the last location they left it, creating an ever congested, but static, background drain).

Currently, time epochs are approximately once per Earth hour (this may change as the game develops).

I plan to run the game for about a week at time, see the results, then reset the entire database and start fresh with a new game.

The aim of the game is to be the person who extracts the most energy at any epoch. At the end of each epoch, all players are ranked ordinally. In this way, players who join in-progress can still play competitively against players who started the game earlier.

Harvest well, Space Miner!

Game Mechanics

Game play happens on a 32x32 grid. Each square on the grid is given an ore concentration value ranging from 0-255. I generated the distribution using a fractal plasma algorithm. I was intending to code to allow grids of different sizes and distributions, and allow multiple games to be played at the same time on different boards, but like all projects, you have to know where to cut. The goal of this v1 release was a prototype to test game play, functionality, and mechanics. In the interests of speed and getting other code out, I generated one board, and made this fixed.
The ore concentration data was stored in sql, using a tileid formed from the x,y coordinates (y*32)+x.
I wanted to store all player status in SQL. This was so players could login from anywhere and from multiple devices. Whilst login credentials are passed from page to page as a session, each page pulls the state it needed from SQL, fresh, before rendering anything (not relying on state being passed from page to page).
As per the rules, players are able to asynchronously make adjustments to the game, but all movements are interpreted, synchronously, in a game update. I elected to call these updates time epochs. Updates are triggered automatically by a recurring CRON job on the server. When the CRON job fires, the game is temporarily set in a ‘read only’ state by a flag in the database. The page that updates a player’s move tests this state before allowing an update. Every other page does just reads the data it needs. The update makes all the necessary calculations for scoring and updates the database. All the update logic is performed on the SQL side.
I wanted players to remain in the game even if they were not actively micro-managing their positions. To achieve this, on each epoch update, each player’s harvester is immediately placed into the next epoch at the last location it was at it. A player is free to override and move, but if not, her position propagates forward. A new player joining is allocated a random location.


Writing the game did not take too long. What took considerably longer were the tools needed to test the game. I needed tools to generate test users that I could add singly or in batches. I needed tools to move players. Tools to reset the database to start a new test, tools to stop and start the service. Tools to log, display, and visualize player moves to help with debugging. More time has been invested in the admin tools than the game play. I think that’s par for the course.

Alpha to Beta

I pushed an alpha version pretty early to a couple of friends as I was working on tools. As this was being played, I continued to add functionality. The two major features I added were the ability to see the efficiency of your harvester, and also a short range scan showing the region and competition around you (even though you don’t know who these people are).


Before the game launched, I was curious what different strategies would evolve. Would everyone plumb for the high yield areas and play chicken about who would move? Would players aim for a middling region for more efficiency? Would some dumpster dive and go for sucky regions and just wait it out below the radar? As it happens, I got a fair mix of all three kinds.
There are a fair number of dormant (stagnant) players choking the map (and over some good regions), and there are active players. The active players are all slowly spreading out realizing that it’s better to have 100% efficiency than share a bounty. I think this will continue until there are more players in the game and map gets covered more completely.


I have plenty of ideas for v2: Ore that decays over time to prevent squatting and orphaned players. Movement that is not instantaneous (requiring you to think about your next location), and the path you will take to get there (harvesting as you go) …
There’s no real end to the current game, and no bragging rights, other than currently being at the top. Making the ore finite and non-replenishing would enable a cumulative score based on ore mined to be determined, and make a defined game end.

Play the Game

What are you waiting for? Try out the game now!