Game Design 2: Blogpost #6, Postmortem
|
This blog post will be my postmortem for Group Sirens work on the videogame Behemoth during the Game Design 2 course in the program Game Design at Uppsala University, Campus Gotland. I am Jonathan Berggren and I was the only programmer in our group along with one project manager, two artists and previously a designer who sadly dropped out before the start of the Game Design 2 course making us one of the smaller groups for this project. Before this we worked together on two other projects, a board game based on an already existing video game and a concept document for a potential shoot-em-up game which could have been chosen as the concept for a game in this course by any other group but sadly wasnt, seemingly because most groups picked one of 3 concepts (Umibozu, Behemoth and Etherial) which we were also guilty of so I can’t really complain. The course had us working on the game for 10 weeks and let us change things from the concept document assuming we could give a reason as to why. Most of the mechanics of the game were done faithfully to the concept however we decided to change the artstyle significantly. Not too surprisingly as the only programmer in the group, for the Behemoth project I was the lead programmer as well as the lead designer on the game. My experience in this was that I did a lot more programming than I did designing which wasnt too surprising as I mainly took the latter role as nobody else who was able to wanted it. I do still consider it in hindsight as a good choice as I was the one in our group who actually worked on the main build of the game while everyone else simply uploaded their work to be added to my build and so it made sense that I made most of the “small decisions” on the game that could be changed later. Examples of this would be things like the levelmanager and small settings like speeds, sizes etc. Ofcourse when working on such a large project with such a small team some problems were bound to happen. During these 10 weeks there were some times where one or more team members were not able to attend the daily standup in time. At one point two group members were working on the same asset and later in the project there was some confusion on how and where some assets were supposed to be implemented. In retrospect to avoid these types of issues it is important to communicate a lot, especially about your work and vision of the project, with your group. Despite these things I think that our work was mostly a success, we were consistently ahead of schedule as far as deadlines are considered and our finished game had all of the main features and more by the time of the final deadline. As we picked a relatively simple game in regards to features we were able to polish them quite a lot. The images bellow show snapshots of the intro and outro of the game respectively. That seems like a fitting thing to put in the final blog to me.
Finally id like to say that I think our game turned out very well, thank you to my group, all things considered id say we were one of the more stable / less chaotic groups from what ive heard and good luck to you all on your future projects!  |
