Design Feedback – 6

Congratulations to your finished game. I did play it several times during the different play testing sessions and you could clearly see a progression from alpha to the finished product. I like how you took some answers from the latest playtesting and posted it in here, it gives you a feel from what people thought of the released version of the game.
I would have liked to know even more about your group’s dynamic. How you worked together, what were the ups and downs of the project? What did you think the most important thing you learned as a game designer?

Great job on the level design. It was a great flow from the very start to the finish. I also did question the story, or who the protagonist really was? Am I evil or not? I think it added some mystery to the overall aesthetic of the game. It was a nice touch.

Good job!

Design Blog – 6

Postmortem

Final Playtest
Yesterday, thursday, was our final playtest. We presented our released version to the testers. We all worked our butts off the day before and the morning before the testing. Making sure there weren’t any bugs or overall fixes that needed to be done. It was a stressful period but I’d say we pulled through, much thanks to our coders that put in so much energy and effort to this project. The testers generally liked our final product. It was feeling of relief when everything was said and done after the days testing. Looking at the survey we got a lot of praises and that always feels good.

The End Result
Everything we had in our backlog we managed to implement in the game. We had a in-game ‘tutorial’, two normal levels, two repair phases and a final boss level. The Behemoth (the player), had a laser cannon with two different shots, light and heavy. Four protective shields that would deflect incoming shots or crashing drones. A shockwave, which is the power-up, blasts the enitre screen and obliviate all visible enemies.

The three types of enemies were introduced one at the time during gameplay. The weakest first, the drone, then the shooter and last the spawner. All the enemies had different styles in terms of size and features. The drone, the smallest, would move in a slalom pattern and try to crash into the player. The shooter, comes in at a medium distance from the player and shoot projectiles. The spawner, comes in and spawn multiple drones from its ship. It has more life than the average enemy and the player had to take it out as soon as possible in order to not to be overwhelmed by enemies.

The repair phases did its job aswell. After you complete a normal level you get the chance to restore some health. The player enters a number of key inputs that are shown at the screen and the health restores. Whenever it is successful the next level begins.

I think the levels rose in difficulty in a good way. The only thing I would have changed is the first minute of gameplay. The enemies spawned too slow and to some players it was at the brink of tedious. After the first drones I would have increased the number of enemies spawned much earlier than I did.

We did manage to finish a game. We covered all the levels, the different menus, win and lose condition, music, sound effects. Everything was there.

Image: Screenshot from the start screen.

What have I learned
Looking back what I have learned from all this it is a whole lot. The one thing that is major is the communication to the player. You have to be absolutely clear what you are telling the player. Everything from how the controls work to a feedback from a sound effect. Everything has to be right and precise. As a designer you can never be too overbearing in teaching the player the game, at least not from what I have learned from this project.
I was head of level design and it was a fun experience. I really tried to put myself in a first-time-player’s shoes and build the levels progressively harder and at the same time learning the player all the different aspects of the game. What I am most proud in this was the boss level, or as many people called it, “the night level”. I worked closely with our lead coder and I send him images I made in Photoshop to display how I wanted the different formations of enemies to spawn. This made it look really exciting and it was to many, aesthetically pleasing to play. The last section of the boss level were the “shield level”. This was something I came up with to alter our gameplay and really test the player. The cannon malfunctions and fast-moving Drones attacking your Behemoth. The player has to activate the shields in a fast-paced manner to destroy the small annoying enemy ships. This made the game very challenging and it was a high peak for sure.
I also learned to stand up for myself, probably that is the most important lesson here. That my opinion and my ideas really matter to our group. That I have a certain set of skills that I can apply to our product. I have to pitch it and really sell it to our group. The more time I spend with the group the more, in my mind, they come to the conclusion that I had more experience and knowledge about design cause of my minor. That felt good.

All in all
This was a great experience and something that I’m proud of. My very first real game. I’m humbled and I couldn’t have done it without my very competent group. I look forward to new challenges and to learn more about design and everything that comes with it.

Game Designer
Joakim Malmström

Design Feedback – 5

I like this blog post for several reasons. The main reason is how open you are with the game’s state and your role as a scrum master/product owner. That you can look at yourself and critique is a very crucial thing to do in order to learn. We all struggle, sometimes more, sometimes less. I think you will benefit from this and take this experience and make something valuable out of it.

It is never a good feeling when you know you can make a better game or as you said, you know the problems that exists with it. You want to really stress that to the testers that you are really aware of it. This is why we are here though. So that we can fail and pick us up again and learn from it. It is “only” a school project and you can afford to have some setbacks.

There is still one week left and you can still improve the game and the groups dynamic. There is always something that can be done, it doesn’t need to be a big scale kind of thing.
Good luck.

Design Blog – 5

Playtesting

First Playtest
Our first playtest went I guess kind of well. Something that we noticed was that testers did not use the ‘heavy’ shot. The heavy shot or the laser needs to be loaded up for four seconds before it fires. Testers found it confusing and did not see (nor hear because we did not have any sound effects at the time) when the cannon was charging up the laser. This was the main issue from the playtest. This is something we changed for the upcoming sprints. We changed the looks of the cannon and added a sound effect when you are loading up the cannon for a heavy shot.

Second Playtest
There was a significant improvement from the first playtest. This time around we had mostly all sound effects implemented and they were very much welcome by the testers. Overall the testers appreciated the game.
Something that we have struggled with is the background and the controls of the game. First off, the background, the enemies blends in all to much and it is making it hard to see them at first glance. Since our game is heavily relayed on tactical decisions it is crucial that the players can spot an enemy ship as fast as possible. The enemies are gray and the background is gray.
The second factor is the controls. Some testers had a hard time learning all the controls, we had a quick tutorial with text but a majority did not read it. We changed the controls for the shields from H-J-K-L to 1-2-3-4 which was more intuitive for the testers this time around.
One last thing, the power-up. The Shockwave, as its called, were the thing people gave the poorest review. Why? Because we forgot to tell them about the key input for it. The testers did not even know how to use it or it was fully charged.

How did this benefit our development?
We have had the luxery to polish the game since we have a very capable team that has done its job right. When the feedback came back from the playtest we imidediately thought of design that would improve our game. When you, as a designer from my point of view, test your game over and over it is hard to sometimes get the perspective of a player that sits down and plays your game for the first time. You really need to be super clear about the gameplay and it has been challenging at times but it is something that I really enjoy. Finding solutions to problems and teaching the player and see the learning curve display right in front of your eyes. Without the playtesting we would not have this good of a product that we have right now. I’m very pleased with the game and it is a real joy to always improving it.

Image: The old cannon (up) and the new cannon (down)

Joakim Malmström
Game Design Student

Design Feedback – 4

You are describing well your thought-process behind the music for the game. It amazes me how accurate and detailed your decisions were behind all of this. In a very clear manner you describe the background to your game and how other cultural influences your music for your boss level. I’ve listened to the track multiple times and I can really get the feel for the Umibozu aesthetic. It is very spooky and it adds something extra when playing a mysterious game such as yours. The dark waters, the only light source comes from the boat. It all adds up.

I have nothing really to complain about. I like how you posted the movie soundtracks that inspired your games’ music. It was all easy to follow and understand how you came to the conclusion that is the music you created. I
genuinely loved the dissonance in the tones that created that spooky vibe. A real solid work well done!

Design Feedback – 2

I feel you have in a clear manner explained the design decisions behind the new power-up. I did test your game and was not entirely clear what the power-up was and how I was affected by it. The new one seems very interesting indeed. Two things I would like to adress it how you are going to communicate to the player that it you should press down either ALT or CTRL for the different power-up. Since the given aesthetic is a feeling of belonging, I in my personal opinion would just keep the one power-up where you gather your bee’s and all of them shoots with you (Honeycumb formation, CTRL-Key).
The other power-up seem a little unnecessary and I’m not sure why this would be better to have increased fire rate yourself than lots of bee’s firing with you.

I would also recommened a picture for the blog post. How the formation looks in-game or how the power-up drop looks like. All in all, I think you got a great game ahead of you and I really like the new ideas.

Design Feedback – 3

You write in a clear and understanding way. Even though it is hard to get an image of “scrum” per se, it would have been something that would make the blog post more attractive. I get the general idea of scrum when reading your post and what it has done for the team overall. I would have liked to know more what in depth, what you put in the backlog and how it affected your work. Did you have to add anything and if so what?

How is the review going for your group? How is your work affected by working in a scrum method? I would also want to know how your part in the team is. Do you use User Stories or do you have a good communication between the team’s members on how you want your game to feel/be?

All in all, I get an overview of what scrum is and what it means to your team. A more detailed version would be something that would improve the post. Good work nonetheless.

Design Feedback – 1

I feel that the blog for this week is very direct on its subject. To break down a character and its features with User Stories. It shows that you have thought carefully about the design behind the whale and then taking it to your team to discuss it ever further. You address it as a team effort and it is vital to use User Stories, in order to break down and question the different aspects of the whale. I definitely like how you structured the blog with the User Story and it is making it easier to understand your thoughts behind it in the upcoming headings.

Although, I’m having a hard time understanding who this whale actually is. Is it a boss, an ordinary enemy or something else? By looking at the stories my guess would be that it is some kind of a boss but I’m not entierly sure.
I would also appreciate an image of the whale. In that way I could grasp how your stories resulted the art work behind it.

Design Blog – 4

Drones

The very first enemy
The Drone is the first enemy the player encounter. It has low health and cannot shoot. In the concept document it was called “Kamikaze”, which by indicated by its name flew into the Behemoth to deal damage. The Drone in our game does this aswell. It moves towards the Behemoth to crash into it but we changed the name cause a “Drone” sounds and it is easier to pronounce.

Stats for the Drone
In the design document I’ve made some basic stats for the Drone.

Speed – 3 (High)
Mobility – 3 (High)
Intelligence – 1 (Low)
Hit Points – 1 (Low)

The Drone has the highest speed of all enemies and can move in different patterns. The weakness is the low health and it is fairly easy to hit.

Gif: The Drone with animation

Level Design
As I stated earlier the Drone is the first enemy to appear on the screen. We want the player to have a real easy challenge at first and to really master the controls. A single Drone spawns and the player has a lot of time to destroy it. When the level progresses the Drones are increasing in numbers and have different formations. Instead of coming one by one they have a “three-pattern-spawn”. Either it’s three in a straight line or three in a triangular form. This could make the player use the heavy shot in order to kill them all off with one single shot.

The Drones can be destroyed by the cannon’s fire but can also be eliminated by the Behemoth’s shields. When a Drone hits an activated shield a blue explosion animation appears and communicating to the player that they have successfully dealt with a Drone with the shield.

Boss Fight
Since there was no Boss Fight per se in the concept document we had to do our own interpretation of it. One idea I had and we will soon try it out is that when the Boss encounter starts the cannon of the Behemoth malfunctions and you can only use your shields. When only the shields are the primairly function you can only defend yourself against Drones. Massive ammount of Drones, which is also faster now, comes at you and you have to tactically use your shields to destroy them.
More on the boss, phase is almost the better word for it comes later on. The one segment with the shield versus Drones are very exciting to me. It is the first enemy and it can still be interesting to the player to face them in a new kind of way.

Joakim Malmström
Game Design Student

 

Design Blog – 3

Scrum

Introduction
I feel the development of our game has been mostly positive for our group. Every time we make a sprint, we get together and discuss what we will be working on for the upcoming week. If there’s some downside with planning our sprints it’s just too short. A week goes by so fast and the tasks we work on would sometimes need more adjustments and iterations. The same task can be worked on the next sprint and in some cases an additional sprint after that.

Though our product backlog is at the moment a mess but we do have a good communication between us and there is rarely any confussion what needs to be done. A great team needs great communication and I do believe that we have that. It would be for sure more helpful if we did have a better structure on our different backlogs.

Daily Meetings
It’s hard for us to meet at the same time. We’ve tried to have it over Discord and it worked some of the times but it is not the best option. We’ve tried having it a set time but the lecture differs so much and we all have different schedules in the afternoon. When we are not meeting on Discord to talk our Project Manager do have to remind us to at least write in the Discord channel what we’ve done and worked on for that day.

Scrum Review
The review is the thing that has been the most positive outcome for the scrum setting. We all know what has been done and we get a clearer vision on what to work on next sprint. The meeting is truly effective and it is mostly positive things that have come out of it.


Image: Sprint planning in the making

Summary
The scrum setting does work for us. It’s not optimal at all times, for the previous examples I gave and we’ve had some sickness in our group. When people are sick the amount of assets we can produce in a sprint greatly decreases. Then we have to make it up for the next week. Something that is good with scrum is that we all know what tasks that needs to be done and it sets a pressure on delievering it on time.

Joakim Malmström
Game Design Student