At work, we often (once every 2-3 months) hold “GameJams”. Generally these involve a group from work all going to a pub, breaking up into teams of 2 – 4 and spending some time after work hours for a couple of weeks coming up with and creating a small game which we present to the other teams on an agreed upon date. I don’t always participate, mainly because of extra curriculars after work, but the game jams always have a theme, and the most recent was “HTML5 Games”.
I’ve posted before about my desire to work with StarlingJS, and was pretty amped to do just that for this particular GameJam. I always want to use these events more as an opportunity to learn, rather than build a game.
With the Ouya having recently been sent out to its early backers, we had one in the office and have had a lot of fun playing the game “Hidden In Plain Sight”. The game is a collection of five mini games that are highly addictive and very fun. I had it in my mind that my team would be able to easily reproduce one of the game mechanics, the “Death Race” game, as I believed it would be the easiest, and therefore best, to build as far as a learning experience with Starling.
The Death Race game mechanic is very simple. X number of players start on the left of the screen when the game begins. The Ouya version of the game supports up to 4 human players, which leaves approximately 16 AI players. The human players don’t know who they are at the start of the game and can press a “walk” or “run” button on their controller to move their character to the finish line on the right. The AI characters walk at random intervals for random lengths of time, on and off, making their way across the screen. The first thing to do is to figure out which character you are on the screen without making it too obvious to the other players.
The reason you don’t want to just run across the screen to the finish line is because each of the other human players have a crosshair on their screen that they control with their joystick. The crosshair can be placed over anyone in the race and then can be “shot” by pressing the appropriate button. If you are shot, you are out of the race and lose your crosshair if you haven’t shot yet. Each human player only gets a single shot to try to take out an opponent.
The mechanic is very simple, and as I mentioned, I thought it would be a great project to learn StarlingJS. I figured that moving movieclips from left to right would be simple enough, and we could use the mouse to replicate the crosshair. The big “win” would be that we could set up a simple NodeJS server with Socket.IO to allow up to 20 people to play at once.
My team liked the idea, but wanted to make some changes. We decided on the following changes for the game:
- We’d have the game character be Zombies, and rather than moving them left to right, we would bring them from the back of the screen to the front, scaling upwards as if the zombies were coming for those playing.
- Rather than using a mouse and having each player connect from their machines, we would project the game screen in the presentation area, and each player would use their mobile device as a controller, so all players would be facing the same screen at the same time.
- We’d add Facebook connectivity and display the winner to everyone on the main screen and their device, and when a player’s zombie was “killed”, we’d show their killers profile picture on their phone, as if to mock them.
I learned immediately that Starling hasn’t yet been released for public use. Which was the first snag, as I had wanted to do the GameJam specifically to learn Starling. No matter, the idea was mine and I didn’t want to let the team down. I stumbled across PixiJS, which, while still in development, looked very interesting and had some fantastic demos that performed admirably on every device I tested it on. I made the executive decision to build the main game view using Pixi.
I set up a simple Express instance, setup a Facebook Passport strategy and added Socket.IO. I had some issues getting the player Facebook details shared with the sockets, but I did manage to get that figured out after some Googling and setting up a RedisStore in Express.
Unfortunately, due to issues with multitouch, performance, time and other commitments, we had some issues with the controller. We ended up going with a much simpler 4-button interface that players would be presented with when they logged in, they could move their crosshair over a zombie to the left or right of where their crosshair was currently positioned. They also had a “walk” and “shoot” button. We removed the “run” as it was too much of a giveaway of which players were human and not AI, and because of time constraints.
Luckily, one of our team members is a fantastic artist and designed some great art for the game. A four-frame zombie walk cycle, a single “death” frame that faded out when a zombie was killed, a bunch of crosshairs moving across the screen, a large background image and 250 drops of randomly falling rain and PixiJS was able to maintain 60FPS the entire time.
All in all I was extremely pleased with my experience building a socket server for a game, as well as working on the front end with Pixi. I’d love to continue building some games with Pixi, as it continues to evolve as a language. I would also love to share the source code, but, as most “rushed” code is, it is still buggy, and we’re actually hoping to clean it up a bit and possibly use it for some upcoming events at the office. If this doesn’t happen, I’ll most definitely share the source repo on GitHub.
Here are some images from the game:
For fun, I’ve attached the following, a Pixi MovieClip of the zombie walk cycle, just because it kind of looks like the zombie is dancing…