Post mortem: Team Bugbear Umibozu

My previous posts have been detailing the design and production process of a game me and a couple of fellow students have been producing for a course in game design. Now the project is over and it is time to reflect on the experience.

In the end I think most of me group are feeling a bit disappointed with the end result. We ended up having to cut a bunch of features due to time pressure, whilst also having to hastily add features as the deadline got closer and closer. What we ended up with was a game with the the basic components we set out to add, but without much else. Features like a second enemy type, a boss fight, or a story told by the level design, were things we wanted to add but didn’t have time to.

Screenshot of the start of our game

Most of the problems we had could be attributed to inexperience. Starting out we had a concept document which was written by someone else. Instead of sitting down and creating our own more detailed version of that document we went into production quickly using the already made concept document. This meant that we had to make up design decisions on the spot, and when we didn’t write these decisions down it created confusion later when two different people said that it was supposed to work in two different ways. This would’ve been solved by having a master document where all the design decisions were documented, instead of wasting time arguing about what we decided last week.

We also had a hard time adapting to feedback we got during or playtesting sessions. I talked a out in my previous blog post if you want to read about it, but to sum it up: The testers didn’t understand how to play the game, and instead of making changes to address that, we assumed that it would all make sense to them when we fleshed out the game a bit more and improved the tutorial. This lead to the game stagnating due to the basic mechanics and gameplay being flawed. If we addressed it earlier we would have been able make our game play better and more intuitively.

These problems, combined with a lack of time due to all of us having other lectures and assignments, meant that in the end we only managed to build a game with a the basic components. The goal is to go from point A to B without getting sunk by sharks attacking you, if they reach you they slam into your boat and deal damage to you. The sharks are covered in a cloud of mist. There are also items that are covered in the same clouds as the sharks. To tell them apart you have to the spotlight attached to your boat to shine a light on the cloud, revealing what is hiding inside.

As for what I’ve learned personally this project has been pretty beneficial. The things mentioned above are great to have experienced because now I know how important proper planning and listening to your testers are. This project also gave me the opportunity to put some things I’ve learned into practice, the biggest has been animation. This is my first time creating a high quality sprite animation for a game and I’m very happy with how my process worked, and the resulting animation. I’ve talked about animation for the enemy shark in previous blog posts if you’re looking for the process.

The finished animation of the enemy shark.

With this project being over, that is all for now, Esbjörn out!

How (not) to Handle Playtesting

During the development process we had a couple of playtesting sessions where me and my team, together with all of the other teams, gathered to show and play each others games. The reason we did this was to give us an outsider's perspective on how the games felt to play. Things that are obvious to you when you are building the game might be completely alien to someone who isn’t involved in the creation process. This is something we struggled with a lot.

In our game you’re playing as a boat. Your goal is to move forward and get as far as possible whilst attacked by sharks hiding in the mist surrounding you. In order to protect yourself against the sharks you have to shoot them with your harpoon. In the mist you can also find helpful items to pick up, the problem is that in the mist they look the same as sharks and if you shoot the items they get destroyed. In order to see if it is a shark or an item approaching you have a rotating spotlight attached to your boat. You can turn it on and off, and when it is turned on it drains energy. More energy is one of the benefits you can get from picking up items.

The problems we had during the playtesting was that none of the playtesters could figure out the controls worked and had great difficulties understanding what was going on. They had trouble shooting the sharks because the way the harpoon projectile worked was different from how projectiles usually work in games like this. The testers also never found or noticed items because the placeholder shadow they used looked way to much like a shark. This lead to all of the testers destroying everything approaching them. Even when we told them how the game worked many testers found it difficult to understand the game.

The tutorial screen of one of our early playtesting builds

My point with this post is not to discuss the exact problems we had, but rather point out how our attitude to them were wrong. After the playtesting ended we all sat down and looked at the feedback we received and we could clearly see that the testers had a hard time understanding our game. Instead of identifying that, and making changes to the game design and how the game communicates the mechanics, we shrugged it off and assumed that the testers would get it when the game was more fleshed out. Of course, when we came back two weeks later the testers still didn’t get how to play the game. It was only in the final weeks that we started to take it seriously and made changes that actually made the game more intuitive. We simplified the harpoon and made the shadows covering the sharks and items more ambiguous, which is something that we should have done after the first playtest.

When we put our first prototype out for others to playtest we had most of the basic mechanics implemented, but when they didn’t work we didn’t try to fix them, we instead chalked it up to the testers being stupid and that they would understand if we made a better tutorial and when the game was more fleshed out. This is a dangerous thought because you are trying to protect your ego instead of realizing that your basic mechanics are flawed and you’ve made a mistake, but as long as the basic mechanics are flawed, the game as a whole is flawed. It is only when you realize this and fix it that the game becomes better, and sometimes you learn it the hard way, like we did.

With this lesson learnt we strive forward, that is it for now!

Catching up

Describing Scrum and me and my groups experience with is all well and good, but I also want to go over some of the things I have been producing these last two weeks. Right now we are coming up on the Beta deadline for our project, and, due to some of the reasons stated in my previous blog post, we are a little bit behind in terms of art assets. Which meant that it has been the time for me to increase my production pace a bit.

Last week I worked on the death animation for our shark enemy. The process of how I made it is very similar to how I created the swimming animation for it. I started out by figuring out the movement, added the rest of the body, drew the outline, and lastly added some color to it. If you want a more detailed description of how I created it check out my blog post from two weeks ago.

That took up most of last week and didn’t leave me with much time to work on other assets. The good news is that this week that is exactly what I have been able to focus on this week. We started out this week by discussing what art we needed in the beta during our monday meeting. A few of those things had to be kept as a placeholder for now, and I don’t feel like they are that valuable to share. Therefore I will instead show you one of the things that I actually put some effort into.

In the original concept of our game you are meant to set sail and find Umibozu, and then escape from it when you manage to find it. One of the main topics during our monday meeting was whether or not we should include the escaping part. In the end we decided that including that segment would take too much time and effort compared to what it added to the gameplay experience. We now needed a way to signal to player that they had reached the end and that that they’ve found Umibozu. In order to show this we decided that we wanted an illustration of the player character in front of Umibozu.

I created this fairly quickly in Photoshop, which is why it feels a bit rough still. I tried taking a speed painter approach to how I created this image. Starting out my blocking in the shapes of the objects with their base colors, adding elements such as textu

re and lighting after the general composition was finalized. Because I needed to complete it quickly I also relied heavily on custom brushes in order to create textures and effects. I would love to revisit this before the project is finished and give it the touch up I think it deserves, but due to needing to complete other assets, this is how it will look in the beta.

That’s it for now, Esbjörn out!

Ready, set, Scrum!

In order to keep track of our progress and make sure that we keep on schedule me and my group have been using an Agile development methodology called Scrum. The goal is to constantly work towards creating a minimum viable product, and iterating on that until the product has the features and quality desired. It is also characterized by working in small teams with short daily meetings in order to make sure that everyone knows what is going within the project.

For our team Scrum has been a bit of a mixed bag. Mostly stemming from our inexperience with the method, and also because of the circumstances of the project. We’ve been good at grouping up and having meetings with each other. Most weekdays we meet up in order to have our daily stand up meeting where we discuss what we’ve been doing since yesterday, and go over what we’re gonna do until tomorrow. This has been helped by the fact that we’ve been meeting up to work together on the days we don’t have any lectures.

The lectures are however a part of one of the problems we’ve been having. At the start we estimated that each workweek we would spend 20 hours each on the project. However, due to lectures, meetings and other classes, the time that we’ve been able allocate towards the project have been lower than that. At least if we aim not to work during the weekends. This makes the initial planning we did at the start of the project inaccurate, and we’ve had a hard time meeting the 20 hour work hours that we plan for. As the project has progressed we have been scaling down the planned work hours for each member so that we can get a more realistic estimate on the amount of progress we are able to achieve during each week.

One thing that could also help us is to get better and get a better routine on how to work with Scrum. For example, both our sprint planning and review could be completed quicker in order to give us more working time. Right now, due to our inexperience and poor execution in how we’ve set up our backlog, we spend a lot of time discussing and figuring out what needs to be done each week. This is something we all agree that we will work on for our next projects, where we might also be able to have sprints that are two weeks long, instead of one week sprints. Having sprints last two weeks would halve the amount of big meetings we have, and also allow us to have a better flow when working. Right now it feels as if we don’t have enough time to really start working on something before a sprint review is coming up.

All in all, there are definitely benefits working via Scrum, but right now we are having some troubles getting it to work because of the circumstances of the project as well as our inexperience. We are learning a lot about what is working and what is not, which will help us as the project continues, as well as for future projects.

That’s all I had to say for now, Esbjörn out!