top of page

Dangerous Heights

Dangerous Heights was the first school project we created at PlaygroundSquad. We were a very small group for this project, of six people, and my role was 'lead designer' (even though we only were two designers) as well as project manager. 

Dangerous Heights is a base-management survival game, where sky pirates are attacking your airship from six different directions. This can be seen on the Holographic board in the middle. 

​

To protect yourself, your ship is armed with cannons that automatically fire towards these six directions. However, the cannons are not strong enough to take down the different types of ships or combinations of ships that may attack.

​

The cannons have three different modes of firing, where one increases the damage per shot (making it good at taking down big ships), and one increases the firing rate (making it overall more useful). The player's task is to swap between the different modes on the cannons to have the optimal firing based on what ships are attacking currently.

​

Finally, the two stronger modes both cost battery power to use, from a total pool of battery. This means that player only can have a few cannons put in the different modes at the same time, then they need to turn these cannons off to be able to allocate the battery to cannons that need stronger firing.

Holographic board

Changing firing mode

During this project, we practiced scrum and had daily standups, where we every day started the day with telling each other what we were going to do that day, what we did the day before and whether we would need any help with anything. 

​

We also continuously iterated on the game idea. Since we were such a small group, it was very easy to hear the opinion of programmers, designers and artists alike, so we often had meetings where we discussed whether we wanted to add or remove something and quickly got an answer from all three disciplines what they thought.

​

When we started this project, the idea wasn't very fleshed out. The base idea was that the player should run from cannon to cannon and manually fire them whenever an enemy approached. Our plan was to work until this gameplay worked (which would be two weeks in), then start to try it and realize how to improve it over the remaining three. However, we quickly realized that our current gameplay got dull very fast.

 

Since we were such a small group, we used this to our advantage to discuss potential additions to the game to make it more enjoyable, and programmers and artists alike got to add their opinions of what was possible and what wasn't, as well as their potential ideas on what the game would be. 

​

After a lot of discussing pros and cons with different ideas, the final idea started to shape out and everyone was very on board with it. In the end, I'm very satisfied with the project, as it turned out to be a very unique game where you constantly need to keep track of where you have been and where you need to go. I'm also really happy with our workflow, where we needed to get something of the board to know what it would feel like, and then start to realize what actually was fun with the current gameplay and what wasn't, instead of deciding on an idea and then going for it without realizing potential fixes along the way. Of course, this would probably have been a lot more difficult if we would've had a bigger group with more opinions and people to keep up to speed. But just because we were only six people, I felt we really could utilize this type of workflow, and the result of it turned out really well.

Back

bottom of page