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)
Here’s something special for the 100th post! It’s project I use to manage projects.
This project was made to manage other projects. Each project has its own metadata which is parsed and arranged to give a useful summary of what the project does, how it was developed, and what I learned during development.
Each project has a python script that summarises the metadata, including the GitHub repository, the relevant links, a short description of the project, and details of implementation. Summaries are made for the Projects WordPress blog, and special links made for the PHP pages for projects that are hosted on my website. The scripts are organised so that they iterate over all projects (currently 83 and growing) at once, allowing a summary of all projects to be formulated.
This project management will eventually be extended to include icons, images, and other useful information. So far this has mostly be used to allow me to catalogue my existing projects in my spare time, which has taken ~15 months, but now that is nearly complete my needs will change, so I will add new functionalities.
Challenge: This project needs to be versatile enough to handle a lot metadata about many projects.
Solution: In order to accommodate so many projects I had to create a new top level directory in my user space which is arranged hierarchically by category to contain all the projects. The choice to use python is motivated by the need to have a project management system that is versatile enough to handle a wide divrersity of projects with different metadata. (Resolved.)
I keep a project 365 page, which means one photo per day. It’s a good way to keep track of the passage of time and as I take my camera everywhere with me it’ quite easy. After using a blog for the photos I soon became frustrated at how long it took, so I decided to make my own wrapper for the images.
Challenge: Given the large number of images there are a huge amount of HTTP requests.
Solution: Each thumbnail image comes with an overhead that could be reduced in the following way. The thumbnails can be combined into a single image which is indexed according to the date of each thumbnail. This can then be sliced up by client using a canvas and arranged on the page. Doing this would save a lot of time and bandwidth for both the client and server, but would require rewriting much of the code, and it is a low priority. (To be revisited.)
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)
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.
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.
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.
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 design went through a few iterations before settling on the current choice:
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.
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.
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.
Here’s the page as it currently looks. It needs a bit of a facelift!