Prince Protect Box Art


Princesses Erin and Daphne are in trouble! An army of evil ninjas have come to steal their stash of boyfriends! Help them fend the endless army off for great justice!

Prince Protect is a “boyfriend-defense” arcade game Daniel made during the summer of 2012. One to two players attempt to keep a set of princes safe from waves of ninjas as long as they can. The initial mechanic is basically a beat-em-up, but players can also strategically place colored barriers around the play area. If a tetromino (or larger) of barriers are placed together, they’ll transform into some item that the player(s) can use to their advantage. The concepts for the gameplay mechanics were borrowed from The Legend of Zelda and Puyo Puyo.

You can also save high scores with names that are rude words.


pp_screen2pp_screen1 pp_screen3


You can download a ZIP file of the game below. Right now it’s only for Windows. Just extract and run.

(download here)

Check it out on GitHub here. It’s open source, and the assets can be re-used non-commercial.


The duration of the project happened over the summer while I was working a co-op at Research in Motion (now known as Blackberry). I’d spend the day working in C/C++, then spend my time developing in C/C++ for the evenings! Talk about madness, right? Regardless, I didn’t find it discouraging or tiring to the point of where I didn’t want to go on. Good work/life balance was key. Being a carefree twentysomething with few responsibilities for the summer really helped with that!

The game was coded in C and SDL almost unintentionally. I was taking a train-ride between cities to meet a friend for Canada’s May long weekend. I started prototyping a silly little blue square that clicked around a board and kept building off of it. Initially work on it was whimsical and organic. As the game began to take form and the summer was waning, I started putting hard requirements and features to get everything done that I wanted. Making a to-do list is key for finishing projects. It lets you know when parts of your game are done and helps you decide when you need to cut things to meet a deadline.

This was the first time I really attempted some degree of software engineering in a personal project, especially in a language like C. Working at Blackberry alongside professionals who were good at this kind of stuff really pushed me to organize my code into modules from the start. It’s not 100% if you look on GitHub, but having the game all in one file or organized like TREPANG would have been incredibly difficult. Abstracting the keyboard control code and audio processing from the game logic really made a difference. The methods can sometimes be long, and a little redundant, but the overall complexity of the running code is kept decent by applying this rule:

  • Always program what to do, never how you’re going to do it.

I tried to get a friend to make the sprites at one time, but in the end I produced all the assets myself. I’m not much of a visual artist (sadly!), so the sprites looked a little crappy. Music was done with Autotracker-C and custom instruments. Sound effects were quickly hacked together with SFXR. These audio creation tools have to be some of the most useful things to an aspiring game developer who cannot make music to save his or her life.

Derek Yu calls his company Mossmouth, because his favorite part of the game is putting the “moss” on. I think what he means is the polish and tweaks that one adds towards the end of the development cycle. Adding detail for Prince Protect was a lot of fun too and had a lot of impact towards the feel of the game. Specs of blood flying around, or black curtain wipes on opening/closing the game made it feel more complete. It’s funny telling yourself while working “wait, this actually kind of looks like a damn video game!”

I’m not driven to work on Prince Protect further, as it was mostly a product of my lifestyle while on co-op. If I found myself developing it for another month, I’d do some surgery to the code (and title screen UI!) and make a decent tutorial. The player doesn’t really understand what to do when they start a session for the first time, nor what keys to press. My time budget and goals had me sacrifice accessibility to make the game feel “complete” in my eyes.

Regardless, finishing a project and being happy (enough!) with the end really boosted my professional confidence. I showed it off at a table for the gamedev club at school in the fall with some gamepads. A few people took the time to play it and some even had fun! Seeing them smile or giggle at the silly action still feels satisfying today.