This post is about the recent experience I gained in creating a game for a public event which included an incredibly large projected display of the game itself. My insight is about the game development of course, the event production, staging, organizing, funding, marketing and everything else was a job undertaken by many people from numerous different companies.
The Place
Vanderbilt Hall, Grand Central Terminal (GCT), New York City.
The Occasion
The unveiling and first public display of (a model of) the Titanoboa, a 40 foot long, gigantic prehistoric Snake, the largest of it’s kind ever discovered.
The Purpose
To unveil the giant snake model, exhibit it in for 2 days and to promote a TV show created by the Smithsonian Channel about the discovery of the Titanoboa fossil.
The Idea
After the initial unveiling, press and news interviews, photos and speeches, the public were to be invited to play a specially developed version of the classic Snake, on a huge projected display (in the order of 25ft by 14ft). Over the two days, the highest scoring player for each day would win a cash prize.
The Game
We (FinBlade) had been contracted to create the Titanoboa: Monster Snake game for Web and Facebook, iOS Universal and Android, and then the Grand Central Terminal event. The game-play was closely based on the classic game Snake, people most likely being familiar with the Nokia mobile phone version. We created the Web/Facebook game using Flash technologies (coded with AS3 in FlashDevelop and using the Flixel engine), and the iOS and Android versions using Cocos2d and Cocos2d-x respectively.
We coded a modern high quality game with high end 2D graphics, a very detailed main snake animation, moving water and environment (foliage) effects, animated food items, online high score tables, smooth frame rate and high quality audio. We also built extra Web and Facebook features (using web technologies) for Smithsonian Networks and their affiliate partners, such as DIRECTV. Including custom game branding and other elements, an online sweepstakes with data entry form, integration with the TV show trailer video, send-to-a-friend emails, Facebook sharing and ‘like gate’ features.
The GCT Event
So, that’s all the background out of the way. How did we take things from there to the Grand Central Terminal event?
Platform
We re-used the AS3 Flash game from the web, and created a high resolution build of the game running at 1920×1080. Since we routinely create games at multiple resolutions for mobile and web, this aspect of the game was pretty straightforward. The various game art assets (including the snake animation) were created in 3DS Max and we rendered the graphics to 2D sprite sheets. Doing this, the artists work at high resolution and output whatever scale sprites and assets are required. They actually worked at above the resolution needed for the HD version of the game. The snake sprite frames were 80×80 pixel cells and the artists rendered from Max at 160×160 before scaling down.
Performance
The web game resolution was 720×570, not too high, and was designed to run on normal machines in web browsers. The frame rate struggled a bit from an optimal 30 FPS on older P4 machines and low end netbook type devices, but we think it was worth it for the graphical look of the game. However, running a full HD resolution build did need a high end PC, with a quality graphics card being the most important element. The game required a Core i7 3GHz and a 1GB modern graphics card. We ran it in the Flash Player 11 Standalone, both as an SWF and a ‘projected’ .exe and 30FPS was no problem. With such high resolution graphics, memory usage was high, at between 200-300Mb RAM usage varying by game state. The final binary SWF was 30Mb in size, 3 times the size of the 10Mb Web and Facebook SWF files, but that didn’t really matter, and neither did the RAM usage since it was going to be run on a dedicated machine.
This video was taken with Fraps, on my development PC which is fairly beefy, and it struggled to get a smooth frame rate. Without Fraps recording though, the game runs nicely at 30 fps.
Game Logic Changes
For a public event, the game logic needed to be tailored very specifically. People playing the game were going to be briefed or guided by a representative before they played, so we removed the main menu/front end of the game entirely. The experience was much more ‘arcade’ like, with the game running on a ‘attract loop’ showing the high score table, then a simulated game-play screen, then looping back. All the time, the ‘play now’ text pulsing at the bottom of the screen, and a large banner stating the real cash prize to entice people to play.
Pressing any button on the joystick started the game, with the customary 3-2-1-go countdown and brief instruction text. After that, the game play was the same as the web/mobile builds, with one exception. On the web/mobile builds, we made the game-play area wrap around. If the snake moved off the left of the screen, it’s head appeared on the right. The disadvantage of this for a public game is that anyone could walk away and leave the snake cycling around and never ending the game. Also, we wanted to keep the play sessions short to prevent people from staying on too long. This did require a graphic update to the play area to add a ‘shoreline’ around the edge to make it more obvious that the snake would crash.
Auto Skip Screens
The final piece of game-play update was in relation to timing out and automatically skipping screens. As well as the cycling attract mode screens, after a player had crashed in a game, they are taken to a ‘game over’ screen giving them details of their play time, how long their snake grew and their final score. We added a 30 second timeout to this screen in case anyone left the kiosk/podium at that point. After the game over screen, the players entered their initials using the simple up/down/left/right movements on the joystick. This screen also had a timeout of 30 seconds in case anyone wandered away.
High Score Server
We implemented a leaderboard function for all the games using some PHP and a MySQL database, running on an Amazon EC2 instance. The same server also collected the data for the online sweepstakes, for which we created an HTML form with some Javascript functions to make the data entry user friendly. For the GCT event, I simply re-used the leaderboard code without change, and ran XAMPP (for Apache and MySQL) on a ‘back end’ PC. Managing the leaderboard (deleting entries for example) was simply done with phpmyadmin.
Settings Screen
Since the exact network setup for the machines wasn’t known to me beforehand, I needed to make the server IP address (as used by the game to connect to the server) dynamic. There were also several other settings that it made sense to make tunable without having to restart the game, so I implemented a settings screen where such things could be changed. The screen was accessed by a keystroke, so the keyboard needed to be attached. I did need to access this screen on a couple of occasions (see below) during the days, and we switched the big projected display to the ‘sizzle reel’ during this short time. In hindsight, it would have been better to implement a remote interface to the game (using an embedded web server for example) that would have allowed me to make these changes without needing access to the PC at all, or needing the display switched over.
High Score Reset
One task that I had accounted for was adjusting the leaderboard during the game-play sessions, and this could be done easily on the ‘back end’ server PC using phpmyadmin. However, removing the top score from the leaderboard did not automatically reset the current ‘high score’ value in the game, which was maintained locally in the game code. This was a legacy of the code, and something I could have changed so that it was automatically synced to the leaderboard top score, but in the end I did not do this. I implemented an easier to test manual reset of the local high score using the settings screen. This worked, but did mean that when I needed to remove a high score from the leaderboard (due to the player being ineligible to win the prize), we had to switch the projected display off the game for a few moments, so that the settings screen was not projected for all to see.
Soak Testing
This is utterly essential, and I was very happy I’d taken the time to implement a proper soak test. The event was planned for 2 days, with the game being played, in public, on a big screen for 10-11 hours straight. It needed to be bullet proof, no memory leaks, no slowdown, no crashes. I’m only human after all though, and during the event, very early on the first day, for some reason, there was a null object reference in the code that flashed up an exception dialog. The operator was very quick on this though, and cancelled it with the mouse. The game carried on without incident (I suspect it was in a short lived network thread) thanks to the Flash runtime shrugging such things off. Had I coded the game in C++, it probably would have bombed straight out! Thankfully, it never happened again, the game ran for 2 days without incident.
For the attract mode, I had already implemented some A* path-finding code so the snake could hunt down the food, automatically, whilst avoiding itself. This wasn’t a perfect snake AI, since it would still go down dead ends, but the attract mode only needed 30 seconds of play. Using this, and some random numbers to drive the name/initial entry, I set the game on soak test playing automatically. All the way through, starting the game, playing till snake crash, then entering scores into the high score table and looping back to the attract mode, ad infinitum.
Slowdown
After only a couple of hours of soak testing, the frame rate of the game started to slow down, badly. It turned out to be a tiny network connection ‘spinner’ I’d implemented as a constantly looping timer task. This thing was only flashed on the screen for a fraction of a second, but when removed, I wasn’t cancelling the loop timer, so each one was leaving an invisible ‘zombie’ task. After a couple of hundred times through the game-play loop, there were 100′s of them eating CPU time!
Once these little zombie timers were sorted, the soak test ran for several days without incident. A perfectly regular memory trace, and rock solid frame rate, even after days of looping. I’ve a lot to thank the Flash runtime for there, but as a quick search will tell you, Flash garbage collection doesn’t do all your work for you! Like I said, apart from one minor incident at the start of the first day, the game didn’t hiccup for 2 busy days of play, the soak testing proved it’s worth.
Never Rely on Wi-Fi in a Busy Public Space
As a great incentive to play the game, on each day $1000 prize money for the top score was up for grabs. Obviously this meant keeping high score data, but the game was already setup to do that. The other element was recording the details of the players who managed to get a high score so they could be contacted if they were the winners of the prize. We decided to re-use the already written sweepstakes form for data entry, linking it to the high score table. The idea was to use an iPad to show the form and get high scoring players to enter their data.
In theory this was a good solution. iPads were already going to be used by ‘brand ambassadors’ to show the iOS game to the public, so using one for the data entry made sense. However, for some reason or other, the Wi-Fi did not prove reliable. We had the wireless router (a Linksys WRT54G) pretty close to the gaming PC and the operator with the iPad (only a couple of feet away in fact), but the iPad just constantly lost the network, or refused to connect to the server PC. I had constructed a simple web page that constantly refreshed the top ten leaderboard scores as hyperlinks that linked to the data entry form with the high score already filled in. While it worked, this solution was great, simple and integrated with the game, but it was completely let down by the unreliable Wi-Fi. Even though the Wi-Fi was a private, secure network, I think it was simply not reliable in the public space. There were at least a dozen other networks in the same area (in fact, I wrote a lot of this post connected to the free Apple Store Wi-Fi) and I think the lesson is not to rely on Wi-Fi for public events. In our case, pen and paper forms stood in and were quick and 100% reliable.
Know Your Controller
This is the main lesson I learned from the event. We left the choice of controller up to the production company, who were supplying and installing all the kit. They went for a simple Atari style digital stick, which was a perfect fit for the game. It wasn’t overwhelming for people walking up to the game, and had a cool red LED glow (it was USB powered), also no array of confusing buttons, just one. We used JoyToKey to drive the Flash game since Flash doesn’t have native game controller support, and this was actually a very good solution. We had tested the game using a XBox 360 controller d-pad, and it played fine. When testing with that, we should have realized that it highlighted the need for a quality controller.
The particular model of Atari type joystick used didn’t have micro switched internals and it’s directional response wasn’t quite as good as I’d have liked. It had a bit of kickback if not held carefully, and missed directions were frustrating to less experienced players. It certainly wasn’t all bad though, the sticks turned out to be robust enough for heavy use, were comfortable to hold, and after a minor tweak to smooth the direction response jitters, things went pretty well. Some pretty good high scores were had at the end of the day!
In hindsight, we were the game developers and we should have sorted the controller out ourselves and I should have taken them with me, or specified to the production company exactly what to get. I was expecting a more ‘arcade stick’ like device and it hadn’t even occurred to me there were other options. I ended up making a last minute tweak to the game input logic to smooth out the direction response, which did help a lot, but could have been avoided, we should have picked up such issues much earlier.
Finally…
Wow, if you’ve got this far, thanks very much for reading. I can say honestly say that being involved in the Titanoboa Grand Central Terminal event was an amazing experience. As a game developer, there’s nothing more awesome than seeing people from all walks of life stepping up to play something you’ve created. As I said at the beginning though, lots of people were involved, my part was quite small really. We at FinBlade were contracted by Civic Entertainment Group who oversaw everything, there was the Smithsonian Channel for the content and Production Glue designed and executed on the two days, from setup to teardown, at the event itself. I’m sure there were numerous other parties involved too, these kind of events need a lot of expertise. Someone must have made the massive cloth scrim, put together the foliage, the people behind all the marketing, the list goes on…
No comments yet.