The end of a project 

Welcome back! This post will mark the conclusion of the Shoot ’em up project for team Gnoll. It was also the first real project I led using the Scrum framework. We managed to create a game that both looked great and had very few bugs. I am proud of my team  and their hard work. This post will look at the game and the lessons that I have learned from being a part of creating it.

The game – Behemoth

We chose the game concept “Behemoth”. What makes Behemoth unique is the fact that you can not move your character inside the game. Instead, you have a shield that you use to deflect enemies and projectiles.

The design

Our interpretation of the concept did not deviate much from the concept document. We changed the setting and narrative but kept most of the core mechanics. Examples of these mechanics are aiming a cannon, controlling a shield, shooting missiles that are manually detonated and a reload system for the missiles.

We decided to modify the reload system sligthly. To make it more intuitive, we decided to only have the players press 1 button instead of 3 (as the concept document described the process to be like). We also removed the manual recharge of the shield and made it automatic. This was a decision based on the fact that there were too many things to control. While we wanted it to feel like the players needed 3 arms to play the game, having them feel like they needed 5 made for a very unenjoyable experience.

We also kept all 3 enemies described in the concept document, since we found them all to be interesting, and feasible to make within the time frame of 10 weeks. The enemies were a kamikaze enemy (that flew in packs of 6 towards the player), a “spawner”, that spawned kamikazes, and a “shooter”, that fired projectiles at the player.

The art

The art turned out great. My art director Felix Rahm really put himself out of his comfort zone with this project. He did all the art himself, except for the intro sequence and the UI. Despite his lack of experience with animations and drawing machines and robots, he really did an amazing job.

For our final build we had art assets for the Behemoth, a fully animated cannon, 3 enemies with animations, a scrolling background, a missile, and several UI elements. We also had some nice cosmetic animations for the enemies that made the game much more enjoyable from a visual standpoint.

The Behemoth

The kamikaze enemy (extremely detailed but funnily enough ended up being just a couple of pixels in-game.)

Screenshot of the game

Music & Code

Making the sound effects and music was my responsibility, and something I had no prior experience of making. Still,  I felt that it was important that everything we had in the game was created by us, even if that would mean that the quality would be slightly lower. All I did in terms of music  and sound effects was learned during this time period of 10 weeks.

I wanted the soundtrack to have a distinct melody that built excitement in the players while also being feasible to make for an unexperienced person. The end result is one note that loops through an arpeggiator with many different effects.  Despite being just one note, nobody noticed it and most people enjoyed it, which I found very amusing.

For sound effects most of the sounds originated from a drum machine that was later on distorted with software such as Ohmicide. Since the sound effects were very rough and distorted, they really fit the aesthetics of our game.

Code-wise the game had very few bugs. There were certain issues with hitboxes and certain enemies not providing the correct feedback (for example not flashing red when getting hit), but overall the game was intuitive and had a good flow.

Lessons learned

I have learned a ton throughout the project and I have kept a list of things that I will incorporate or think about for future projects. These include things like “Have a rough gameplay screen sketch drawn early in the project”. Visual communication is very important and that was made extra clear throughout the course of the project. We thought we had reached an understanding for how the game should look like, but it turned out to be the case that we all had a different vision of it. To prevent this,  I now always try to work in rooms that have whiteboards and bring pen and paper with me.

I also want to create different kinds of contracts at the start of the project. Group contracts, Project initiation documents, etc. These would have helped tremendously for me to deal with tough situations. It is easy for things to get personal, but if you have an objective source that you can refer to, that was created as a group, you can remove the feelings from the argument. This makes it easier for all parties.

I also want to make sure that all members of the team follow and place value in the Scrum philosophy and understand why we do things in a certain way. I really learned my lesson by bending the rules of the framework to fit the wants of the group. Temporarily removing the daily scrum was probably my biggest mistake. It caused us a lot of miscommunication in the last few weeks of the project. I definitely wont repeat this mistake again.

Finally, I will make sure that future games are tested in an iterative manner. Whenever a new increment is created it is important to test it and make sure things are working as intended. Having people from outside of the project help is something I will try to do more often. We kind of zoned in on our game and thought it was balanced and fun, but to many outsiders of the project, the game was extremely difficult. So testing and hearing people outside of the projects opinions is super important. It is these people who are potential customers for future “real projects”.

So yeah, thank you to my team, you worked super hard to finish the game. Also thank you to all the people who followed my blog or just passed by and read this post. I thoroughly enjoyed all the feedback I got.

All the best,

Michael Degirmen

About Michael Degirmen

2017 Project Management

View all posts by Michael Degirmen →