The main purpose of this blog is to keep track of my various projects and to document them. The end result would be a long list of projects with all the associated metadata which can then be summarised to make browsing them easier. The Project List is a meta project that does just that. Each project on my website gets a file named project.php associated with it that contains the meta information. They are then gathered by the Project List and can be sorted, filtered, and displayed online. I’ve also added static pages, blogs, and talks to the lists of resources. You can view the Project List to read more it. This was tied in to a major update of my website, as I had to create new preview images and new styles to match the new way of showing the projects. This will probably evolve further over time, but for now it’s fine.
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.
While updating my website, another project that needed a little attention was the Wolfram rules (Live page) project. Apart from looking a little poor in its presentation, it was an experiment in DOM manipulation where a huhe HTML table was used to display the resulting algorithm. While it was nice to see that the DOM and CSS worked as they should, this project was better suited to the canvas, so I moved over to the canvas and added some colour to improve the presentation.
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.)
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)
One of the features I want on my webpage is the silhouette of a skyline to use as background image. This project is aimed at allowing the user to draw a complex skyline, with the possibilty for animation.
The user can create individual “buildings” with many layers, and then arrange the buildings into a skyline to generate an image. If possible, the user can animate the image (for example adding lights at night, allowing the sky to change to match the time of day.)
The design would take place on the canvas, with a suite of tools to allow the user to correctly determine the size of buildings, add arches, spires etc. A second layer would allow the user to add windows, and a third layer would allow them to add other features. These would then be saved to file and a script would read the file to render the images on screen. The images would be rendered on a canvas that sits behind the main content of the page. This project is largely a problem of geometry.
Challenge: Initially I wanted to set the canvas as the background of the page.
Challenge: The user needs a simple and intuitive interface.
Solution: This project allows the user to draw wire frames for the buildings. They can draw straight lines, circle arcs, and quadratic curves. The interface is not perfect, but it is easy enough to quickly make buildings. A grid is also provided so the user can keep track of sizes. (Resolved)
Challenge: This projects needs to be able to calculate interections and unions of polygons.
Solution: One of the hardest problems to solve is the interserction and union of two shapes, so that the user can make complex shapes. This is a non-trivial problems of geometry and finding solutions online was not east. I honest cannot remember if I completely solved this problem or not. (Resolved, to be revisited)
Challenge: This project would ideally respond to the client’s time.
Solution: Animation and time dependence has not been implemented yet, but eventually the colour of the sky and weather would chance, lights would turn on and off, and vehicles would move. This should be relatively simple to implement, once I find the time. (To do)
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.
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)
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.)
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.
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)
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.
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!
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)
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.
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.
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)