Blog posts for game design courses

This is the place for my blog posts in game design courses

 

Postmortem – blog 6

We made it! During a 10-weeks course, group Kraken built a shoot ‘em up game that works! The game has a tutorial scene, two different scenes of gameplay and a final scene when the player meets the boss in a final epic fight. We have a power up that finally works (!) and two different enemies with attacks and movement patterns that makes them very different from each other. Our boss enemy has three different attacks. I am proud of us!

Group Kraken started this project as a quite immature group, as could be expected. At the same time, we felt focused and exited to start working. There were some delays in the beginning since we were told we could not start working before we had a kick of meeting together with our Scrum Master, but as soon as that was done we were ready to go.

My first goal was to get the Scrum meetings going as soon as possible, to help us not waste time on not knowing what to do and when to do things. It took about a week and some collaboration with the project manager and after that the meetings in our group has run smoothly speaking about scheduling. However, during the first weeks more than one group member did not attend to all meetings and did not tell the group why they were absent or when they would be back. That raised some irritation in the group, but at the same time I am proud of how my group handled this. The ones in the group that were present did not waste too much energy because of this or lose their spirit but instead increased their work speed from week to week and continued doing so until the end of the project. Since the opposite also could have occurred, that the feeling in the group could have been “why should I work when he/she doesn´t”, this was a great way of handling the situation.

Once the meetings were on the role and managed by the project manager, my next concern was to take lead of the design process as the lead designer of the team. I decided right away that I was going to do this by using user stories, as I have spoken about in previous blogs, and I am very happy that I did. Already for the first sprint planning meeting I presented the first user story to the group and overall that went well. What I did not realize at that time, but have learned during this project, is that we as a group did not have the same picture of how the game or features of the game should end up. This led to misunderstandings and some energy waste in the first couple of weeks. I spend a lot of time thinking about this and how I could improve my communication skills when talking about the design of the game to the team. The solution I came up with was:

•  Prepare both sprint planning meetings and design meetings even more. For example, at the end of every week I rewrote the user stories I had from the beginning of the project, so that it would fit the team and the game for the sprint planning the upcoming Monday)
• Draw sketches of the features on the whiteboard when a suggestion came up, so everybody could see and react at once. When I started to do that, group members became much more active during the meetings and said “What, no, that is not how I want it to be!” and asked, “Can I come up and draw how I see it?”. Of course you can! And when we started to do that, we really improved our communication in the group.
• Talk and ask and explain repeatedly when talking about the features in the game – what does it do, how does it look, what is the behaviours of the feature? Every time I felt that we had come to a decision, I summarized the details out loud one last time, asking the team “Do we now see this in the same way?”. This helped the work in the sprint run much smoother.

Did I learn something from this experience, during this game development project? I did indeed! As a game designer, I now know from experience what I had read about in the literature, that communicating a vision to a team is a difficult task. I have tested different ways of doing this and I have improved my skills in the subject. I know that I should start earlier with learning how the team wants and needs me to communicate and that will save us time and energy in whatever group I will be a part of in the future. 

If I could wish for one thing to be different before the course started, it would be that all students should have been prepared better for working in Scrum. That would have made a huge difference at the start of this project, especially since we did not receive a lot of information as the course started either. In my group, the solution to this became that I as designer (who had been taught about this in the previous course) as fast as we possible could helped the project manager of the group understand the basics of this agile framework and after that we have kept on improving.

The biggest weakness of this team I would say was quality assurance and the definition of “done”. Yes, we talked about it in the beginning of the project and tried to set our standards. Still, week after week, when it was time to implement and test features in Unity, assets did not work and had to be adjusted or redone. We improved some during the project but the problem with this was still present in the end when we built the final level – things did not work as they should and we spent a lot of time fixing that on our last workday together. Because of that, we did not have enough time to build the final level. We managed to put things together and the game running, but there was not enough time left for balancing and tuning. This is an important lesson that I will take with me into the next project. Regarding that final level, already before the final playtesting session I was aware that it is too difficult for an audience outside our own class, and that was confirmed by the playtesters. With a better planning for the end of the project, this could have been avoided. Still, as I know why it happened and what we could have done to fix it, I feel that the lesson is learned.

The core strengths of this team were the focus of getting things done no matter of group members were missing or other obstacles that came in our way. We also had a good way of responding to the feedback we recieved from the playtesting sessions, as we took the answers seriously and every time we tried to make changes that would improve the experience for the players. The final playtest session we also recieved valuable infromation, but since we will no work more on this game I will take that feedback with me into my total learning experience from this project. When I look back, I cannot see that we had even one break down as a group during all this time. That is also something to take with me. 

The final question I am asking myself is – “Am I satisfied with my learning outcome from this project?”. Yes, I am. I have learned tons of things that I will take with me into my next project – things I will do sooner than I did this time, things I can do better than I did in this project and things I will not do again because I now know better ways of doing things. I feel super exited to get into the next project in the education and keep evolving as a game designer.

  

 

No more restart for “Atherial”, it is time to hit exit and move on. Thank your for reading!

 

Playtesting – Blog 5

From the beginning of this course, I felt that this part of the development process – playtesting – was a little bit frightening. I thought that the game needed to be almost finished before it was any use in letting someone test it and that it felt scary to show others our product.

Reading the literature about game design and playtesting, and by watching lectures in the subject, I have started to understand that it is never too early to playtest your game. I have understood that if you wait until you have nearly a finished game, it is way to late to have a playtesting session, since it will be too late to make any important changes. In that state, you might be able to do some cosmetic changes, but the most important things like the core mechanics of the game will not be something you can change at that time. Also – as time has passed by – for some reason playtesting does not feels as intimidating as it did at the start.

A playtesting session is an opportunity when you as a game developer – if you know your MDA (mechanics, dynamics, aesthetics) – can test how the players experience your game, in a much deeper way than if it is “fun” or not. You can test your core mechanics, your aesthetics, the difficulty level of your game and lots and lots of other things. To make the most out of the two playtesting sessions in this course, I decided that we would use both a survey for the players to fill in after playing our game and an observation guide for us in the team, to help us focus on things of value while observing the players. Before the first playtesting session, I talked with the group about playtesting overall and I talked through both the survey and the observation guide, letting them comment and ask questions, so everybody would feel prepared and know what was expected from them. 

As the lead designer in the group, I designed the survey for the playtest sessions. The questions were designed for playtest 1 (before Alpha), with only a few questions. We did not have a lot to test at that time, so we wanted to know how the players perceived the game mechanics and if there were things they appreciated or not. Since the playtesters were very generous in providing valuable feedback through these questions, I decided to use the same questions for playtesting 2 (before Beta).

There were more things we wanted to know about our game, like if it was too easy or too difficult to play, if there were things the player did not understand  and if there were parts that were frustrating for the player. My plan was to receive answers to these questions through observation, a powerful tool in playtesting. I therefore prepared an observation guide for us developers, so we knew what to focus on when observing the players playing our game:

From the playtest sessions we received a lot of feedback, both from the survey and from observations. One thing I take with me into the next project though, is that most of my team members did not write down their notes from their observations on the observation guide itself, but on the back of the sheet. For some reason, they did not think this was easy to use. I need to think of how to improve this part of the playtesting next time I plan for one!

The next image shows a screenshot of how I summarized the result from playtest session 2, where I divided the result into categories based on feature.

The final picture shows a screenshot of a part of the ”to-do-list” I made after analysing the results (focusing on what would add most value for the player).

To summarize my experiences from the two playtesting sessions we have had during this project, I must say that it turned out surprisingly good. We received a lot more feedback of value than I had expected, feedback that has led to improvements for our game. Thanks to all of you that contributed!

Adapt to circumstances and grow as a team. Blog post 4

Working in sprint 6 we are now close to Beta. All core movement, features and challenges area supposed to be implemented (at least close to finalized) and between Beta and the Final version of the game there will be time only for tuning and polishing the game.  

Our goal for this sprint is the final challenge, the boss fight if you wish. The sprint planning now works smooth for group Kraken. It works like this:

I show the user story for the sprint for the team:

Then I make a quick sketch of the scene on the whiteboard and we talk every part through, before we start formulating the tasks for the week.

This is a rough description of the final challenge and end scene of our game:

• The whale appears from the right, fronting the player for the first time
• The whale uses its three abilities:

Lightning breath

Call for allies

Ram attack

• The player does her very best not to die from the attacks from the small enemies and the whale.
• The whale dies from a final epic shot with the harpoon

• The player feels like a champion. The end of the game!

The level design will be finalized this or next week.

Our group has so far encountered one obsticle that got us out of balance for a while. Somewhere in the middle of the project one of the two artists left for a three-week vacation. Since we did not know about this vacation at the start of the course, we planned the project sized properly for two artists. When that person left, it took us a while to rethink and change our design to match the new circumstances. I think some energy got wasted as well, before we decided to do the best of the situation and move on. Now we have adjusted to the situation as it is. I plan the user stories with this lack of artist in mind and the artist that is present is doing a great job, performing his very best every week, and all the art tasks from the sprint planning is done when the sprint is over.

Lesson learned – don´t get stuck when something unexpected changes the conditions. Adapt and you will grow as a team.

Note that the pictures are not screen shots, I have put together not finished concept art to show a mockup of the final challenge. The harpoon and both the small enemies are made by Isak Mansén; the ship, the beam, and the whale by Emelie Almroth, and the UI by Juste Eriksson. The lightning breath, the call for allies, the damage indicators on the whale and the ship, and the background are mockups.

To Scrum or not to Scrum – Blog post 3: 20180222

Our way into Scrum
In my group (as in other groups as well I believe) it became obvious, that only the ones with design as a minor had knowledge about the Scrum framework when this course started. Not that we were experts in any way, but we had at least read about it in the previous course. The project managers started to learn about it now in their minor, but since both courses started at the same time, at least my project manager felt it was hard to support the group in a method she did not know enough about. Our solution to that was that the project manager and I had a couple of meetings just the two of us, where I could help her get on track and plan the meetings that we needed for the group. I feel that this was time well spent, because after this there was a distinct change in how the project manager took her role in the project.

Where we are now
For each week, the project manager in the group is setting up all the necessary meetings and then leads them in a clear and efficient way, benefiting the group and the development process.
When we got this running, with the sprint plan meetings Mondays, the daily stand up meetings Tuesday to Thursday, and the sprint review in the end of the sprint (Fridays), we have followed this strictly. We believe that it is good not to do exceptions or changes now when we have just barely learned how this work, so we have followed this meeting routine every week.

Personal thoughts about Scrum
As a designer (with design as my minor that is) I have appreciated working inside the agile Scrum framework. For me, I would say this has helped me grow into my role as a lead designer in the game development team.
I guess it has helped that this way of thinking really suited me as a person – both the clear guidelines about how we can plan the project (user stories, meetings, reviews), and also the agile part, absolutely. It has been super interesting to follow the work of the team each week, from the Monday meeting where we have set the final design for the tasks for the week and then see how much code and art can be produced in a sprint. After every sprint review I have then refined the user story or stories for the next sprint.
Working this way, starting with a general understanding of how the game is supposed to be, and then letting it grow and change for each week, depending on both the performance of the team but also… I can see that I make new design decisions now in the middle of the game, because there are things in the game that I could not have seen when we started, and this will make the game better than if all the decisions were made before we started to build the game. For me as a designer to be, it has felt like freedom inside a safe box of guidelines.

 

My comment for this week kan be found at:

https://thephantommenaceisnotthatbad.wordpress.com/2018/02/22/scrum-and-user-stories-user-stories-and-scrum/comment-page-1/#comment-4

Powering up the Power up – Blog post 2: 20180215

So – this week is Alpha week – and my post will describe my reasoning concerning the detailed design of the power up.

The game that we are creating in my team is named “Aetherial” in the original concept document and the main objective for you as a player is to hunt and kill the big whale. Like a Moby Dick story in the sky you could say.

Early in this course, on the very first design meeting I called for, we designed a draft for the how the power up was supposed to work and why, together in the team. When Alpha started to really get closer, I realised that I had to make some final design decisions about the Power up, so the team could build and implement it before Alpha.

Because of this, I decided to talk this through with the team on the sprint planning for this week. As this was not only the power up itself, but also how the player would receive it, I broke down the whole scene where this happens. This is how it turned out:

1.       The whale  (the boss in the game) appears in the bottom of the screen, and you can only see its back. The whale has armor plates on its back, that can be drawn away from the whale.

2.       On one armor plate there will be a crystal, that the player has learned in the beginning of the game that she should destroy. It can only be destroyed by using the harpoon (that is one of two weapons in our game, the other one is a beem).

3.       When the player shoots the crystal with the harpoon, it breaks, and an animation of a fragmented crystal appears on the screen, above the whale. That is the power up.

4.       The player can now fly into the power up and pick it up. Then an animated power up indicator (a picture of the ship) will be revealed on the screen, telling the player that she now has a power up to use.

5.       The player now can see that the harpoon is stuck in the armor plate, and that a chain combines the harpoon with the ship. When the player flies away from the whale, the armor plate comes of the whale and reveals a weak spot under. The player can now hurt the whale with the harpoon and the whale leaves the scene.

In the real level in the game, the player will save the power up for later, but for Alpha, we let the player test it right away, so:

6.       There will be a large wave of enemies spawning on the screen, too many to handle for the player. The power up is blinking in the UI and as the player presses a key the weather changes by larges clouds cover the whole sky. The player can still see the enemies as silhouettes, but the enemies cannot see the player, so they lose track of the player and can´t hurt her for 30 seconds (the seconds will be balanced later), while you can kill them all.

 

Note that the pictures are not screen shots, I have just put together not finished concept art to make the design easier to understand. Harpoon and the small enemy is made by Isak Mansén; the ship, the whale and the crystal by Emelie Almroth, and the UI by Juste Eriksson.

This detailed explanation was what I brought to the team for discussion, and after a few adjustments we turned it into tasks for the week.

The reason why the power up scene has quite a lot going on, is because we wanted it to add something to the game. I believe this mechanic will help us achieve the aesthetics (as described in the MDA framework) that we want the player to experience when she plays our game (feeling like a champion).  As we have spoken a lot about in my minor, Design, when we have talked about user stories: we must always think of the value for the player.

 

Link to my comment for this week:

https://kassandergd.wordpress.com/2018/02/15/boss-design/

Blog post 1 – 20180208 – Using stories to guide the design process

The subject for this post: The process of breaking down a user story about a whale. The aim of this process was to create tasks for the team members to work on during sprint 3.

So – what did I do this week? As the lead designer, I led the design discussion in the sprint 3 planning meeting, Monday 20180205, with this user story working as a starting point:

……………………………………………………………………………………………………………………….

As the whale

 I want to

• make my first appearance slowly from the bottom of the screen (looking away from the ship)
• not care about the player
• spawn sky slug from crystal
• have armor plates/shields that can be removed and leave spots where I can be hurt
• have a power-up-item under armor plates that can be destroyed, and the player gains a power-up
•  leave after getting hurt the first time.

Because I want to tell the player who I am and that I will come back

………………………………………………………………………………………………………………………….

How did I do this?

Together with the team, I broke every part of the user story down into tasks. Every part of the behaviors of the whale was discussed so all team members knew how it was supposed to work in the game, and what was needed to be done to get there. When all the tasks were defined, the ScrumMaster took over and led the team in accepting and time and risk estimating the tasks.

For example: the first part of the user story is about how the whale appears in the game for the first time. The player is supposed to learn that the whale is large and dangerous and that the whale has an important role in the game. Here I first told the team my vision of when the whale appears – that it should be a slow, majestic movement of some sort, and that I wanted the whale to leave the screen in a similar way at a given point. Together we identified tasks for art, like concept art and animations for the whale. For the coders, we also identified tasks, for example for the movement.

In the same way, I broke down the rest of the user story together with the team.

The important “why”:

The user story was created the way it was to match the aesthetic goal for the game: “The player should get the feeling of being a champion as if accomplishing a very difficult task on an elite level”. The gameplay must build up a knowledge about the whale to be something interesting, something the player will have to meet several times in the game and create an expectation that it will be both a fun and a hard experience for the player. As we are working in an agile scrum framework, our product backlog consists of our user stories. In my role, I prepare one or more user stories for each sprint planning meeting, trying to make them sized for one week´s work for the team. To gain the best possible outcome of the meeting, it felt both natural and necessary to try to build a good atmosphere in the room, so all team members felt that they were an important part of the design process and in creating the tasks for the work of this week.