Almost concurrently to finalising the concept behind the crowd-game, we had a couple of other challenges to surmount.
Most of them had to do with the kind of technologies that we’d be using to make the game happen, obviously one area we want to completely wanted to leave to the specialists was the projection part. There was also the matter of our choice of server side technologies and front end technologies and visual development too. Getting it all coordinated and made in such an insanely short amount of time, required a good deal of minute by minute project management.
Specialist company Blitz communications were enlisted as the project partners to provide the game with over 120,000 Lumens of projecting power ready to blast hot photons onto the face of a chosen building. (it ended up being 3x projectors for each side the game is played on, that’s about 40 times as much power as a home cinema projector).
Building Choice / Game development
As the building choice wasn’t completely final till very late in the project (pending permissions, discussions with the UK Civil Aviation Authority, Councils and lawyers of a multinational oil company) we had to keep certain things very flexible, and completely adaptable to circumstance, for example, the choice of the game being Battleships, was in jeopardy as we could only potentially use one side of a building.
Regardless of the game mechanics and everything else that was going on at the early stage of the project, we developed a neat circuit like visual design language, sympathetic to the overall theme of the show. Conceptually speaking, we were thinking, the players would be uncovering the circuitry underlying the facade of the building, by destroying it.
From a visual design specification standpoint we made it so it could wrap around the features of pretty much any building with standard architectural features such as windows, window frames, dividing spaces, decorative columns. While bearing bearing in mind the limited space available to project onto, we wanted to stay as far away from the usual tropes of projection mapping which include faux shadows, excessive animation, lighting effects and playing with negative space. Our objective was to make it distinctly befitting of the brief and more importantly, legible at distance.
Needless to say, even though we had a projector to experiment with, we kept tweaking the visuals and in particular the animation effects till the final test day. This flexibility and agility is ultimately required on projects like this.
Creating the mobile game
The requirement for the game was that a crowd of people could connect to play the game using their phones, with minimal instruction and setting up.
Given the time constraints, to bypass the App store and Google Play was imperative, we wanted to be able to test and tweak the client side experience till the last minute and in response to the requirements of the project. So we created a very usable HTML5 browser based interface for a game that could be played on any smartphone. Because the game was team based, we had ensure that every player could view what their team-mates were doing on their own phone, in realtime. To achieve this we used the brilliant Node.js to create a socket server, which each player connected to through their instance of the game. This node server is essentially what facilitated the realtime interaction.
Every client connection to the game fed directly to a server we had set up, where a database collected all the game actions. The game logic itself was all done on the server. The results of each players actions in the game were in turn fed directly to two computers running an instance of Unity for each side of the building.
To say unity is built for fast prototyping is an absolute understatement, in the right hands, it’s an absolute force to be reckoned with. We’d actually previously used it for a brief put to us to create a series of games for a well known national brand in record time (sadly under NDA, but they’re delicious!), and some of our research and development work is built upon pushing the Unity platform to do unexpected things.
One of the things we could do with Unity was simulate the physics of crumbling, and the special effects such as sparks and explosions. Unity essentially took the game logic from the server, and displayed the corresponding visuals, the code was abstracted enough to work on each side of the building with a few minor variables being changed.
Petite url: http://rith.co.uk/blog/mkoec