“Fear is in me” Postmortem
|
Hey! This time I’m going to sum up the past weeks that my team and I spent on creating our first digital game – Fear is in me. Let me describe the end result then! My group produced a short Shoot ‘em up game with unusual shooting mechanic. The set-up is a dark forest full of 3 different kinds of terrifying and bloodthirsty creatures. But none of them is true – in fact, everything takes place in a little girl’s mind, as she is having bad dreams that she desperately tries to get rid of. The player is put in situation where he or she needs to continuously move forward, being chased by the wolf monster. Other beasts spawn randomly on top and sides of the screen and deal damage on touch with the character. The player’s only defence is flashlight and different kinds of light sources which can be found on the way that harm enemies inside the light cone. 2 measures – the screen getting darker and quickly increasing difficulty support the feeling of raising tension. The game ends when the player manages to survive long enough and reach certain point. The initial plan assumed that there will be a boss which needs to be defeated in order to free the girl from her nightmares, however my group didn’t make it within time frame. In brief, a quick, rather difficult game that takes the player beyond regular shooting mechanic and which lacks a bit of satisfying factor was produced. Now, when you’ve been introduced the outcome, I will proceed with my analysis. As a producer and a scrum master, I’ll focus on management point of view and go through what I am satisfied with, what could have been better and my final conclusion. First of all, my group manged to form an exemplary team in accordance with one of Agile’s principles that states: Self-organizing teams encourage great architectures, requirements, and designs – Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products. Even as just 4-men unit, we were able to fulfil the concept of cross-functional group with sufficient knowledge of development and design. By combining forces, closely cooperating on all the fields, working together in the same room and not limiting ourselves to just our minors, it became possible to work very efficiently. Following the rule about frequent and clear communication was also easier because of the co-located manner of working. Worth mentioning, all of Rakshasa’s members agreed that arranging it that way was a very good move, despite the fact it was a bit troublesome at the beginning. That leads us to another aspect which I’m glad about – leadership. The development of Shoot ‘em up games was the first long-lasting project in our programme and beforehand I was convinced that maintaining high level of motivation and developing group dynamics in new circumstances would be a tough task. Even though “long-lasting” might be a little strong word for it, I’m certain that every team had to get through tinier and greater conflicts, however solving them in my team went smooth. I wasn’t trying to avoid clashes at all costs, but rather to bring up topics to be discussed and point out problems that needed to be dealt with. My team appreciated that kind of approach and I believe it was something that allowed us to grow as a group. On the flip side, there are several things I’m unsatisfied with. The prime example would be that we were unable to fully enforce another Agile principle. The idea is to deliver working software each sprint. We were certainly developing iteratively and pushed the project closer to the end each week, but would we be able to take everything we made each sprint and make a release out of it? Not really. In my opinion the way it functioned was more like a traditional approach dressed up as Agile. Luckily, that leaves clear message, pointing out what needs to improve. We should have worked on 1 or more features as a team over single week, instead of picking bench of loosely connected assets that can be later merged together. In addition, I think that learning more about scrum in advance would be highly beneficial – I would have used tools that we were learning about concurrently with ongoing project on the PM minor if I was aware of them beforehand. In accordance to our PM practise, velocity charts could be used as a tool to track the team’s capability and incentive to make our working standards higher. Besides that, in hindsight I noticed another thing that I believe I could have done much better. I think I should be more consistent and at times more strict in what I demand from my co-workers. If they have just proper amount of pressure on them, if they know that they have certain number of tasks to handle and they are not overwhelmed – their productivity increases. Additionally, seeing visible progress encourages everyone to move forward even further. Overall, making a computer game was exciting experience. This first ever project was challenging, but we made the best of our abilities and I’m personally satisfied with the end result. It was also a very valuable lesson and in retrospect, it allowed me to refocus on things that I found out to be faulty and to set up new objectives. From now on, I will strive to present more control over the project, not in terms of power, but rather to make it stable and organised. Moreover, I’m aiming at becoming more charismatic leader and I’m going to utilize bunch of small details that can help me with that. Cheers, Krzesimir  |