Created: Late November/early December of 2018.

Role: Ideation and project management.

Princess Tower was a prototype for a game I made with four other people: Angela Casidsid, Javad Goudarzi, Andrew McDonald, and Steven Prichard. We created the game for a project called the Hackathon. Our goal was to “hack” together a functioning prototype out of a collection of apps that contained features such as gravity, text entry, random selection, and other common mechanics. The projects we worked on were taken from ideas we provided before the Hackathon. We would present what we had after two weeks of work, which would include a prototype of the app with some working code, a mock-up, and a five-minute presentation showing off what we had made.

I came up with the concept and game design, managed the project, and made the presentation. Angela and Steven did the visuals, and Andrew and Javad did the coding.

Ideation

The central idea of Princess Tower was a subversion of the trope of the helpless kidnapped princess. In this game, a princess is kidnapped, but she is the protagonist and architect of her own escape. The original story called for the princess to be kidnapped by a rival kingdom, but partway through development, I thought it would be more interesting if she was put in the tower by the king as a test for would-be princes. This would put a spin on the idea of the kidnapped princess as a reward, as she is literally being offered up as a reward against her choosing. It would show the worrying implications of the trope by presenting a literal application of it in-universe, and the player, as the princess, would fight against it.

The basic gameplay loop would be as follows: guards would patrol the ground below the tower. If a player were to tap one of the three windows at the top of the tower, a book would fall out of that window. If a book collided with a guard, the guard would disappear. If the player defeated a certain amount of guards, they would move on to the next level. However, if a certain amount of guards were on-screen at the same time, the game would end. I created the following before the two week period as a wireframe for the game’s pitch:

 

                    

           

These wireframes were refined by the design team into the following:

The simple design of the game was to allow us to have a functioning prototype by the deadline, but also to enable us to introduce new factors such as different enemy behaviors, new weapons, or other environments if we got the basics built and had time to spare.

Management

During the two-week period, I delegated tasks and organized our materials. When I wasn’t doing either of those things, I helped out with whatever odds and ends people needed a hand with.

To help with task assignment, I created a Kanban-style job board where tasks were grouped based on whether they still needed to be done, were in-progress, or were finished. When someone started working on a task, they would take it and put it in the “in-progress” section under their name until they were done with it, then move it to the “finished” section.

Unfortunately, this kind of fell apart. No one used it after the first couple of days, and it became more of a hassle than an asset. I think part of the reason was because I didn’t do a thorough enough job identifying the requirements of our project in the beginning. During the project, someone would start working on something that was necessary, but that I hadn’t put on the board. I added new things to the board, but this resulted in it being cluttered and confusing. We eventually abandoned the idea, and we were able to organize our tasks fine without it.

Reflection

Ultimately, I think we did okay in the two-week time period. I’m very happy with the game’s visuals, and the programmers did a great job hacking the gravity system and starting on enemy AI and collisions. In our prototype, the enemies tend to move erratically and float off of the ground and their hitboxes don’t seem to match up with their visuals, but I think we got a good start on a project that could go places if we continued with it.

The only things I know need to improve are my managerial skills. I was completely lost when it came to the coding that the developers had to do, and as such, I was unable to provide guidance or lend a hand when they ran into trouble. If I was more involved from the start, I could have been a better asset to the members of my team and been more effective in delegating work. In addition, I think that if I had put more thought into how to split up the programming tasks, we would have had an easier time consolidating all of our code, and we possibly could have made a more finished prototype. I just asked Andrew to handle the enemy movement and Javad to handle the gravity on the books, and as a result, I think code consolidation was harder than it had to be. If I had given more thought to how we would do that, I think it may have gone more smoothly.

In the end, even though I’m not entirely happy with my part in the project, I think it was a valuable learning experience. In the future, if I’m in a leadership position, I need to be more on top of things. I need to be more involved with my team, think ahead more thoroughly, and get better at task delegation. As for the game itself, I think it has potential that we didn’t get to explore, and I would love to put more time into it at some point in the future.