So we had an 8 bit party
I work for a marketing firm, which, for those of you who haven’t had such a pleasure, means that weird stuff happens all the time. One of those things is a sudden all-hands on deck throwing of an 8-bit themed happy hour for all the other local marketing agencies. With a free day to code what we wanted, I and another developer (Ben Loos) started cracking.
Some time ago I had built in under 48 hours a green screen gif booth in Chrome. It would take a series of shots of your group in front of a green screen, drop in a cool background and overlay, and give you a gif to share on Facebook or Twitter. People loved it and we used it at a few events. We were debating bringing that out again for the party but decided to up our game by putting people IN a game.
That’s right — we were going to build a kiosk that would put you into Mario Bros (we called it Super Fusion Bros), and then let the user go home and play it whenever they wanted.
We found an open sourced randomly generated infinite Mario Bros clone written in javascript. We modified the game sprites, putting in beer instead of mushrooms and Fusion Marketing branded fire flowers.
The Tech
To prevent having to reinstall node, imagemagick, and every single dependency onto every computer we settled to use Vagrant. Vagrant isn’t typically used to power production apps but since this is used locally on a kiosk we figured there wouldn’t be any issue. We defined a VagrantFile to grab the Hashicorp provided default Ubuntu 64-bit Precise Pangolin image, install nodejs, imagemagick, and any other pre-requisites the kiosk would need. While this means that we did have to install Vagrant onto the Windows 8 kiosk (Win 8 all-in-ones make great kiosks, btw), it would handle installing and running all of our other code. Likewise, we knew with certainty how the code would react on our dev and final kiosk machines. I think we’ll be using Vagrant on kiosks moving forward to provide a consisten platform to build on.
We built a local node server that would serve up a small AngularJS app that handled the webcam, individual screen shots, and organization/user interface. Each shot was passed to the local node server where it performed a number of imagemagick conversions — pulling out the green screen, resizing the image, cropping out the user, shrinking them to mini mario, etc.
Once the user took each pose (Mario needed something close to 16–18 unique poses, but we cheated and had the users only record 5) the local node server would bundle all the images together into a spritesheets for large and small Mario, and tint the large Mario sheet red for fire-powered Mario. Then it would upload to a remote node server hosted on Heroku.
The remote node server performed two functions. The first was actually hosting and serving up superfusionbros.com. The next was accepting those sprite sheet uploads and pushing them right to S3.
No database was needed — as soon as you enter a code on the superfusionbros.com site, we check in javascript if a spritesheet exists with that code on S3. If so, we bring you to the game and S3 sends out the hosted user-created assets. Otherwise we warn the user.
There’s plenty I would change or improve about the process, but not bad for a single day’s work.
Working at a marketing firm creates some truly unique experiences for developers.
Try it out — use code 85wsm to play as Rosie, our company’s current LaunchCoder!
