Postmortem

This assignment have been a ride, both with its highs and lows. There has been struggles and disagreements, but also a lot of learning and growth. The final product is a mix between all I envisioned and a complete surprise.

Looking back, we were terribly unstructured in the beginning. No one understood what the backlog was and how we were supposed to be doing it. Not to mention how I struggled with the user stories for a while there too. Luckily we managed to wing it until everything settled and we actually understood how we were supposed to document everything.

The team worked well together, however, personally I feel like we could have done even better and I think that is my fault. While everyone else were decent in their fields, I didn’t really understand my role in everything until the very end of the project. Had I understood how my job was to make sure that everything was supposed to have a reason, how everything was supposed to be connected and designed to enhance the players experience as much as possible, then I think I could have been a better asset to the team. Just goes to show how I’ve still got a long was to go.

While our gameplay was pretty smooth, I feel like we could have worked on our aesthetic some more. The gameplay aesthetic was “feeling like a champion”, the visual aesthetic was pirates and beauty (??) and the sound aesthetic was a mix of both. While we did make a moodboard and pulled in some example art so we could get a feeling for what the visual aesthetic we were going for, I still feel like it was a bit to undefined and ended up a bit all over the place. The gameplay aesthetic was barely reflected in the players actions at all and was definitely not worked on enough. Not to mention the fact that we barely even had a targeted audience. Maybe that was why we didn’t work so much with the gameplay aesthetic?

In the end it all worked our, but I have my own personal notes about how we went about htins project and how I wish to do this in the future. Let’s just hope I can put them to good use.

Thanks for reading!
Lots of Love

//Maya

Comment #5

Comments On Others Blogs

Original post here: https://msmonoxide.wordpress.com/2018/03/08/playtesting/

This was a very nice and organized blog post. You started by very clearly stating Why playtesting is important, then you explained (in rough terms) how your group carried it out, your result (with both the positive and negative feedback) and lastly your thoughts on these results. It is seldom you see these really neat and professionally typed posts 😊 kudos!

If I had to mention anything to make this better, it would probably be that it’s kind of excluding of people who don’t already understand playtesting and games. Things like not mentioning what a ‘playtest’ is at the beginning, means you assume that whoever is reading already knows how these procedures work. However, considering who your intended audience is, it’s not a bad assumption to make.

I loved your post, it’s nice to see people who cares a little about the paperwork.

Best of luck!
//Maya

Level Design

Level Design – A Design Decision

So! The biggest puzzle pieces were set. We knew the goals and “feel” of the game, we knew how the player character was supposed to act and move, we knew the rough outline of the challenges we wanted the player to face and we knew how long we wanted the game to be. With these aspects in mind it was time to design the levels.

Starting off, I mentally separated the game into three faces. The Tutorial – A very short part, meant only to teach the player the base mechanics in a safe environment. The Adventure – The very meat of the game, where the player learns how to use their new powers. The Boss – The biggest challenge. The grand finale where all that the player has learned up until now would be put to the test.

In this post I will only describe The Adventure part, seeing as that was the big problem. It was supposed to be the longest part and -while being entertaining- its sole purpose was to teach the player the different moves, obstacles, and how to best combine these. I ended up creating 13 “waves” of enemies, all with a different purpose behind them. To either teach the player something or prepare them for what was to come. Some examples from the list looks like this:

• Wave 1: Introduce one Enemy 1
  • (first contact with enemies, keeping it simple)
• Wave 3: First real trial with about six E1’s
  • (shows a glimpse of what is to come)
• Wave 4: Introduces one Enemy 2 with two E1’s in the back
  • (to indicate that it’s no big deal)
• Wave 5: Same enemies as in the last one but lined up
  • (to inspire the player to use their Secondary fire)
• Wave 9: A wall of E1’s and an Enemy 3 behind them
  • (as the last test for the warm up)
• Wave 10: Just one E2
  • (to let the player catch their breath and process all that happened while still engaging in the game)

(I could make pictures for ya’ll so you could more easily understand what I’m talkin’ about, but that sounds like a lot of work and I’m not being paid for this. Please imagine pictures if you will).

What’s important is that with this, all the players abilities are challenges tested. A lot of possible waves were created that never made it into the game, seeing how it was important to me to only keeping the parts I found most necessary for either pacing or tutorial reasons (so nothing would feel like filler or just a waste of time).

Lesson to be learned out of all of this? Having a reason behind you design, no matter how small, brings the design to life and makes it so much more fun when it works!

Lots of Love ❤
// Maya

Scrum

Scrum – Working Method

Working in a team -especially one that is creating something from nothing- is not an easy task and it’s very important to have a set frame for the working process to make sure that all goes as smoothly as possible. We are currently working in the agile method Scrum. A process where every step of the way is surveyed, tested and prioritized.

The basic idea goes like this; the overall goal is set early on and broken down into pieces, these pieces are then prioritized, broken further down into tasks and worked on in sprints. A sprint is a set time frame where the only goal is to finish one piece, once the sprint is over the work that has been done is reviewed and tested. Next sprint, the next piece is worked on, and so and so forth. A sprint is usually around 2 weeks, this way if something goes wrong, or a feature does not live up to expectations, it will be obvious very quickly and can thusly be dealt with before it becomes a bigger issue down the line.

As a team with an extremely short deadline to fulfill, we decided to make each sprint only one week long and have daily stand up meetings to make sure that nothing problematic goes undetected for long. So far it has been extremely beneficial for us. Communication has been going smoother once we started talking about our progress every day, and reviewing the weeks work every Friday has painted a clear picture of the projects progression (which has assisted in the weekly prioritization as well).

However, as with all good thing there are also downsides. Having the entire team involved with the process every step of the way has proven to create a lot of arguments and disagreements. This lead to the preparation stage (before the actual work began) becoming far longer then necessary. Not to mention that a lot of the prioritization is hard to carry out for a team of inexperienced game designers as ourselves. But even so, it is my belief that both these issues will be solved with more experience in the field, and with all these frequent meetings and reviews, I believe we are heading the right way.

Lots of Love
// Maya

 

Boss

Boss – A Design process

This week I have taken a first stab at designing the boss for our game. As I’ve mentioned in earlier posts, the boss is of very high importance to our game. Everything before you face it is simply practice, the boss itself is the main course.

So, in hopes of gaining some understanding into what makes an enjoyable boss fight for a shoot ‘em up game, I have analyzed some boss fights from different kinds of games. My focus was on Cuphead (2018), a shoot ‘em up game famous for its great design and interesting bosses. But I’ve also spent some time looking at Floot, Touhou, Sly 2 and others like them. I found a lot of interesting designs and decisions, however what stuck with me the most was a common formula that seemed to appear in a lot of the fights. The core was that the boss had 3 stages and then 3 different attacks in every stage. Naturally this formula is slightly modified in every instance to suit the game as necessary, but it was a perfect base for me to work with.

When designing the actual attacks, I started by imagining the scene for the player. Seeing as I needed to know; the players position, the bosses position, the bosses attack and the bosses’ weak points I felt it necessary to go back and look from the players perspective. What would the player actually want to face? Based of the training so far, what kind of scenarios would be fun and challenging for them? So, I wrote down all the actions the player could take and numbered them, like this;

1. Primary fire
2. Secondary fire
3. Teleportation ability
4. Movement

I then started combining numbers to see if I could set an interesting scene with them. Like this;

1 + 2
(Primary Fire + Secondary Fire)
The primary fire is good against a lot of small targets and the secondary is good against singular but strong targets, so send in a couple of small and easy enemies and have the boss show one big weakness. With this the player will naturally want to use the secondary fire against the boss but won’t be able to do so continuously since they will occasionally have to switch to defending themselves against the smaller enemies.

Like this I combined the players different abilities and actions to create as many scenarios as I felt necessary. After that I picked the 9 scenarios I liked the best and sorted them in such a way that I felt like it would follow the earlier mentioned “boss pattern”.

This was the result:

Stage 1: (1+4)(2+1)(1+2)
Stage 2: (2+3)(1+3)(2+4)
Stage 3: (2)(3+1)(1+2+3)

As the reader this probably doesn’t tell you much, but that right there is the first draft for my boss design. Next up, testing it.

Lots of Love
//Maya

 

Playtesting

Playtesting – A Method of Reflection

This week we have been executing a playtest with our fellow peers in the Game Design course in hopes of getting an outside perspective on our game. As we now have an Alpha build, we wanted some insight into the controls and the user friendliness of it.

Our method was simple. We set out a computer running our game, we had one person documenting the behaviors the witnessed from the player and one person asking them questions afterwards. The analyzer looked after the following signs;

• Were they frustrated by anything?
• Were they bored by anything?
• Did they grasp the controls naturally?

And anything other behavior that stood out too them. The questions asked afterwards were in the same spirit. With the added question of;

• Did you enjoy the dash mechanic?

Seeing as that was a part of the game we were uncertain about, we used this opportunity to get some new thoughts on the subject.

Note: The testers themselves were 8 females and 18 males, with the age-span of 19-30, all university students studying game design.

The results were later collected and analyzed, and we noticed a pattern in their frustration. Three things kept coming back as the major negative feedbacks;

• They struggled a bit with heavier enemies (especially the second one).
• Some didn’t grasp the concept of Aether and therefore couldn’t utilize the Aether abilities.
• Most didn’t initially understand that the powerup was a good thing and not an enemy.
• Almost no one used the dash.

Because we could now see some blatant flaws in our game, we discussed what might be the cause of these problems and how we could fix it. Since every point took a good deal of work to fix -and that means a lot of text to write- I will not reveal our conclusions today. And I suppose they do not matter right now anyway. What matters is that our playtest was successful. We got some very important information from it and I can say with confidence that the game is better now because of it. Method recommended 😊

Lots of Love
// Maya

Enemy Types

Enemy types – A design decision

Our game is fairly short and simple. The concept is that, as the player, you are supposed to kill a few enemies and then a boss to win the game. As such, we decided to use the enemies as “training practice” and make the boss the main event.

The player character has four features; movement and three kinds of attack. To help train the player in every attack, we created three different kinds of enemies. All were designed with a weakness to one of the attacks and a strength against the others. So Enemy 1 was weak to Attack 1 but neutral to Attack 2 and 3, while Enemy 2 was weak to Attack 2 but neutral against Attack 1 and 3, etc. This was to motivate the player to use all their different attacks without flat out forcing them.

For example: Attack 1 is a long-range attack meant to portray a harpoon. As such, it fires at a slow-to-mid speed and cannot take out more than one enemy at a time. Seeing as the gun is quite slow, it forces the player to make every bullet count and aim every shot. We interoperated the optimal type of enemy for this kind of attack to be one that takes only one shot to kill, but multiple enemies will arrive simultaneously and at different locations on the screen. Forcing the player to slow down and aim every bullet instead of shooting erratically. Using Attack 2 or 3 on this enemy will still kill it, however neither of these attacks can aim, which forces the player to move around to get all the enemies placed throughout and thus wasting valuable resources and time. So, while it would be possible, it is not as convenient. This motivating the player to use the attack we want them to use.

With all enemies designed in this fashion, the player would be fully trained in all the available options before facing the boss.

(Extra! My thoughts on the fact that there is a word count for school assignments is that, in itself, it not a bad thing! however, not even looking at a students assignment because they had 20 words to few feels a little extreme to me.)

Lots of love
// Maya