Post Mortem Shoot ‘em Up

Greetings once again!

This week I will discuss the overall result of the 10 weeks of production that went into our Shoot ‘em Up game ”Beelonging”. My role in the project was Lead Programmer.

The game was a ”Side-Scrolling” shooter in which you played as a Bee and was hindered on your way to the beehive by enemies such as Flies, Spiders, Wasps, and Dragonflies. The game included a scoring system and a power-up mechanic in the form of a formation as well as a very rudimentary AI-System for your bee-friends. It also included a parallax background that was continuously scrolling, animation, sound effects, background music and a spawner that could conditionally spawn waves depending on if you had killed the previous wave.

The list of things that I have gotten out of this project is very long, but I will try to focus on the essential parts. First off, this was the first time I have worked with other people to create a video game of any sorts which introduced a lot of new challenges. For instance, I now realize exactly how hard it is to communicate well while designing games. Especially since most of the group are doing entirely different things, have entirely different areas of expertise but still rely heavily on the work of each other. I do however think that we did decently in this aspect since we are a quite closely-knitted group and tend to be able to communicate pretty well most of the time, but there are always off-days or unforeseen circumstances which can impact the development profoundly. The part that was particularly hard for me personally was the fact that I was lead programmer for the first time ever and I think that we programmers failed in some aspect of staying on the same page, but more on that later.

What went well:

• Choosing a concept
• Working and designing as a group
• The art and sound design

I think that we chose well when we decided our game concept, it was not Umibozo which was a plus, and the game concept had a very well designed core mechanic that was somewhat easy to execute. I did, however, have a small problem with it and that was that I was worried that we would have problems with designing that AI which turned out to be very true.

Overall I would say that working with the group has been successful and I credit that mostly to the fact that we function quite well with each other, within meetings and outside of them as well. I think this is partly because we got lucky with the people in the group but mostly I think that it is because of good management of the group.

I can’t speak for the artists that much about why the art and sound design turned out well in my opinion since I do not have the expertise to define the key factors. I will just say that I feel blessed to have such talented people that I get to work with.

What could have gone better:

• Preparation of Code Standard with clear naming conventions for the artists
• Communication between programmers + QA
• Version Control

All of the things that are on this list are things that are my responsibility as Lead Programmer, which paints a clear picture of who I believe holds the blame of the shortcomings of the group. That person is of course none other than myself and I will now go through the things that I think I failed at.

Even though the Code Standard was prepared by me before the start of the project, we quickly moved away from it and created completely new guidelines that were not written down and just changed on the fly. The main reason for this is because the Code Standard was written without any prior knowledge of the language that it was written for. Another problem was the fact that I did not acknowledge the problems when they occurred and steer the group towards better habits. I will, however, say that I do not believe I made a mistake in not updating our code standard in the middle of the project since that would only have subtracted development time, but I could have done more research prior to writing it.

For the next project, I already know more about C# so writing a Code Standard will not be as big of a problem, but I will also try to focus on including clear guidelines for naming art and sound assets.

Even though thus far I have alluded to the fact that the communication between the programmers wasn’t great during this project I will now go deeper into that fact. We barely worked together on code, this was mostly due to both of us working better alone, especially when it comes to coding. I also did not really see the benefits of working together on the same scripts seeing as you can only write the scripts once anyway so I thought that it would just be a huge waste of time. I did not think about the problems that my approach would cause, such as us eventually not even being able to read each others code at times. I also thought that we were somewhat on the same page about the approach we would take when making scripts but I was clearly mistaken, this was partly caused by not having a clearly defined Code Standard. Another problem that we had because of poor communication was the fact that around 2 weeks were wasted for one of the programmers because he felt that he could continue making an asset but was clearly not making any progress, a problem which is the responsibility of the Lead Programmer.

If my group decided to make me Lead Code again then I will try to talk more with the other programmer about how we should approach the issues that are in front of us and try to have well-defined responsibilities within the engine that make sense.  I will also try to be more strict with QA and try to read and give feedback on everything the other programmer creates to have better quality code that is more expressive and less volatile.

The problems that we had with Version Control are mostly due to the fact that the group had little to no experience with it, to begin with. We did in the middle of the project realize that we should define clear responsibilities for who does what within unity so that we do not touch the same scripts or scenes. This worked for the most part but I am still unhappy about the fact that the artists and our designer did not work that much within engine rather than me implementing their assets, this was of course not their fault since it was part of my responsibility to make version control work for the group.

Again, if I were to be the lead coder for the next project, I would try to help the rest of the group out with understanding how Git works and also do more research on my own so that we are spared unnecessary issues but have improved productivity.

I will say that I am happy with the overall result of the project as well as the functionality of the coding done, I am however not satisfied with the overall quality and reliability of the code. Nonetheless, I think we did a decent job even though we had problems with illness and lack of experience and I think we improved a lot as a team over the duration of the project.

Looking forward to easier times and less merging errors.

//Fredrik Henriksen Lövlie