Blog comment #1

Link to original post: https://mateuszgamedesign.wordpress.com/2018/02/08/blog-1-scrum-documentation/

It is very clear what you have done and how it is done. I like that you have taken in what we have learned during the project management course and trying to implement it, by using MoSCoW. It is also very good that you are being agile and changing and adapting from the original scrum document we were provided with, to be able to do a better job.

Things to improve is to tell the reader the changes (in this example) that you did, before saying the reasons, because this can help the reader visualize what it is you mean and are talking about more clearly.

Otherwise it is very clear why it is done and it contains some points of value that I can take with me to think about in my own group.

I hope that you are able to make a blog post where you can discuss how these changes helped and or hindered different parts in your project at later date.

Blog comment #6

Link to original post: https://makingumibozu.wordpress.com/2018/03/20/post-mortem/

Hello Alec!

I am glad that you are happy outcome of the project and that you learned something in the process.

As you brought up the minimum viable product, it came to me that I never even had a thought of this during my teams project. To see that teams had difficulties with this, will hopefully help me in the long run as well, so thank you for bringing this up in advance.

One thing that confused me a little bit is: “The process was different from what most of us had done before, despite Scrum being the framework for it.”. Does this mean that your team have worked with scrum before this project? Or am I misunderstanding something?

Other than this, it is clear what, how and why everything is done and there is some value to reading this from a new project manager’s point of view, since you bring up problems that I have not encountered yet.

Good job and good luck in the arcade game course!

Blog post 6: The end result

Hello there. This will be the last blog post about the game development of “Depth”.

Depth is a side scroller, shoot ’em up game, where you play as a rookie submarine operator. While exploring the depths of a cave you encounter a giant monster. The goal is to avoid or shoot the enemies that tries to stop, blind and block you and escape the dark cave before the monster can reach you. Use the submarines light to find the way out and if you are lucky, there might be some wreckage parts lying around to help you out.

The project was very smooth, with few problems and we managed to implement everything that we wanted in the end.

While all of the items in the product backlog was implemented, the game could have used some more external playtesting before the final presentation of the game. Though there were no real bugs, except for one of the players being able to push the shrimp enemy and making it into a useless ball, the game was far too easy. Most players could go through the entire game without dying or even being close to dying. Other than that, the game was very good, when taking into account the amount of time given.

 

A lot of lessons were learned during this project, that I will write about from a project manager’s perspective. Some examples of what this project taught me was how to keep a clear and continuous communication, how to increase team spirit and what the job of a scrum master entails.

To keep a clear and continuous communication we used sprint planning and review meetings, daily stand up meetings, design meetings, and we had meetings where we talked about the parts of the project and the game that the team members wanted to talk about every time we met. Be it after a lecture or just randomly meeting each other. We also wrote to each other on the communication app Slack. The Slack chat was active constantly, so that everyone got the help and answers they needed fast. What I learned from all of this was that a team needs to function is this kind of communication. What could have improved the project, would be to work in the same space. Since this would give everyone an even better understanding of what everyone else is doing and would make us able to give fast feedback.

I was very lucky with the team that I got for this project, since we all had a similar idea of how the game was supposed to be. For this reason we did not have any fights about the design. The team also had a clear and continuous communication through our daily stand up meetings, the meeting we used to have right after to help each other with problems and through talking via Slack and Discord. This made sure that everyone knew what was happening and how to help where help was needed.

A problem that the team faced, was low motivation. This happened towards the end of the project. A reason to why this occurred, could have been that the talk about the upcoming course, Game Production 1 – Arcade Game, was increasing, therefore, a lot of people turned their attention to finding groups and game ideas, instead of focusing on the game that we were currently working on. To counter this problem, it was decided by the team, with help from our second year scrum master Kim Ohlsson, that we were going to do something outside of the project. The activity that was agreed upon by everyone in the team, was DND. After this was carried out, the results that we wished did not occur. The motivation did not increase, though the team spirit was increased. If this was done earlier, it might have helped the motivation not drop. Doing activities outside of the project could also increase happiness, since it could take away stress. This is something I should bring with me for future projects.

Personal lessons, about the job I had in the project, were very useful. Since I do not have enough programming experience and knowledge to help (yet) or have any graphics skills, I had a lot of problems with feeling a bit useless. This is where Kim helped me a lot, to feel more confident, that I actually had an important role in the project. After a conversation with Kim, I started to plan on how to make it easier for the team and through this, I learned more about what the job of a project manager/scrum master entails. While it was not something that I was actively thinking about doing, I was solving problems, preventing problems from occurring, and I was thinking about solutions to problems that had not yet occurred, but could not be prevented.

Link to download Depth: https://clepirelli.itch.io/depth

Blog comment #5

Link to original post: https://antonberglundgamedev.wordpress.com/2018/03/08/week-5-using-playtesting-during-development/

Hello Anton!

In the beginning of your blog post, you mention that you used internal playtesting, as well as external playtesting with other students or dedicated testers. When you mention these dedicated testers, I wonder who you mean. Are these random people that you got in contact with or are they friends and family that helped you out? Another question this brings, is how these playtesting sessions were preformed. Did you give them a questionnaire to fill out after playing, like in the sessions we, the students, had?

Other than that, you explain why the playtesting is done in a very concise way and give a good example to why it is very necessary to have external playtesting. As you had a big problem with communicating controls to the player, it was an easy problem to find and an easy solution.

So in conclusion, it is a concise post with good information on your game development progress. Though it would have been good to clear up a bit how you preformed the playtesting.

Good job and good luck in the last couple of days!

Blog post 5: Playtesting

Hello there.

This week I am going to talk about how playtesting has affected the development of the game “Depth”. During this course we had two different sessions of planned playtesting, where everyone in the course and teachers, tests all of the games in development. The first session was right before the alpha presentation and the second session was right before the beta presentation.

To do this, we used two computers with the then latest version of the game. When people came to try it, we always had two members watching them play, to take notes on what was working well and what was not working well.

During the first session, that was right before the alpha, we quickly noticed that people had a hard time distinguishing between the enemies and the power up. Because we did not have anything to show what was an enemy and/or friendly item, the playtesters spent a while shooting at everything, no matter what it was they saw.

To counteract this problem, we put in voice acting in to our game, that explains everything in a tutorial level. Though, this was not implemented until after the second playtesting session.

During the second playtesting, we still saw the same problem with people shooting everything, atleast from the people that did not try the game during the first playtesting.  Though this has been solved with the voice acting that is now implemented.

Another problem that we noticed was that the playtesters did not see the boss that is chasing them, since there is very limited light. We did have a light from the eye of the boss, but it was not enough. There were playtesters that died several times without noticing. When asked if we reused the same level in a loop, it was obvious that it was a problem. Therefore, we decided that there had to be a glowing outline on the boss, for extra visibility.

The playtesting that we had by sending our game to friends, that are not in the same education, gave the same negative results.

Though, the positives from the playtesting is that we got the aesthetics that we are looking for right. The “last leg” theme, as well as the stress and horror feeling of the game are all met, according to the testers.