Overkill Post-mortem

Recap of the project
   The Overkill project went of for ten weeks during the spring of 2011. During this time we set out to develop a game based on a concept that we had previously been working on. The group, known as TrashTalk, was made up of seven second year students and one first year student, in addition to a musician from a different university.

   In short, the concept was a four player coop hack'n'slash game with a fairly free-flowing combat system. The players took on the role of the "evil" characters, sick of the ever smiling citizens of the all too happy kingdom, who with the use of steel and malice carve a blood-splattered world more suited to themselves. In the level that we focused on during this stage of the project the players set out to battle their way through the tranquil farmland, the peaceful village and past the magetower before finally breaching the castle gates and beheading the king and queen, to then set themselves up as the new rulers.

Project outcome
   Anyone who played the game at the Gotland Game Conferance will obviously notice that it did not quite live up to everything that we had planned. The most glaring difference would clearly be the lack of multiplayer. It was something that we had to cut the last night before GGC due to a handful of bugs that still remained and were deemed large enough to have a significant impact on the playing experience. Apart from this the cut features were not too obvious, such as the interior of the castle and a few events along the way there being removed.

Despite this, the game was quite well received and people definitly enjoyed playing it, with numerous people coming back to play it multiple times. Given that we managed to win the Public's Choice award I guess that we should be happy with the results.

My role in the project
   My role within the project was that as the lead programmer, as well as the programmer in charge of the network and multiplayer aspect of the code. The majority of my time was spent setting up the basic functionality needed to get the game working in multiplayer such as the initial connections, creating entities on multiple clients, and making sure that they were all synched. In addition of this I also spent a significant amount of time rewriting the code of the other programmers to make sure that their parts were properly adapted work with an authoritarian server.


Assessment of personal results
   I'll split this into two parts: one for my role as lead programmer and everything related to leading and organizing the programmers and the code, and one as my role as programmer and my own contributions to the code.


   I can't say that I am too saitisfied with the work I did as the lead programmer. At the end of last years project, Gods of Steel, I said that I would take over the role as lead programer and make sure that the code kept a much higher standard. However, I was not nearly strict enough to actually get my ideas and plans in motion. At the start of the project we had a couple of meetings where we decided on the overall layout of the code and divided the various aspects of it among the four of us. After that everyone went off and worked on their own part, and I did not take part of the other programmers code other than when I requested a specific class that I needed myself. The main reason behind this was technical issues. We did not get the Unity licences that we were promised and were therefor not able to utilize the asset server to the degree that we had planned. Despite things being partially out of my hands I still think that I could have done more to make sure that the code kept the standard that I wanted it to. 
   Apart from maintaining the standard I also think that I could have done a better job when it came to organizing the various tasks that the programmers were working on. Everyone knew what they had to do, but some tasks did drag on for far too long and even if I did encourage them to wrap things up quickly and move on, I should have been more strict and made sure that they actually did so. 


   As a programmer I am quite satisfied with my results. Given that I was in charge of the network aspect and that the whole multiplayer part was cut this may seem a bit strange, but I was there when we made the desicion and I know that the main reasons behind it were not actually related to the network. I'm not saying that there weren't bugs and issues with the network code itself, but I would argue that the main reason was in one way or another that the other programmers were developing their parts with a single client in mind and paid little heed to how it would later work with a client connected to a server. A large part of my time during the last few weeks was spent going through their code and trying to make it work in the network. In the end I think I did a pretty good job of it given what I had to work with and that it worked well without modifications after the multiplayer was cut completely. 


Skill set improvements


   Apart from improvements in programming in general, this project has especially given me a lot of new knowledge when it comes to developing games for multiplayer. Working with a game where the client is connected to a remote server is quite a bit different than if you're only working locally. There are a number of things that you need to consider, and you can't always use a normal approach when taking network delays and loads into consideration. 
   In addition I've also improved when it comes to organizing a team of programmers, and I've learned several important lessons. 
   Last but not least I've leaned and experienced a fair bit when it comes to working in teams where everyone may not be getting along perfectly.



Recommendations of best practices
 Don't let a tight schedule be used as an excuse to not do things properly.
 This was the main reasoning that I used for myself when it came to not keeping a close eye on the code of the other programmers. I argued that if I was to check everything that they did and have them rewrite things with suboptimal performance or standard then things would take too long to implement. While that may have been true, a middle-ground that works out can always be found if one simply tries.


When using a new engine make sure that you first research the known bugs and issues present within that engine.
Towards the end of the development we noticed some serious performance issues with the GUI and found out that they were caused by bugs within the Unity engine. Had we known about them from the start then we could have circumvented them, but with so little time remaining there was nothing that we could do.

Post GGC

We managed to win the Public's Choice award!

Now off to some much deserved rest.

First day report

The first day of GGC went great. In the end we had to cut a lot of features to make it work, but once we did everything came together real nicely. No crashes and almost no game breaking bugs, and those will be ironed out before tomorrow anyway.

Late night crunch

11 hours remaining before GGC opens and we're still working hard, but it's looking pretty nice.

Crunch

With less than a week remaining we're working hard to get the game finished. I'm currently working on rewriting the AI for the network. Progress on it is coming along nicely. The basic version for the peasants is pretty much finished. Just need a few last touches, and then the versions for the wizards etc need to be done, but that shouldn't be too much of a hassle.

Let's get this ball rolling

Alright. With about a week and a half remaining before the Gotland Game Conferance I figured that it's about time to get started on this blog.


I am the lead programmer on the Overkill project and I am also the one in charge of the network aspect of the code. I am currently in the middle of rewriting large parts of the code of the other programmers to get it to work in multiplayer. It was a bit of a miss in our development, since most of the code was initially developed to work in single player, rather than adapting it for multiplayer and the network right from the start. However, it is nothing that a few late nights cannot fix.

With Teddy being busy with his Dwarfs project, the workload of the remaining programmers has increased a fair bit, and with only a short amount of time remaining we are in quite a hurry to get everything in order. I do however remain confident that we will get a good, playable build done in time.

First!

This blog will cover the work that I, Fredrik Nes Sjödin, perform as a lead programmer for the project Overkill. I will be updating it in the coming days to cover everything up to this point.