My sixth blog comment

Week 6 – Carl Hvarfvenius Blomgren

Hi Carl!
I’m happy to hear that you didn’t have any major issues with the group. It is highly valuable to have good communication amongst team members, since that can really have a positive effect on the group when it comes to efficiency. It seems like you enjoyed working together with your group, and that is exceptionally important.

It sounds like you have learned a great deal throughout this course. It is interesting to read about how much effort you put into the level design and how you tried to make a good tutorial level. I can truly see that you are passionate about your work. As you wrote, we did not have many lectures about level design. Therefore, I think it was a good idea to make a lot of research, to get knowledge and learn how to make a level in the best way. However, to understand your course of action, I would have wanted to get an example of what you did to create a good tutorial level. What did you use from the different articles that you read? What subtle hints did you use in the background?

Overall, I think your blog post is interesting, since you talk about the bad and the good aspects of the past 10 weeks working together with your group. You all did a great job and I need to congratulate you on creating a good game! It was really fun to play! I hope you are as excited as I am to work on the next project, and it will be fun to see what more you can do on upcoming projects! Give yourself a pat on the back. Well done!

/Lina Femling

Do you want to play the game?

The game is uploaded on itch.io, and is free for everyone to play! Click on the link below and play the game! I hope you like it!

https://team-mimic.itch.io/beelonging

Postmortem

Ten weeks have passed and Beelonging is finally done. It’s surreal. Having a finished product; a product I’m genuinely proud of, is something I have difficulty grasping. I’m proud of the end result and I’m blessed that I had the chance to work with such amazing people. Everyone should undoubtedly be proud of their accomplishments. However, aside from the success of working together, there have been some bumps on the road. We didn’t encounter major issues, but there were situations we could have prevented. Today I present you a brief postmortem of the last ten weeks.

What went right?

1. Daily stand-up meetings

Over the course of ten weeks, we succeeded to meet up everyday for our daily stand-up meetings. These meeting were really important, since it gave the whole team an overview of what everyone was working on. During those daily stand-ups I got an overview of what everyone was currently working on and I made sure that everyone was following the sprint schedule. The meetings also brought up important discussions; things we needed to decide, as well as clearing up misunderstandings.

1. Getting along

Since day one we have been working really well together. Everyone shared the same work ethics, and was very motivated to do the best they can. We created an atmosphere where we listened to each other and where we took every opinion into consideration. Since we had a pleasant energy in the group, everyone was excited to work on the game. This resulted in a more fun and enjoyable experience for everyone.

1. Making a vision come true

Even if there were some issues when it came to envisioning some assets in the game; we created a game that everyone was happy with. All the team members contributed in different ways, with their special expertise that made the game just as we wanted it to be. Bruus and Arvidsson found an art style that everyone in the group really loved. Plähn found great ways to code the game as we wanted it to be. Kassander improved the game by finding bugs and creating great level design. And I contributed with sound and music that really strengthened the aesthetic goal, which also made the game more humorous and fun. Everyone helped in making our vision come true.

What went wrong?

1. Not being done with assets on time

Even if everyone had work ethics and motivation, there were sometimes issues with finishing assets on time. We agreed on not working on weekends, since we wanted to have everything done for the sprint on Fridays. Thereby, everyone could have a relaxing weekend and gain energy for the next week. However, that was easier said than done. This problem occurred if the group had other tasks to do in their minors, sickness or inadequate distributed assets (and a bit of laziness). The main issue we faced with this problem was that it could affect someone else’s working week. For example: the programmer could not implement an art asset since it wasn’t finished. When the art asset was later finished on a Sunday, the programmer was forced to implement it on the weekend.  

1. Playtesting

Since we sometimes were finished with assets late on weekends, we did not have the time we wanted to test the game before playtesting sessions. This problem made it difficult for us to spot bugs or glitches in the game and be prepared as much as we wanted to be. This complication resulted in a situation where we found major issues with the game during playtesting (things we should definitely have foreseen). Obviously, playtesting is for finding bugs, but the problems we encountered were things that should have worked flawlessly at that time. However, we learned from our mistake and made every group member test the game frequently during later development.

1. Different visions

Another problem we encountered was to vision an asset in the same way. We had a brief discussion about how the boss fight would be played, and we thought we all were on the same page. However, when the art asset were done and coded into the game, we realised everyone had a different view of how the boss fight should have been done. We needed to make some major changes, and the programmer put down additional hours to make it right.

What did I learn?

These ten weeks have been intense and educational. By developing this game, I have had the chance to understand my part as a project manager better. I have learned to be better at giving out constructive criticism, as well as solving conflicts or arguments among team members. I have also realised that even if I thought I planned enough, I could have planned and organized even more. In the future, I will make sure to playtest the game more often, since it gives me a better insight of how the game works and what needs to be improved. It is my responsibility to make sure everything works as it should, according to our vision. I have also learned to create sounds that would fit the aesthetics of the game. Even if I had never worked with Audacity before, it was a great experience for me. The sounds turned out great and they got a lot of positive feedback from the playtesters. Last but not least, I improved my knowledge of working in Unity. I got the chance to put art assets in Level 1 and create a nice-looking level. Since we had a parallaxing effect, I needed to understand how that effect worked, to make sure the level would look coherent and neat.

End result

Our game turned out to contain a tutorial, five levels and a boss fight. Because of this, the game felt like a complete game, since it had a clear start and ending. We were also able to add a cutscene before the game would start, as well as adding a cutscene before the boss fight. This made the game look more polished and it also added a fun story for the player to follow. By adding the cutscenes, we were able to convey the aesthetic goal better. Since the team worked very efficiently, we also had time to create hats for the main bee. These hats could be found in the different levels and be used to dress up the main bee. Everyone who played the game loved the hats! To summarize, we created a complete game that contained more than it needed. Some things did not work properly or looked as they should have, but overall the game were enjoyable and appreciated by everyone who played it.

Overall, I’m really happy with the result. This is the first game I have ever developed, and it has been a very educational and interesting journey. I’m grateful for working together with such talented people, and I’m excited to see what the future behold! Thank you for reading!

My fifth blog comment

Week 5 – Amanda Cohen

Hi Amanda!
I’m really happy to hear that the playtesting sessions have helped your group to improve your game! I can definitely agree on that it is tricky to find the bugs and wrongs in your own game, since you eventually become blind to all the different errors. My group also had issues finding flaws in our own game. However, the bugs were then discovered during playtesting. Just like you, I have certainly understood the importance of playtesting; since it benefits the development in a crucial and favorable way.

I genuinely enjoyed reading about how your group addressed the problems that appeared. You came up with great solutions, and the game have definitely turned more advanced and enhanced since the Alpha playtest. I think you have been clear about what you have done, and why it was done. You expressed your approach in a brief but understandable way. However, I would like to get a better understanding about how the procedure was done. I would have highly appreciated some pictures describing how the approach were accomplished. Since I have played your game, I may fathom your procedure better than others. Have in mind; there may be people who haven’t played your game, and would not be able to understand how you dealt with your bugs.

Overall, I really enjoyed your blog post! I may salute you for the good idea of adding a “flashlight” to the game. I think that was a great solution! You presented me with valuable information, and I will definitely remember this. Thereby, I can learn from it and then use the solutions in the future. I really wish you good luck with finalizing the game. I’m excited to play it!

/Lina Femling

Playtesting

Since the start of this project, we have had two opportunities to let teachers and other students playtest our game. These two sessions have had an immense positive effect on the development of our game.

Even if we playtested the game several times ahead, checked for bugs, searched for errors and wrongs, we were still too blind to see all the glitches that needed to be fixed. Working on the same game for weeks, makes it eventually difficult to spot what needs to be improved. That’s why we truly enjoyed having people playtest our game, since they could see errors we were too blind to see. Furthermore, we also got the chance to see what the players appreciated about the game; what was fun and entertaining. This is also important to investigate, since we want the game to be as fun as it can be. We should not only focus on the negative things, but also try to find the most favourable moments in our game. From that information, we knew what we needed to focus on to develop an even better game.

To collect data, we decided to create a survey for every playtester to answer. The questionnaire consisted of seven questions:

1. What was your favourite interaction/moment of the game?
2. What was your least favourite interaction/moment of the game?
3. How difficult was the level?
4. Were there particular aspects you thought were satisfying?
5. How did the controls feel? Did they make sense?
6. Did anything feel clunky/awkward/confusing?
7. If you could change one element of the game, what would you change and why?

Answers from the survey

By letting people answer these questions, we received great feedback on what we needed to improve, but also on what the players enjoyed the most. The first playtest gave us an insight on what people thought about the swarm function (when the player call the surrounding bees to get into a swarm, instead of being spread out). The majority of the players did not enjoy the speed boozt of the swarm function, since the bees were flying too fast. Also, there were not really a reason to use the swarm function. You could still win the game, by not being in the swarm. Therefore, we slowed down the speed of the swarm mechanic, to make it easier for the player to keep up with the change, as well as adding obstacles. By adding obstacles, we forced the player to use the swarm function. Otherwise, the player could easily die and lose the game. However, during the second playtest, we once again received feedback on the swarm function. But this time, it was too easy. The player could easily beat the level by only using the swarm function. Now, the players over-used the swarm function. We discussed this problem, and came to a conclusion. We decided to eliminate the shooting mechanic while being in a swarm. This lowered the eminent sense of being in the swarm and the mechanic were once and for all balanced.

If we would not been able to get people to playtest our game, the problems could still have been damaging our game. Therefore, we have enjoyed and appreciated the playtesting sessions, since we received great inputs and feedback from individuals who have great knowledge when it comes to games. Thanks to them, we have been given a chance to improve our game. Thanks for reading!

My fourth blog comment

Week 4 – Sophie Ahlberg

Hi!
I am delighted to hear that you solved a problem that have been an immense issue for you. There is no better feeling than overcoming difficulties. It must have been satisfying and refreshing to find a solution to your problem. Great job!

However, since I’m not a programmer and have no experience when it comes to coding, I would have wanted to get a clearer explanation of your process. You described the process very briefly and bareboned, which sadly left me confused. I understood the reasoning behind the procedure, but not how the action was done. It would have been helpful if you would have presented your process in pictures, or in a further detailed explanation.

If you were only writing a blog for programmers to read, your text is probably comprehensible for them. However, there are several individuals that have never programmed before, that may read your blog. Therefore, I think your blog post is valuable to other coders, since you are describing a problem that could have occurred to them as well. Thereby, I think your post is relevant and beneficial for them, and can be used to understand how this kind of formation is constructed. Nonetheless, the post may be too difficult for others to grasp, which sadly brings down the value of the blog post. On the other hand, your post may be understandable to others.

Keep up the good work, and I know you will overcome more difficulties in the future! Thank you for your blog post!

/Lina Femling

Creating sounds

During the last week, I have been creating sounds for the game. It has been an interesting challenge for me, since I have never been editing sounds before. Moa Bruus (Lead Sound and Artist), has been very busy with numerous artifacts conserning art. Therefore, I have been helping out by editing audio files.

To know what kind of audio we needed to implement in the game, the group had a discussion about what sounds we wanted to add. During this discussion, we realised how many different audio files we needed for every asset in the game. It was a bit overwhelming, but we were also excited to search and find appropriate and fitting sound files for the game. In an earlier post I explained how difficult it was to find suitable audio files online for the different assets. We wanted free music and sounds that would fit the different assets. However, finding free and suitable audio files were more difficult than expected. Therefore, we decided to record our own sounds for the game, which turned out to be great! Moa then created a document with all the different audio files, to make the creation of sounds more organized and easy to follow. In this document, we could easily follow the progress of the audio files, since this document were updated as soon as there were any changes.

The above picture shows an overview of the audio document, containing the different sound files that needed to be edited to fit the game concept (36 audio files in total).

We divided the different audio files between each other, and were expected to edit them on our own. However, at first we had a discussion about the different audio files and how they should sound in order to fit the concept. How do we want the bee to sound? As well as the bear and the other characters in the game? We came to a conclusion about what we wanted, and then started to distribute similar audio files to the same person. For example, I was supposed to edit the different sounds for the bear. If a different person would have edited one of the remaining bear sounds, that person could have interpreted that sound in another way. By distributing sounds in this way, we avoided creating audio files with a distinct difference.

One of the first sounds I wanted to edit was the one called “EveryoneBeeCheering”. If you listen to the unedited sound file, you’ll hear my team cheering. We created this sound, since we wanted the player to be cheered on during the game. However, the original sound did not fit the desired concept. We wanted the group of bees to sound cute, innocent and high pitched, similar to how chipmunks usually are displayed in cartoons. To make this change, I had to research for a suitable audio writing software. My group recommended me to use Audacity, since they said it is a program that doesen’t have a steep learning curve. As promised by my group, things like changing the tone or the pitch of a sound file, proved to be quite simple.

Firstly, I opened the audio file I wanted to change in Audacity. To change the pitch of the audio file, I first needed to chose the file. Then I started browsing the option called “Effect”.

In the Effect menu, there is an effect called “Change pitch”. By clicking on that effect, a new menu pops up.

By dragging the meter (the marker is marked with a circle in the picture) up, the sound will be brighter and high pitched, and by dragging the meter down, the sound will be darker and low in pitch. Since I wanted the bee to sound like a chipmunk; very high pitched, I dragged the marker up. By playing around with the marker, I could try several different versions by clicking on “Förhandsvisa” (Preview in english). When I found the perfect choice, I clicked on “OK”, which added the the effect to the audio file. Then the audio file was done! Quite easy, wasn’t it? I have used other effects for other audio files, but the “Change pitch” option has helped me to create several audio files that will fit perfectly in our game. It will be very fun to have them implemented in the game.

My third blog comment

Week 3 – Emma Jelving Eklund

Hi!
I am happy to hear that Scrum have helped your group to decrease your communication issues. By having a bit of structure, documents to follow, it is easier to get a better workflow and organising in the group. According to myself, Scrum have been very helpful and effective for the project to move in the right direction.

I think you have made a brief reflection about your experience with Scrum. I would have wanted to get a better explanation about a few things in the text. In your text you are talking about some weeks being better, and some weeks being worse, when it comes to communicating. To get a better understanding, I would have wanted to know why some weeks were better than others, and what problems you had. You talked about how your group are using Slack frequently, but what kind of communication issues did occur? Did you sometimes have problems with Slack or other channels, or did you just had problems with communication within the group (face-to-face communication)? If you would have given me an example of an issue, I would have gotten a better understanding about your content.

Also, you were talking about how the Sprint and Planning elements have helped you in this project. It is good that you have found something that is helpful for the project. However, I didn’t quite understand what kind of elements you were talking about. Were you referring to the documents, e.g Sprint Planning, Sprint Review and the Product Backlog? And also, in what way were the elements helpful to you? How did they help you with communication and organizing?

Overall, the blog post were interesting to read, but you could have expanded your reasoning about your thoughts about Scrum. However, I really appreciated you for being honest about your flaws. Not many people tend to show their true self to others, since they want to portray themselves as perfect (which no one is). I think it is very admirable of you to acknowledge your flaws, instead of hiding them. By doing that, you will grow faster and learn to thrive in the right direction. We all need to learn to understand how our minds work, so we then can learn by our mistakes and become our best self. Thank you for sharing this, it was liberating to hear.

Thank you for this blog post!

/Lina Femling

My second blog comment

Week 2 – William Teurnell

Hi!
I must applaud you for your blog post. It is nicely written and have an interesting topic. Since you started giving the reader a good description of the narratives (in the introduction), I got a detailed overview of the game and what you wanted to achieve.

As a project manager, I can relate to the decision of prioritising other features more, than putting the cutscenes as one of the biggest priorities. As you said, the cutscenes are not considered to be essential for reaching the aesthetic goal. Adding narrative cutscenes, can of course improve the game in several ways. However, there are numerous ways of finding other solutions for achieving the aesthetic goal.

Several teachers have also been very clear about how cutscenes can lose their function. Why would the player want to see a narrative story, before the game starts? Can the player click past the cutscenes? If so, what is the function of having cutscenes? Therefore, I think you have come up with a great idea of adding narratives to the game, by not using cutscenes. By creating a menu that is containing visual narratives, not in a forceful way, the player can chose to interpret the visuals and then get a sense of what kind of game it is. I think it is brilliant.

I think it were very easy to follow the process of how the menu was made, since you managed to have a red thread in the text. You were very clear on how your process were accomplished and why you made your decisions. The text is backed up by good arguments, which makes the text much more appreciated. The post is definitely valuable, since you have come up with a solution on how to add narratives, without using cutscenes. This information will be saved and used for future projects. Good job!

/Lina Femling

---

Hi!
When I read the first paragraph of your text, several questions emerged in my head. Why have you decided on the present design for your enemy? What made you do these changes? What led the enemy sprite to evolve from the original idea to your idea? I wanted to know more. I seeked a good explanation of your changes and why you made them.

However, when I continued to read, you gave me all the answers. All the questions that were circulating in my head, were gone. I continued to read your text and was amazed by how well written and thought through your text were. As a reader, I understood your process very easily. The text contained good descriptions of why you made your choices; making it easy for me to understand the decision making. Your thoughts about the robotic looks for your enemies, were very interesting and made much sense. You have really taken the aesthetic goal into consideration, and I am certainly very excited to see what else you can make to reach the aesthetic goal. I think this blog post is valuable, since you describe thoroughly how an enemy can transform into something totally different; but still be able to achieve the aesthetic goal. Everything in the text were understandable and I grasped why you did your changes and how you made them. I really enjoyed reading your blog post, since it did not contain any excess of irrelevant information, you communicated the production process in a helpful way, as well as providing me with reasonable motivations for your design decisions. Good job!

/Lina Femling

I accidentially commented on the wrong blog post, therefore there are two comments this week.

My first blog comment

Week 1 – Vidar Grönros

There are some question marks about the text. There are a few contradictions in the blog post, which makes a few things confusing. In the beginning of the text, your group didn’t wanted to give the player a feeling of adventure, where the player would be able to control a ship on the open ocean. However, later in the text, you made some changes to your initial idea; to make an infinite ocean in all directions that would keep on generating. This would thereby create the dynamics and feeling of an infinite ocean. According to me, this is a contradiction. You didn’t wanted to give the sense of adventure. However, by creating an infinite ocean, the player would automatically be able to “explore” it. Consequently, the idea of making an infinite ocean would give the player a sense of adventure. I understand your approach and the procedure in your changes. The different ideas to solve your problem is clearly described and I understand your course of action. However, it did not become clear to me why you made them.

To make things clearer, I would have needed a better explanation on what the initial concept document had in mind. It is briefly explained, which makes it difficult for me to understand why you made your choices. I think the post is valuable, since you came up with an interesting idea; an idea I would not think of myself to put in a shoot ‘em up game. To clarify, your idea is not a bad thing. The post is valuable, since you are going against the original and traditional idea of a shoot ‘em up game. If you can pull this of, your approach will be very interesting to follow since the reader will be given another idea of how a shoot ‘em up game can be like. However, the text could have been more valuable if it would have been less incomprehensive. Since there were a few things in the text that appeared confusing, the blog post lost a bit of value.