Comment #6

http://blog.erikrosenberg.se/2018/03/15/post-6-postmortem/

Hi Erik!

This was a great read! This blog post was very informative without being suffocating.

First of all, congratulations on the finished game! I see your group is missing a design minor which is sad but it seems you’ve still managed well without it.

I feel this blog post was well written and had all the information I could want. It was organized in a good way so I could understand the history of the team and the development of Behemoth. All in well written english grammar.

I can’t see any real problems with the post but if I have to come up with something I would say you had the opportunity to put in even more pictures. Since you described the whole development, even from the start of the program, perhaps you could’ve put in chronological pictures from start to finish. A time-lapse almost.

Other than that I see my own groups struggles in your text and can therefore understand the work process.

All in all, great blog post and great work!

//Karl Lindkvist

Comment #5

https://gamedesign905092715.wordpress.com/2018/03/13/how-did-playtesting-help-us-in-our-development-of-our-game/

Hi Sofia!

This was an interesting and informative read on the topic of Playtesting! Besides a few words here and there I felt it was well written and I understood the information that was given.

Playtesting is a great way to understand your own game from a different perspective and to grow and learn. I feel you described this process in this post. You described what problems arose as well as what you and your group did to solve problems and improve on flaws.

Other than that pictures are always a nice addition to show what you’ve described. For example, you could’ve shown before-after pictures of the game, or how the form of questions looked like and what exact questions you and your team asked of the playtesters.

All in all a nice blog post, well written, easy to understand and describes every part that should be described.

Thank you for the read!

//Karl Lindkvist

Comment #4

http://axelgamedesign.blogspot.se/2018/03/designing-difficult-enemy-in-aetherial.html

Hello Axel!

In short, I think this was a good blog post!

To begin with I feel you described your journey of thought when creating this enemy, as well as communicating it to the rest of team, very well. I easily understood your english grammar and found no significant problems. It’s nice to see the pictures of the creature described as well. The User Stories were good too.

I have to say that game and enemy balancing is a very interesting topic and a quite difficult one as well. As a fellow designer I like to read about the balance of health vs. strength, damage vs. speed and so on. I think you’ve done well in figuring this out when designing a difficult enemy and you described it well.

All in all, a good blog post in which I could easily read and understand what you’ve written and what your process of thought was during this design.

// Karl Lindkvist

Comment #3

https://andersdotgames.wordpress.com/2018/02/21/get-up-stand-up/

Hi Anders!

This was quite the entertaining read. You weave together information and charisma pretty well in this post
.
To start of I would like to say that I felt I understood your English grammar very well. Beyond that I understood your role within the team and your feelings towards the lovely framework of Scrum. Me, not being Project Manager but a Designer, (sadly couldn’t find the blog of your groups designer) could still get a grasp of what you were describing and discussing.

I did not feel I could find any particular problems with your blog post. If I have to point out a possible problem with an already good post is that my clear understanding of Scrum might be because our groups Project Manager has instructed us well on the subject and we’ve been using it to great success. So if I’m pretending that I have absolutely no idea about anything called Scrum or group work, would I still understand your post? I would say you could describe the work process in more detail, day to day, for a week. To really hammer in the concept of Scrum to someone oblivious to it.

Other than that, good post and thank you for the fun read!

// Karl Lindkvist

Comment #2 – 5SD064

https://thephantommenaceisnotthatbad.wordpress.com/2018/02/15/spooky-tunes/

Hello Teo!

This was an excellent blog post and a very interesting read. It was very informative and described your creative journey from research and inspiration to creation. It was easy to read and written in good and understandable english. The videos you posted worked very well together with your text and gave me a deeper understanding of what you were describing.
I can’t say I have any general complaints about this blog post as I felt it did everything it’s supposed to do for the course requirements. However, if I have to pick something that could be even further improved on this already good blog post I would’ve personally enjoyed even further description of your creative process and even more music theory. What did you play on, how did the piece of in-game music you post evolve through various stages and so on.

Other than that I, like Elias, took the liberty to listen through the other Umibozu tracks on your Soundcloud. Great stuff. Really liked the Menu Theme.

And finally, I have to agree that Atlantis and Treasure Planet are both severly underrated.

// Karl Lindkvist

Comment #1 – 5SD064

https://kassandergd.wordpress.com/2018/02/09/cursor-design/#comments

Hi Maximilian Kassander!

If I would summarise this first blog post in short and in general, I would say that this was a good and informative read!

I felt that I understood what you were discussing about this specific item. It was written in easily understandable and readable English. You describe the purpose of the item as well as the problem that arose and how you solved it as a designer, as well as how you solved it together it with the rest of the team.

As a fellow designer I found it to be an interesting learning experience on how you work as a designer in your group.

I do not really have any general issues with or complains about the post on this blog since I felt it was easily understandable and reached the required goals of the assignment.

Well written, well explained, I look forward to future posts!
/Karl Lindkvist from Team Lychantrope

5SD064 – Game Design Blog 20/03

Postmortem

Six weeks ago, our group, Group Lychantrope, started the development of a game called ”Beelonging”, based on a Game Design Document written by another group.

During the course of this development we’ve had the opportunity to feel what it’s like to develop a game from scratch. We’ve appointed roles within the team, responsibilites, organized daily and weekly work, set up goals for both each team member as well as the group as a whole. It’s been a great learning experience.

Luckily for me my group has worked well together without any large crisis affecting the development.

What went right?

First of all, the final product that was presented via a final playtesting session was a great success. Both students and teachers who played it seemed to enjoy it and from the feedback that we were given we felt that we had managed to succesfully create the feelings and aesthetics we wanted the Player to experience.

Our teamwork worked very well throughout the entire process. Besides having the daily stand-ups and the weekly SCRUM reviews we also kept in contact from home via various chat software such as Slack and Discord. There we could keep updating each other on our individual work and prepare for the coming days and weeks. We had good chemistry in the team and I felt that everyone had a voice and their opinions were respected.

When problems came up, such as bugs in the game, or questions about design choices, we could either solve it via online chat or have a meeting, depending on the size of the problem.

So all in all I felt very happy and comfortable with the team and with our teamwork and workflow. Looking forward to continued work!

What have I learned?

As this is the very first time I’ve ever developed a video game as well as working together with a team for such a long time it’s been a good learning experience. As the Lead Designer I’ve learned to communicate my design decisions better. At the start I took it for granted that the rest of my team always understood what I was looking for but as it turns out that wasn’t always the case. Not being the loudest or most confident person I felt that  this also meant that I grew as a person. That I should be confident with my design and ”drive the design bus”. I’ve also learned what it’s like to be dependent on other persons who in turn are dependent on me in return.

One thing I had to keep reminding myself was to always compare my design decisions to the aesthetic goal. Sometimes, even if an idea sounds great on paper, it might not fit the rest of the game and turn out bad.

Personal Conclusion

So, to conclude, I learned a lot and grew as a designer and as a person. Most of all I had fun. Genuine fun. I’ve never been the type of student to study a course where you have to read 200 pages in two days and have a huge exam and then repeat (think economy or law). Being a video game designer though, and being the Lead Designer, has been a lot of fun. Serious. But still fun. Serious fun.

End Result

The end result of this project was a colorful and cheerful game in the ”shoot ‘em up” genre. In Beelonging, the player controls one bee in a larger swarm of several bees. Together with the swarm the player has to navigate through a scrolling vertical level on their way back to their bee hive, all while fighting off various dangerous insects such as wasps and spiders.

By collecting honeycomb pick-ups scattered throughout the level, the player gain energy which she can then use to bring the entire swarm together for increased offense and defense agains the oncoming enemy insects.

Through the combined effort of the team we have created a game with original art and animation, several programmed and functional enemies who acts correctly in the ways they were designed to act and a scrolling level with a clear start and finish.

Visual and audiotory feedback has been constantly improved and polished into a satisfying and coherent final product.

I feel we managed to develop the product we set out to develop. Our aesthetic goal for Beelonging was to create the feeling of belonging to something – such as a larger group. I believe we have created that feeling in the game via gameplay, visual feedback and audiotory feedback.

To see and experience the end result in person, you can visit the following link down below which brings you to the official website for our finished game – Beelonging.

This is the link which brings you to our website where you can easily download and play the finished product! Enjoy!

// Karl Lindkvist

 

5SD064 – Game Design Blog 08/03

The effects of Playtesting

Hello yet again! This week I will be writing about the effects that the sessions of playtesting had on our game, Beelonging.

During the course we had the opportunity to let other developers from the other teams, as well as the professors at the university, play and try out our game. There were two sessions, Alpha playtesting and Beta playtesting.

The point of playtesting is to let players who have no previous experience of the game play it and give critique feedback. This feedback is then used to further improve the game for the future. Playtesting is used all throughout the industry, because it offers the unique perspective of outsiders. If you are the developer of a game you will have knowledge of every little mechanic, and every little trick to easier kill certain enemies and so on. Therefore, it can be difficult for the developer to fully realize how difficult or balanced the game may be to the crowd at large.

During the development of a game, the product is most often cut into three main parts – Alpha, Beta and Final/Release version. It may also be further cut into pre-alpha. During the course we’ve heard several times about the importance of the alpha. The mechanics that are in the alpha IS the game. The rest is simply balancing and polishing. But if the alpha isn’t fun, the final release version won’t be fun either.

So, during these playtesting sessions our group set up the game on two laptops for other people to play. We let each playtester play as long as they want and then we ask them questions that we as developers felt were important. Our group knew that many teams were to use online surveys that their testers put their answers in. We wanted to make a different approach so we decided to talk to the testers directly and then write down their feedback.

This proved succesful, and we recieved a lot of great feedback. For example, the health of the spider and wasp were changed since they were too strong and a lot of visual and audio feedback were added in the game to better communicate certain in-game events to the Player.

We then summarized our feedback in a google docs document, excerpts from the Alpha and Beta playtesting sessions can be seen below:

---

I felt that the playtesting sessions were extremely useful and were the main reasons for a lot of design decisions and changes made throughout the development phases.

// Karl Lindkvist

5SD064 – Game Design Blog 01/03

Level Design and the introduction of difficulty, enemies and mechanics.

Hello again! This is the fourth blog post on my game design blog and this week I will describe my process of designing the level for the game our team is currently developing – Beelonging.

To begin with, Beelonging is what’s called a ”Shmup”, that stands for ”Shoot ‘em up”. It’s one of the earliest concepts of classic game design. Amongst famous retro arcade games you might’ve heard of games such as ”Galaga” or ”Gradius”. These can be organized further and our game is a side-scrolling shoot ‘em up, which means the screen scrolls continuously at a set pace.

While level design in a platforming game such as Super Mario Bros. includes a lot of design when it comes to the environment which is used in the platforming gameplay, the level design in a shoot ‘em up is based around the waves of enemies that flies across the screen and the Player needs to shoot down for points. I read an article about level design for shoot ‘em ups that described the process as the creation of a symphony. The enemies comes in many different variations of waves. You may start out simple, introduce different enemies at different points, introduce large waves that comes in somewhat like snake. Good level design makes the waves should flow together in a very natural way – like a symphony.

So how did I go forward with this in mind? Beelonging is being developed in the Unity game engine. In my Design minor we’ve been taught some basics on how to work within Unity, so I felt at least somewhat familiar with it. The question was how to easiest create, organize and implement different waves into the game. The solution came from our programmers. They asked me what exactly I would wish for in a simple spawning system, and then they got to work and coded a program within Unity that has helped me tremendously with level design.

In short, I have a folder with all the enemies, and I can simply drag them into a list. Within this list I can then decide which wave should come at what point in the game, I can change their positions based on a classic XY-coordinate system. It looks like this:

At the bottom left corner is the folders in where I can find the various enemies, the bottom middle shows what’s inside a folder, in this case the waves I’m currently working on, and on the right side is the list in which I drag enemies and waves and where I decide their time and position within the level.

Next up is the question of balance. You can’t start the very first level of a game by having a massive wall of enemies rush the player. You need to introduce the controls, the mechanics, the enemies and gradually increase difficulty as the player learns about the game. So, in my first version of the level, the game starts out with a few second of breathing room in which the Player prepares their mind and hands. After those seconds the very first enemy appears – just a simple fly. The Player can see that the enemies comes from the right side of the screen, and by pressing Space the Player shoots out a ball of Honey and defeats the fly. The next wave is four flies, two at the top, two at the bottom. This is to incline the Player to start moving around to shoot enemies at different positions. The third wave is a group of flies spread out across the screen, to test out what the Player has just learnt about controls and shooting.

This is a simple way of introducing mechanics while increasing difficulty. Each new enemy will be introduced alone, as to show the Player how this enemy works, before combining that enemy with others in larger waves. There will also be situations where we introduce our Power-up – the Golden Honeycomb, and a larger wave right after so the Player can immediatly test out their newly found Power-up.

As the level design work goes on, challenges will include coming up with creative combinations of enemies within a wave. The final version of the game is expected to be aroun 5-7 minutes of gameplay. With four different enemies to create waves with, it will all be about creating fun challenges to not make the level boring.

To help me out I report to my team when I have a newly updated level which I then have them try out and give me opinions on.

That’s it for now, next blog post will be a reflection on the Playtesting sessions!

// Karl Lindkvist

5SD064 – Game Design Blog 22/02

Working with Scrum

Hello again! In this weeks blog post I will discuss my experiences as a team member from working with the Scrum toolkit during the development of our game. I will explain what Scrum is and how our team has implemented and used it, as well as my own experiences as an individual team member.

Scrum is a working toolkit that was first introduced to our groups Project Manager in his minor and then from our Project Manager to the rest of our group.

Scrum itself is a framework and philosophy that can be used by teams to work as productively as possible and use the most of their time in the most productive way.

Using Scrum, each week for our team starts on Monday with a ”Sprint Planning” where the team has a meeting where we discuss where we are and decide what should be done during the week. This is known as a ”Sprint”. It’s the planned amount of work from Monday to Friday. Using an excel document on Google Drive, the work is seperated into the team members individual minors, as seen in the example picture below:

The questions of who gets what work is something that is discussed amongst the team members. Perhaps the programmers are in need of specific design decisions which then needs to be prioritized by the designer.

Next in line on the picture is the ”risk” of the work. This can be seen as the difficulty the person responsible might have with the work. If the person has never done a specific kind of work then that would be considered a high risk for possible problems.

Each task also has a time estimation set by the person responsible for that task. A preferable total time for each member during each sprint, which is from monday to friday, is at least 20 hours. That would mean at least four hours each day focused on the Sprint workload.

When the Sprint Planning is concluded the Sprint for the week has officaly started. Each day the team have a ”Daily stand-up meeting”. This is a short daily meeting where we discuss what we did yesterday and what we plan on doing today. It is very useful because we can talk about what problems might’ve arisen during the previous days work.

At the end of the week, on Friday, we have a ”Sprint review”. This is where we sit down and discuss what we got done during the whole week. What tasks that we set at the start of the week were we able to finish and how did it go? Did anything not get finished? Why? What other problems and issues do each member have? We then decide that the work week is finished. If any member wishes to work during the weekend that member is of course free to do so, but the optimal goal with the Sprints is to be able to work as productive as possible from Monday to Friday and have the weekend to rest.

Besides Google Drive, our team uses an online software called ”HacknPlan”. Within Hacknplan we can keep track of each others work, what we’re currently working on, what we’re going to work on next and what work we have finished. This is very useful since the work of the whole team is dependent on each other. An example of how this looks can be seen below:

From a personal perspective as the Designer of the team, Scrum has been a very positive and well working framework. It has introduced an organized and clear structure to my own work as well as a good teamwork with the other members of the team. I’ve also felt a sense of constant progression during the work since I can follow the teams progress and get response on my own work at any time.

I have never worked like this before and it has been a very positive experience so far and I think it will continue to evolve within our team and become even better!

// Karl Lindkvist