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.
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!
In the mid to late 2000s I used to visit an LGBT social networking site, Thingbox. The site had many features, but the users wanted more. It was around this time that I was discovering how to use greasemonkey, so I put together many short scripts. Eventually I combined them all into a single script called greasebox that was very popular. It has been many years since it was maintained though, so I doubt it still fully works.
The website provides a huge amount of information via AJAX and HTTP requests, and this project required some clever reverse engineering to get right. When the scripts are combined they are modular, and they are executed in a specific order to prevent clashes. A few modules are inter dependent, so they are arranged in the correct order, otherwise it goes from least to most fragile. There is also a debug tool to see exactly whre things go wrong. There is also a detailed interface page where users can change their settings.
Unfortunately I don’t have a screenshot of the project, since it was developed so long ago (last touched 2011/02/05) and in browser scripting has changed a lot since then.
- Challenge: This had to use the Thingbox “API” properly.
- Solution: Although Thingbox didn’t have an official API, I reverse engineered how things worked to make it do what I wanted. This occasionally required help from other users (eg to send friend requests) but was mostly possible on my own. (Resolved.)
- Challenge: The content had to be intuitive and responsive to users’s needs.
- Solution: This was one of the first projects where I had to see things from the point of view of the user and make things as intuitive as possible. The aesthetics of the project had to fit in with the Thingbox style, not only to look good, but to be usable. This meant that I had to deconstruct and understand the rationale behind the site design and the choices the creators made, which was very informative. I also had to pay close attention to requests and questions from users as they arose, which gave me a lot of insight into how to make things as easy to use as possible. (Resolved.)
- Challenge: When combining modules the order mattered.
- Solution: I had several modules that would go through and edit the content of the page. Obviously this would cause problems if it wasn’t done carefully, so I had to order the modules in the correct way. This was not trivial to do, but made management much simpler. There was also a dedicated debug module that would take information from the current session and print it to a div element that the user could attach to the page with a special command. This debug information allowed me to determine exactly how far the scripts got before a module caused a problem. (Resolved.)
- Challenge: This project suffered from a sense of humour.
- Solution: I was writing for a group of mostly well educated middle aged gay men, and as a result there was a lot of banter and humour. I would create puns for each of the single modules. (For example one of the running jokes was constant references to internalised homophobia, so I called the script that open external links in a new window “externalised homophobia”.) This did not help when I tried to combine the modules into a single script, and I will not be making that mistake again! (Resolved.)
- Challenge: This needed cross platform and cross browser support.
- Solution: This was probably the most difficult challenge to overcome. I would test in Firefox with a mac, but there were many users who insisted on using Window, Chrome, and sometimes even Safari. Each one had different nuances (including counter intuitive storage of information) that had to be understood to make features work. Although I tried very hard to make it work, there were some features that didn’t make it onto every browser. (Mostly resolved.)
- Challenge: The project required detailed manipulation of the DOM.
- Solution: It was with this project that I learned how to use the DOM, which helped me to better understand the heirarchical structure of XML in general. I also wanted the HTML to be semantically pure, so while I used the DOM to store some information about the state of the game, I also ensured that it was semantically consistent. (Resolved)
- Solution: This was probably the most difficult and instructive part of the project. I had to learn how to register event handlers in a manner which worked across browsers. I still use the same style of event handling today that I developed when I wrote this project. It took a while to get used to the issues of synchronisation using the window.setTimeout method, which I still use frequently today. (Resolved)
- Challenge: I had to store some data on the server.
- Solution: I had had plenty of experience with PHP and MySQL before this project, including sanitising input to the database, so the PHP side of this challenge was easy to implement. However making the httpxml requests was not so easy and took some practice. After a few iterations I got a working model, although this is something I should improve further, as httpxml requests tend to be rather messy. (Resolved)
- Challenge: One of the users wanted a feature that required cookies.
- Challenge: The game has a soundtrack.
- Challenge: The game had to have cross browser support.
- Solution: This game was initially developed using Firefox, but one of the users wanted it to work with Chrome. This was the first time I met the frustration of cross browser event handling, which has been something of a pain ever since, but it was not too hard to overcome. (Resolved)
This project is a fun game where the user had to guess the song by guessing the lyrics, hangman style, with whole words instead of letters.
The script loads a song randomly and displays blank spaces for the lyrics on the screen. The user then enters guesses and the script checks for matches, keeping track of which words have already been suggested by the user. The score depends on the total number of guesses, the time, and whether the user chooses the hard or easy mode.
- Challenge: The lyrics must be hidden from the user.
- Solution: Initally the lyrics were “whited out”, but some users simply highlighted the lyrics to cheat. To prevent this the lyrics were replaced with underlined monospaced blank characters. (Resolved)
- Challenge: The users should be able to collect achievements, to encourage subsequent visits.
- Solution: I don’t usually pester my users to come back a second time, but with this game it seemed natural to do so. User’s gain achievements for various actiosn which are then stored via AJAX to the MySQL backend, building on previous knowledge of these methods. The achievements are then highlighted by changing the CSS of HTML elements. The user id is store in a cookie, and can be recovered by copying and pasting a uri. (Resolved)
- Challenge: The users interface should be as intuitive as possible.
- Solution: As usual the user interface is a significant stumbling block, and what is obvious to the designer si not obvious to the user. After some iterating with friends the user interface was adapted based on their feedback, and now the game starts with the correct element on focus so that the user can start guessing immediately. (Resolved)
At CERN we used a meeting orgnisation system called indico. Each meeting had a unique ID that was used to identify the resourcs associated with it. In many instances there were times when a person had to access a meeting page when they only knew the unique id, and not the full uri. I made this tool to obtain the full uri, given only the meeting id. Since this project shortens the uri for indico it is called “\(i\)”, which leads to all kinds of puns.
The user can interact with \(i\) in two different ways. They can enter the uri of a meeting page, a meeting category page, or a meeting resource, and it will return the shortened uri. They can also enter a shortened uri to be redirected to the full uri.
When the user enters a full uri it get parsed and strings are replaced to get a short uri. They then have the option to copy the short uri with the use of ZeroClipboard.
When they user enters a short uri the HTTP request is captured using rewrite rules in
web.config. They are then parsed and strings replaced to give the full uri.
The domain names are matched against known domain names to make the uris even shorter. This limits the versatility of the tool, but to include custom domain names would result in strings which were almost as long and difficult to remember as the original long uris. users can download and extend \(i\) to include any domains they want, and instructions to do with are given in the dev page.
- Challenge: The user should be able to copy the short uri with a single click.
- Solution: In order to use the tool, the user must interact using HTTP requests. This ensures that the user can always use the tool even if they disable flash and Javascrpt. (Resolved)
- Challenge: This tool should be extendable to suit different hosts and domain names.
- Solution: Users are encouraged to assist with the development of \(i\), and with the GitHub repository they can be download and develop their own copy. (Resolved)
The user clicks to roll the dice, with the interactions being detected by event listeners. As the user fills in the scores the corresponding boxes are removed via the DOM. Users can submit scores via AJAX which are then stored in a MySQL table.
- Challenge: This page requires dynamic HTML content to allow the buttons to be removed as the user clicks them, and added as the game is reset.
- Solution: This is simply achieved using the HTML DOM. (Resolved)