Creating Present Drop

Around the Office Design Development
Daniel Knoben

An In-Depth Look at How We Created Our Online Game

In case you missed it, we created a festive online game called Present Drop! We’ve spent the last four months researching, prototyping, refactoring, building, and testing.

It all started when Glen, our Art Director, wondered if we could design and build an online holiday game for our clients to play. The idea was a hit with several team members, and so the holiday game team was officially formed.

We’re proud of the game we’ve created, so we thought you’d like to look behind the curtain to see how we built Present Drop.

Where To Start?

We started with a simple question: What kind of game do we want to build?

After weeks of brainstorming, which was mostly sitting in a conference room and shouting out ideas like, “What if it was 8 bits?” and “It needs to have cool music!”, we narrowed it down to two concepts: A game where you drop presents or a game where you shoot zombie snowmen. In the end, we held a vote and the idea of dropping presents won.

How Do We Build It?

The next step was figuring out how to actually build the game. We researched using Unity or Phaser game engines.

Choosing a Platform & Designing Prototypes

The benefit of going with Unity was that Phil, our software architect, has extensive experience developing on the platform. However, Phaser’s framework is written in JavaScript, one of the key programming languages for modern web development. Ultimately, we chose Phaser so we could use this project as an opportunity to build our JavaScript skills and try a completely new platform.

After one day of research and work to set up Phaser, we created our first prototype complete with Microsoft Paint images (created by yours truly)!

I was ready to release it and let the whole world play, but our team said we needed “real” images. So, we started creating concept art and building out the Present Drop world.

Using the concept art image, I was able to cut it up to create different game objects and build out more pieces of the game. After a few days of work, we had a new and improved prototype (even though I was still partial to my original work).

Refining & Adding

“Surely, it was ready to release now!” I thought. But the rest of the team pointed out that our chimneys didn’t look right, we needed obstacles to make the game harder, and it was missing buttons.

Another issue we needed to address was the site architecture. All the JavaScript used to create the prototype lived in one big file. Scott, one of our Staff Developers, thought it would be a good opportunity to incorporate Typescript.

After a weekend of work, he converted the game to use node package manager and to run using Typescript. We spent the next week doing what I called “The Great Refactor of Early October.” This involved:

  • Moving game objects into their own classes that extended Phaser game objects
  • Converting the big JavaScript file into a game scene file
  • Creating Start and Game Over scene files

This was a great way for the development team to learn a new technology that we had not used much before, and it resulted in more modular and readable code.

The rest of the team was also busy creating more image assets and incorporating them into the game. Leah, one of our developers, and I researched how to animate an image, how do Phaser containers work, and what is a tileImage.

After a few more weeks of work, we had a game with a start scene, animated images, and cool new effects like snow and obstacles. Phil used his musical skills to create sound effects and background music. By now, we had a pretty good looking game!

Tracking Scores

One of the last big obstacles was figuring out how to securely keep track of everyone’s scores. After researching our options, we landed on keeping track of each game’s state on the server.

We created a small database and used to send requests to save and retrieve high scores.

This allows us to validate that high score submissions are legitimate before they get added to our leaderboard database. If a high score submission doesn’t match what we have recorded on the server, the user is presented with this unique error message:

The Final Touch

The game was definitely ready to release, but our team thought we could push ourselves even further. We needed one final challenge to make the game harder to play and more diverse.

And the drone was born.

The drone was one of the hardest obstacles to build. It needed to shoot out from the bottom of the game then follow a path to make it seem like it was hovering.

We also had to incorporate new sound effects including the final explosion and the infamous complaint, “Oh no, my new drone!”

The drone proved to be too challenging to play with using our existing random obstacles class, so we made major adjustments and cut back on the number of drones that players would have to face.

With the drones and high scores working, and a few other features and tweaks worked out in the beginning of December, the game was finally ready to release.

So here it is! It was a lot of fun to make, and it was a great educational experience for everyone who worked on the game. We hope you have fun playing it.

Play it now!