Blog Post 6 – Postmortem

The game is finally done! After 10 weeks of work we have created our first game as a group. To start this off I want to talk about why we chose to create a game based of the umibozu concept document. I really liked the aesthetic goal of umibozu. Mystery and excitement is very interesting. Our group felt like this was the concept that we could build upon. Our artists liked the style, the programming would not be too hard, and overall, the concept looked cool.

Many things have happened during the project, some things were good, and some things were bad. Some things that have gone well is the teamwork. Our group had meetings every weekday. We had sprint planning on Mondays and sprint review on Fridays. We kept this up during the entire project and this has helped keeping everyone on the same page.

As always, there are some things that have not gone well during this project. One of the biggest issues we had and did not realize was how we started thinking less and less about the aesthetic and more about making the game fun. This was something that made us add things the game didn’t need and remove things that helped the aesthetic but were not “fun”. This was something that happened over time as we got more and more attached to the project. This is something we should have realized earlier, and we should have looked at our game from a different view or contacted other people that were not in the project, so they could give us their view of the game. We wanted our game to be mysterious but instead it became confusing.

The game ended up not being what we were hoping it would be. The game didn’t make much sense. We did not explain any narrative in the game. we did a really poor job in teaching the players how to play. The players didn’t know what was going on most of the time when they played. If we made it clear to the players how they should play and what their goal is the game could have been a lot better. I think that this was the biggest reason the game was not very fun or enjoyable.

This project has been a mess from time to time but in the end, I am somewhat happy withour results. The game did not end up good but I learned a lot in the process. I realised that if we do not have a clear tutorial or explanation to what is happening the players will not enjoy the game as much. A confused player is going to have a hard time continuing with the game. This is our first game and we have room to fail and make mistakes, and I am very happy about that.

Blog Post 5 – Playtesting

Playtesting is often an extremely important part in game development and many huge changes can be made to games after playtesting. Some ideas may seem good on paper but when you try them out in the game they suddenly don’t fit at all. Some games have been completely changed based on playtesting alone.

Playtesting for our group was nothing like this. We have been behind schedule for both playtesting sessions and this made it hard to get good and valuable feedback. Our game for the first playtest was almost nothing like the game is now. We had made enough to get into alpha but almost everything was not working as intended. Most of the feedback we got were things we had already planned to do. We created our survey in a way we thought could help us even though the game was not anything like what we had planned. The survey ended up confusing the players and we got no good feedback from the first playtest.

The second playtest was similar but the big difference here was that the game had more art assets and a level. We got the same feedback as the first playtest. Our programmer had been sick so we behind on a lot of code work. Some programmers that played our game decided to help us and explain how we should do the code to fix some of the issues. This was the most helpful part of the second playtest.

Overall the playtest did almost nothing for us. Our group have felt that our game has not been ready for playtest during both sessions. This is not good at all since we could have gotten some very valuable feedback if our game was ready and worked like we wanted it to work. The things we are changing and iterating now are things we could have changed back then.

Playtesting is an extremely important thing to do when creating games. The fact that we didn’t have good playtesting sessions has made us forced to make some blind decisions.

Blog Post 4 – Level design

Level design is one of the things many people greatly underestimate. Great level design often goes under the radar since most of the time you don’t notice when its good, you only notice when its bad. Creating a level that would do our game justice was my main focus this week.

We are creating a game from the umibozu concept document and our game has a big focus on exploration. When exploration is a big part of the game, the level design will be a big part of the game. I wanted the players to feel like they could go anywhere but I also needed to lead them towards the end. We had a fixed start and a fixed end, but the player could go through the level in many ways to reach the end.

How do I create a level that encourages exploration but also leads the player towards the end? This was one of the many questions I asked myself when I started designing the level. We made the level wrapped on the sides so that the player does not feel stuck within a corridor. I placing objects such as walls and trees within the level and I realized I could create the level through many small options. I would place a wall with two holes in it and the player could then chose which hole the wanted to pass through and depending on the path the choose, they would get a new option. I liked this system because it gave the player a choice. The choices have little meaning if there’s nothing else to it. That’s where the challenges and rewards come in. I would give the players more rewards on a more challenging path and vice versa. The goal is for the player to see a path and through seeing the path alone estimate how tough it would be. I did this by placing things such as enemies or thick mist at those locations.

Above picture is an example of two different paths. Without mist for clarity.

I was happy with this layout and felt like it was good enough so that we could start working on the level in more detail with environment art and balance.

Blog post 3 – Scrum

It is important to have control over all the work when you develop games. It is easy to forget things or put work in the wrong places. That’s where scrum come in. Scrum is a framework for managing work. Within scrum there is something called sprints. These sprints are tasks that need to be completed within a certain time. Our group had one sprint every week. We had sprint planning on Monday and sprint reviews on Fridays.

On Mondays we would go through everything that had to be done for that week. On Fridays we would go through everything we have done. If something was not completed, we would put that at a high priority for the next sprint.

Working in sprints has worked very well for our group. It makes everything seem more manageable. I think it also helped us with not getting burnt out. Everyone is very excited the first few weeks and its hard to stop people from working more than they should. The sprint planning gives everyone a task for the week and if they are done they can relax and know we are still on schedule.

A couple of problems I had was that my work was very hard to put on the sprint reviews. I as a designer think about my game often and its not always effective work hours. I felt that I worked a lot during the first few weeks but then I do not have much to do. I try to help everyone with their disciplines, but I am not nearly as good as them. I do not think this is a problem with scrum, but it is just how game design works in some cases. I didn’t know what to do if everything was working and we were getting things done.

I realize now that I could have worked on a lot of things during this time. I could have worked with sound and level design. I forgot that these were things I could have worked on to be more prepared for the development that comes later in the project.

I think scrum and sprint has overall helped our workflow a lot and kept everything under control and it has been making sure we get things done.

Blog Post 2 – Movement

Hello! Time for another blog post. In this post I will talk about player movement in our game. The player controls the movement with the WASD buttons. W and S are for thrust, D and A are for rotation. The player is a boat and the player can traverse the level any direction. These are the two most important things when it comes to the player movement in our game. The problem that I currently have is that the movement and the perspective are very hard to fit together. At the moment our boat is drawn in a true top-down, but the rest of the level is drawn in a 45° angle. This makes everything in the level look wrong when the boat is right next to it. We have gone through a couple of things that might solve this problem but so far, we have not come up with anything that will keep the realistic boat movement and the nice perspective.

Image of the boat next to a tree.

The first solution we had was to make the movement 8-directional and have a different sprite for each direction. This would make everything look good with the perspective but the biggest problem there is that the movement will feel very wrong and not feel like a boat at all.

Another solution we have is to keep the same movement system as we have now but once the boat hits certain angles in rotation the boat will swap to a sprite that fits that angle. This seems like the best solution but the problem we have with this is that it might look weird in between these angle points. The boat will travel one direction and the boat sprite will not always point at the direction the boat is heading.

We are unsure on how we will solve this and in the end it will come down what the programmer and artist can manage.

Movement is one of the most important parts in a game like this when moving around the level is core to the game. If the player does not like the feel or the look of the boat when they play, there is no reason for them to keep playing. The boat is always in the center of the screen and the center of attention at many times. It is vital that it feels good.

Blog post 1 – The Mist

Hello! My name is Jesper Bergman and I am the lead designer for group Zombie.
The concept document we chose to create our game from was Umibozu. A big part of umibozu is the mist, the mist is used for both gameplay and visuals. The mist is used to cover things and bring a sense of mystery to the player. The player would be able to see through the mist with a flashlight. This mist has caused our group a big deal of problems because we could never figure out how we wanted the mist to work. We did not know how to make it look good or how we would program it. We started by having the mist very similar to how it worked and looked in the concept document. We quickly realised that this would be very hard to do. Our programmer and our artists had problems making it work in a way that we were happy with. We started to think about many different ways the mist would work. One version we had was that the mist would cover everything and the player would almost see nothing without the flashlight. This did not work because our programmer did not know if he could program it and the artists had problems with making the art. We realised something had to change since we were getting problems from all different angles. We came to the radical conclusion to scrap everything about the mist and have darkness instead. The plan was to use a spotlight in unity to work as the flashlight and have the mist be unlit areas. We thought that this would make everything easier but with this change came other problems in programming and art. I was struggling to come up with an idea that would help the entire group. Our programmer then managed to create a light that could work with the first iteration of mist. We realised we could solve many of our other problems with the art through small changes in the mist and thus the problem was solved. We managed to go full circle and spent many hours working and thinking for nothing. I lacked trust in my team and thought I had to change the game. All I needed was patience and it would have saved my group a lot of unnecessary work. I was too eager to create a game that as soon as a problem occurred I took the easy way out by changing the game instead of fixing the problem.

Our first iteration of the mist and background: