Category Archives: Games

Update: Tangles

While giving my website a facelift I deciced that the Tangles (Live page) project needed some attention. The page was previously the main game, followed by a mess of buttons and then instructions. I rearranged the content to give a proper introduction and made an in-canvas transition screen between levels. The end result looks much nicer and now it’s almost a completely self contained game. With some more work it could be made into a standalone app for the App Store. This project also benefitted from a higher resolution canvas than the actual element size, leading to better graphics.

Screenshot

Tangles, with a new transition screen
Tangles, with a new transition screen

Update: Conway’s game of life

As part of my website’s facelift I decided to update the Conway’s game of life (Live page) project. The content was rearranged to make more sense to the first time user, a the controls organised in a way that made them larger and easier to navigate. I also changed the links to different shapes to be gallery objects (similar to what I had for the Mandelbrot project.) This is also the first page to get the “You might also like…” feature at the bottom, which will soon appear on most other pages when I get time to add them.

Before and after

Conway before the update
Conway before the update
Conway after the update
Conway after the update
Conway after the update
Conway after the update

Update: Trigger game

In recent weeks I’ve been working a lot on the Trigger game (Live page.) These update have included an overhaul of the style, addition of new pages, rewriting of the “Spy mode”, adding new particles, tweaking the graphics, and many more changes behind the scenes. The code was significantly refactored to make it easier to extend and understand, as now this has becomes a collaborative project. The game has been tested on a few schools and shown to be a good success with children (and adults) and it seems to have a bright future. I also added sounds, music, and a simple music player.

Screenshots

Updated event display
Updated event display
Showing the various modes (some in development) with a garish colour scheme.
Showing the various modes (some in development) with a garish colour scheme.
Updated Spy mode, analysing the data.
Updated Spy mode, analysing the data.

Work in progress: Google Maps war

This project was made partly to combine the Hexagonal civ game with Google Maps, and partly to push the Google maps API to its limits. It turns out that Google Maps is not suited to this heavy use.

Links

Live page
GitHub repository

Overview

This project is intended to be a Risk style conquest game based on a map of Europe. The maps would be split into hexagons with rules for how the different unit (land, air, sea) could move from place to place. The map is split into equal areas of latitude and longitude with values chosen to best suit the arrangement of cities. Ideally the economic value of each hexagon would be taken into account, although this would require quite a bit of research. The connections between the hexagons is already defined, so in principle this could lead to a rather simple game by randomising the economic and defensive values of each hexagon (or giving them all equal value.)

Challenges

Challenge: The hexagons should be arranged in equal latitude and longitude, which isn’t necesarily equal area on the page.
Solution: The hexagons are not equal in area, so I had to draw them from the centre of each hexagon and find their vertices using polar coordinates around the centre of the hexagon. This was the first time I had drawn the hexagons this way and it turned out easier to make the drawing functions if I did it like this, given that I had already solved the coordinate problem in the hexagonal civ project. (Resolved)
Challenge: The game requires quite a bit of data entry.
Solution: Finding the economic values of each hexagon is very difficult and time consuming, so this has been put off indefinitely. The connections for the land, sea and air units have already been determined. (To be revisited)
Challenge: Drawing the hexagons requires drawing many polygons.
Solution: Using geometrical experience from the Skyline project, I found a reasonable way to label the hexagons with hatching in a colourblind friendly way. However the sheer number of polygons means that the performance is quite poor. It might be prefereable to draw the large map without Google Maps, and only underlay Google Maps when the user requests it. (Resolved, to be revisited)

Screenshot

Sample Google Maps War map.
Sample Google Maps War map.

Work in progress: Hexagonal civilisation game

It’s another unfinished game!

Ever since I played Sid Meier’s original Civilisation I’ve wanted to make something similar to explore the gameplay and create something fun to pass the time.

Links

Live page
GitHub repository

Overview

In principle this game should be fairly easy to develop because it is turn based and each problem (except the AI) is well defined. I first tried developing a game using SVG and one of my friends suggested using hexagons, which gives it a nicer, more rounded feel. However like many other projects this one is much lower priority than the others and it’s hard to justify the large amount of time required for development, so it’s stayed in a very rudimentary state for a long time.

As usual this game uses the canvas with the normal model for user interaction that I developed when writing the Feynman diagram maker. The rest is simply a matter of keeping track of the variables needed for the game to function. The interface would be as clean and elegant possible, as I felt this was the main advantage the original game had over the rest of the series.

Challenges

Challenge: This was one of the first games I developed using hexagons.
Solution: The choice to use hexagons leads to some non trivial problems. The most important challenge is the choice of coordinate systems and arranging it in an intuitive manner. It tooks some trial and errr but in the end I created a map that could be used for the development of the game. (Resolved)
Challenge: This game would need some (basic) artificial intelligence.
Solution: This is something I haven’t even started to think about yet! (To do)

Screenshot

Screenshot of the game, showing units and overlapping cities.
Screenshot of the game, showing units and overlapping cities.

Work in progress: Maze game

Following on from the Platform game and Explorer game I wanted to create a tile based game. This was partly inspired by the game Kharne which I had played many times, and I became frustrated with the lack of similar games online. (It was this frustration that lead to a minro obsession with 91, and the creation of the huge 91 map poster.)

Links

Live page V1
Live page V2
GitHub repository

Overview

This game builds on the experience I gained from the Platform game, Explorer game and others. The player finds themself on an island where they must pursue several adventures. All of the graphics are procedurally generated and the emphasis is placed on making each adventure unique and special, rather than “Collect 100 coins” or “Beat this boss”. Like the other similar game projects the progress has been postponed here, as other projects are considered more important.

Challenges

Challenge: This game needed dialgoue trees and combat.
Solution: I wanted to make a game with some standaard dialogue and combat functionality for NPCs. The dialogue tree to a while to work out, mostly because there’s no clean way to do it, but I’m quite happy with the outcome. The combat was easier to manage, but it will take some iteration before it becomes optmised. (Resolved)
Challenge: I wanted to arrange object pseudorandomly on the canvas.
Solution: One of the things I wanted to do was auto-generate environemnts (for example, arrange flowers on grass randomly.) Initially I used random number to do this, but immediately found that the flowers would move around as the player moved! To get around this I used the room and position coordinates to generate pseudorandom numbers, which work much better. Some objects moved (such as bees around the beehive) so for those I added a time dependent part to the motion. (Resolved)
Challenge: I wanted to envinonment to change slowly.
Solution: I wanted to have an adventure where the life on the island slow dies, and I made an effect where the grass slowly fades from green to grey. This needs to be changed so that it only comes into play during certain missions, but I am very pleased with the result. It looks very creepy and it was quite easy to implement. I took some inspiration from for this. (Resolved)

Screenshots

Screenshot of the first iteration, testing dialogue trees and NPCs.
Screenshot of the first iteration, testing dialogue trees and NPCs.
Screenshot of the first iteration, testing objects, button, and doors.
Screenshot of the first iteration, testing objects, button, and doors.
Start sceen in V2.
Start sceen in V2.
Special effects in V2!
Special effects in V2!
One of the more complex rooms in V2, showing the grass slightly faded.
One of the more complex rooms in V2, showing the grass slightly faded.

Work in progress: Explorer game

This project is a game where the player explores rooms with a top down view and does all the normal things, such as traverse mazes, open doors, fight monsters and so on. This is a gravity-less version of the Platform game and has an even more retro feel to it. It’s obviously a work in progress and needs a lot more work, but the main mechanics are complete and it even has its own editor.

Links

Live page
GitHub repository

Overview

The game works mostly through simple collision detection. This differs from the platform game in that is has moving enemies that can be killed through shooting. Given that it’s in the development phase it’s lacking any coherent narrative, but one day when I get time I’ll come back to this game and add a lot more to it and make it much more interesting.

The game has an editor where the developer draws lines onto the canvas to define where the walls are. There are some features that need to be added to the editor, such as choosing the line colour, and being able to move vertices around or break up lines.

Unlike the platform game, this game uses procedurally drawn graphics. This was quite fun to write!

Challenges

Challenge: This game requires fairly robust collision detection.
Solution: Collision detector has to consider two different cases in this game: the intersection of lines and the intersection of rectangles. For recangles it’s easy enough but for lines I needed to write an algorithms to check the overlap. Once I had this I could use it in other projects. The number of potential collisions scales with the number of lines in each room, so I tried to minimise the number of lines to something sensible for gameplay reasons. (Resolved)

Screenshots

A screenshot of the game in all its simplicity.
A screenshot of the game in all its simplicity.
Screenshot of the game editor.
Screenshot of the game editor.

Work in progress: Platform game

This project is something I’ve been working for a long time and something I have wanted to develop for as long as I can remember. It’s a platform game strongly inspired by the BBC Micro game, Citadel. (I have another project dedicated to mapping Citadel.) When I was younger I would dream about playing non-existant extra levels in Citadel, and when I started recreational programming I would sometimes dream about making new levels for the game.

Links

Live page (Play)
Live page (Edit)
GitHub repository

Overview

The game is organised into a two dimensional array of rooms, which are subsequently split into blocks. Each block is then specified using a shape, foreground, background, obstacle, medium, and objects. The medium can be air, water, fire, solid rock etc, and the obstacle is wall, ladder etc. The foreground and background are purely cosmetic. The objects are things like coins, doors, keys etc.

Motion is controlled using the keyboard and is handled on a pixel-by-pixel basis. The function defining the motion are very loosely inspired by , although all the code and algorithms are my own. The player is modeled by a rectangle which is moved across the blocks pixel by pixel, searching for collisions. When a collision is detected movement is stopped along that axis. If movement along the other axis means there is no longer a collision then movement along the first axis resumes. This is how collisions were handled in Citadel, and was something I wanted to replicate. When the collision happens at \(45\deg\) the ambiguity is resolved by the direction of movement of the player. (For example if the player is moving down along the \(y\) axis and collides with a corner the player will move down instead of horizontally.) The movement was initially monitored using a “mask” of pixels surrounding the player, with a special mask view for debugging, but this has since been retired due to the huge CPU demands.

This game is in progress, so at the moment there is very limited functionality. The physics engine is pretty much complete, although it would benefit from some optimisations. The main environment types have already been developed, including air, water, solid, fire, and ladder. A few extra features have been added including trampolines and the double jump feature. The features I was working on when I paused development were interactions with objects and the inventory, and adding a “pain” feature instead of instant death (another feature of Citadel that I very much enjoyed.)

The game has an editor so that the developer can “draw” rooms onto the canvas directly instead of writing things in a text editor, as it was arranged initially. This speeds up content writing a lot, but there are almost certainly some features that need to be added to make this better, and probably a handful of bugs that need to be fixed as well.

When the player or editor goes into a room that does not exist, a new room with the name “Nothingness” is automatically added to the map. This is very important because players always find new ways to break the map. In fact this is something that was handled very well in the original Citadel, although it did lead to a serious exploit, where players could “fall off of the edge of the map” and end up elsewhere.

This game needs some more development, but already it has potential to be very interesting. As well as adding more content and assets it’s necessary to optimise the game play so that it can be played on lower end computers.

Bonus!: Before the canvas was available I tried to make a platform game using SVG. As I’ve already discussed before, using SVG with Javascript is a pain since the Javascript must be cleanly embedded within the SVG document itself. This didn’t stop me though, and I made a very bad proof of principle game where you can see some of the problems with moving platforms: SVG platformer.. This game also has a game breaking bug associated with how different browsers handled text nodes and how the standards changed.

Challenges

Challenge: This game needed a decent physics engine.
Solution: This was my first time writing a physics engine, and being a physicist I thought it would be easy. I was wrong. I love classical physics and its inherent beauty, but writing code for a classical physics enging is hard. I started out with a ball bouncing around a square room, followed by adding gravity, then adding player controls. I built up the model step by step until I had something reasonabe and intuitive. It was a very informative experience. (Resolved, to be revisited)
Challenge: The rooms needed to have some kind of model that was both versatile and had good performance.
Solution: I built the rooms out of blocks. Each block had a shape and this allows the developer to create a detailed room for the game, as well as having pixel perfect control over the player’s movements. however this comes at the cost of performance, so some additional gains needs to made with the physics engine. The versatility of the room design is excellent and I am very happy with the amount of creative freedom the developer has in assembling the rooms. (Resolved)
Challenge: The double jump feature needed to be added.
Solution: One of the options I wanted to add was a double (and triple etc) jump to make some areas accessible only once this feature is enabled. Doing this meant keeping track of how many jumps had already been made, and from what kind of surface. This was not a trivial thing to do and it helped make the physics engine more robust. (Resolved)
Challenge: The rooms has to be stored in an array, which could be turned into a map.
Solution: Storing the rooms in an array makes it easier to access them and reduces memory usage. At the same time it means keeping track of additional coordinates which brings their own problem As the player (or game developer) moves into new rooms, new rows and columns are added to the array, meaning that indices must be updated. This caused a few bugs, but was finally resolved. The developer also has access to a map of the rooms, which is something I may add for the player as well. (Resolved)
Challenge: This game requires quite a bit of pixel art.
Solution: The style of the art in this game is heavily inspired by Citadel, but there are other parts I made myself. The pixel art used to make the blocks was made using the Painter project, which was in fact written explicitly for this game.. (Resolved)

Screenshots

Screenshot of the game in developlment.
Screenshot of the game in developlment.
Screenshot of the room editor in developlment.
Screenshot of the room editor in developlment.

Work in progress: Trigger game

Like the Science Shift Simulator, this is a game that emerged as a subset of the aDetector project. The player has to save events that match the criteria given, just like a trigger does in real life. The results are then combined across all the players in a given team to determine the final score. The scores can be combined across experiments to make a “discovery”. This is still in development, which will continue over the net week and months.

Links

Live page
Spy page
GitHub repository

Overview

This is another cooperative multiplayer game aimed at showing the public (especially high school pupils) how particle physics research actually takes place. Any number of players can take part and they are split into “Team ATLAS” and “Team CMS”. The score of each team is determined by the performance of the players on each “shift” they take at the trigger, and the final scores are combined for the discovery of the Higgs boson. There is also a “spy” mode where people can see the events as they are submitted.

Challenges

Challenge: This project needs an attractive, fast, and realistic detector model.
Solution: Having already developed a decent detector model for the aDetector project, I simply used a two dimensional version for this project. I then split the detector finely in \(\eta\) and \(\phi\) to make interactions between the particles and detector easier. The aesthetics went through a few iterations before settling on the final design. However further optimisations and aesthetic changes are anticipated as development continues. (Resolved, to be revisited.)
Challenge: This game puts a bit of a strain on my server.
Solution: My web space uses a shared server, so sometimes many HTTP requests from the same client looks like a Denial Of Service (DOS) attack, resulting in a throttling of the requests. There are two main strategies to overcome this. The first option is to bundle up several requests into one request, reducing the total number of requests, and the load on the server. This solution has not been implemented yet. The second option is to change the server settings. I do not have access to these, but as development continues I intend to move to a different server that can handle so many very small requests. (To be revisited.)
Challenge: This game needs cross platform and cross device support.
Solution: This game was initially intended to be played with an iPad, but I did not have an iPad for testing. On the day of the release of the game I had to tweak the settings so the response times were slower with respect to mouse events to make it easier to play on a tablet device. These settings are trivially changed to allow multiple device support. (Resolved.)
Challenge: The game should be repsonsive to the inputs of the user.
Solution: Initially the game did not confirm success when a user clicked on the screen and this lead to confusion. As a result I had to add a big green “tick” for success and a big red “cross” for failure to inform the user of the status of the event. (Resolved.)
Challenge: The game needed an animated histogram for the final result.
Solution: I’ve made histogras before, including histograms that update themselves on the aDetector project, but until now I had not animated a histogram. This was a bit tricky as I had to call events which were using the this keyword, so the histogram object had to be stored as a global variable because, although I’d like to, I couldn’t use this to refer to the histgoram. Javascript can be frustating like that. (Resolved.)

Screenshots

I don’t normally put lots of screenshots up, but I’m quite proud of the asethetics here, so here are the three main screens of the main game:

The front page of the game.
The front page of the game.
The transition page of the game.
The transition page of the game.
The game in progress.
The game in progress.

The design went through a few iterations before settling on the current choice:

Design 1
Design 1
Design 2
Design 2
Design 3
Design 3

Work in progress: Science Shift Simulator

The Science Shift Simulator game is something that emerged from development of the aDetector project and LHC Driver projects. The mechanic is loosely based on the cooperative game Space Team. This is still in development, so the current page doesn’t actually work at the time of writing, and development will continue over the net week and months.

Links

Live page
GitHub repository

Overview

This is a cooperative multiplayer game aimed at showing the public (especially high school pupils) how particle physics research actually takes place, with an emphasis on cooperation. The game proceeds by bringing up several issues that need to be solved. The “Shift Leader” has information about how to solve the problems, but no control over the various subsystems. Instead they have a team of “Shifters” whose job is to solve the problems. This then becomes a problem of communication, cooperation, and optimisation between the various players.

For this project each player has control of a browser, which communicates with a central server. The Shift Leader’s client sends problems to the server, which are then collected by the Shifters’ clients. As a result the main difficulty in developing this game is synchronisation, especially when there are network problems!

Eventually this project will be reskinnable to allow other developers to add their own content. This will also be moved into a collaborative space, as this will have several developers in the future.

Challenges

Challenge: The big problem is synchronisation.
Solution: This is not the first project I’ve developed that required the client and server to communicate via AJAX requests, but it is the first that had more than one client sending information to the server. In fact it was this project that persuaded me to install MySQL locally and hook it up to Apache to get a local LAMP stack running on the my laptop. I got a prototype version working for demonstration purposes, but had to cut some corners. Development stopped in the middle of a significant rewriting of code, which is still to be completed. (To be revisited.)
Challenge: This game contains many mini games.
Solution: This is the first game I made that has mini games in it, and this required a different strategy for development. Making a generic mini game module in Javascript is not easy, and there will be some further significant changes as I rewrite this code again. (Resolved, to be revisited.)

Screenshot

Here’s the page as it currently looks. It needs a bit of a facelift!

Screenshot of the Shift Leader's page
Screenshot of the Shift Leader’s page