# 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.

# 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.

### 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 design went through a few iterations before settling on the current choice:

# IIHE Nobel Prize website

When I started working for the ULB at the IIHE I wanted to get involved with some outreach activities. One of my first activities was the creation of a website celebrating the Nobel Prize in Phsics 2013, which was awarded to François Englert and Peter Higgs for the prediction of the scalar (Higgs) boson. This involved collaborating and development using HTML, CSS, and PHP, with multiple language support, search engine optimisation, YouTube integration, and video recording sessions. The results was a webpage where the users of the lab got to show off what they did to the wider world and to show how the rich physics program at the lab was relevant to the prize. It was a fun project to work on, it was my own creation and was excellent practice for working on similar projects in the future.

Live page

# 91 map

I played the game 91 and wanted to create a map of the world. What started out as a simple map to help keep track of the regions soon turned into a larger project which resulted in an A0 sized poster being produced. The creator of the game got in touch and at the time of writing the first poster has been printed and more will follow. The creator is going to publish and sell these posters online.

### Overview

The game 91 is a tile based canvas game which is written entirely in Javascript (served up by PHP via AJAX requests). The game itself has a “fog” which means that only regions in a line of sight are visible. Given the way the game is organised means that in principle it should be easy to create a map. I adapted the code to make maps of each region, and then created a patchwork of all these small maps to create a larger map.

### Challenges

Challenge: The code had to be reverse engineered to obtain all the maps.
Solution: One of the most fun parts of this project was reverse engineering how the AJAX requests were handled and how the maps were parsed. Fortunately it was relatively straightforward to do. (Resolved.)
Challenge: Small maps had to be combined with different drawing styles.
Solution: To make the large map I had to combined many smaller maps. There’s no “cheap” way to do this, so I created an object that contained the smaller maps in a larger two dimensional array where each cell has its own drawing style flag, allowing non-trivial overlap of different drawing styles. (Resolved.)
Challenge: A poster of very large dimensions needed to be created.
Solution: There’s no easy way to manage an image of the size needed to make a large poster. I have made large posters before (for example, in the Marble Hornets project) so I was prepared for many of the problems. The sides of the map had to have relative sizes of $$\sqrt{2}$$, which fortunately was relatively easy (especially when compared to the Citadel project. In the end I opted to have a large .png file at $$\sim 500 ~\mathrm{dpi}$$ giving very fine print quality. The resulting file is just under 20 MB in size, which is rather impressive given its physical size. (Resolved.)

### Sample outputs

The final version of the poster, as approved by the game’s creator, can be seen here: Poster version 2.