2018.03.18 – A SHMUP Postmortem

Over the course of the last 10 weeks, we -my team and I- have developed a game concept entitled “You May Kiss The Bride”, abbreviated as YMKTB, in the context of our second semester “Game Design 2: Game Development” module (course code:5SD064). The concept was created by a group of fellow students during our first semester’s “Game Design 1: Introduction” module (course code: 5SD065).

In this postmortem blog post, I will be going over the highlights, both good and bad, of this production and how we evolved as game developer thanks to those.

Concept summary

The Elevator pitch for the concept was:
“You May Kiss the Bride is a fast paced and aggressive shoot ’em up game wrapped in a story about commitment issues and the fear of marriage. It comes with horrifying enemies, a dark atmosphere and challenging gameplay.”

The final game – a.k.a. the Result of 8 weeks worth of development

Game Description

The final game ended up being exactly what is described in the the above mentioned concept; namely, a 2.5D top-down shoot ’em up wrapped in a narrative revolving around the societal interpretation of a “normal” marriage.

Game Narrative

YMKTB is a 1 level long shoot ’em up in which the male protagonist is fleeing from a demonic bride and her female wedding guests in order to escape from a church with the goal of being reunited with his true love (another man). The narrative being portrayed is that of a homosexual male who tries to escape the normative concept of marriage which society still considers to be one between a man and a woman.

Visual Style

To support the narrative and aesthetic goal, we opted for a darker color palette (mainly brown, black, grey, red, green). The character designs were inspired by classical demonic drawings for the same reason.

Level Design

The single level of YMKTB is split in two parts, the tutorial screen and the main game. In the tutorial screen the player gets taught the game’s mechanics (movement, shooting, reloading, pick-up and use of the power-up) via visual cues within a safe space, i.e. where there is no possibility of dying.
When crossing the safe-space’s threshold, the regular starts. The core game is made of an intensive short level, approximately 1’30”-2′ of gameplay. The intensity originates in the the short nature the level, the speed at which players blaze through the hordes of enemies and evades the environmental hazards (fire and pits), as well as the instant death looming behind the player in the form of the demonic boss monster pursuing the player.

Game mechanics

The player is constantly pushed forward without a chance of back tracking thanks to the boss monster cutting off any escape route lying behind the character and the follow camera which only moves upwards.

There is no scoring option in the game, rather the player is presented with a percentage showing how much of the level has been completed in the current run.

Limited ammunition, slower walking speed during reloading and sparse health & ammunition packs, make it impossible to run-and-gun your way through the game. The player is thus forced to consider each action with care regardless of the external pressure.
The only way for the player to catch their breath is by picking up and using the power-up, a sort of holy halo which freezes all enemies in range for a short period of time.

Enemy types

Further pressure is applied by the 3 enemy types in the game:

1. Wedding guests turned demon
   • 1 slow walking shooting type
   • 1 fast melee type
2. An invulnerable boss monster which always looms at the bottom of the screen and catches up with the player as soon as they slow down and kills them instantly if they are ever within reach.

Premise and mentality for this course

This part is not necessarily applicable to the rest of Team Hastur (my group); however these preconceptions and assumptions heavily influenced how I approached this production and will help explain some of the actions further down.

• My premise:

Given that we only had 5 minutes to chose a 3rd party concept, I went into this course assuming this was focusing on the production, rather than the development of the concept we chose. In other words, the goal was the execution of a 3rd party I.P. (concept) and not the creation of one or expansion of it.

That being said, we were informed that we could of course make changes to the game concept IF:

1. part of the concept was unclear or did not mesh well with other parts of the game; or,
2. the change was necessary for gameplay purposes.

• My mentality:

Based of my premise, the mentality with which I went into the development was oriented towards getting a finished product out of the door that was a close as possible to the original concept – that also means being very off-hands in terms of (re-)designing aspects of the game unless absolutely necessary.

Game Design

As a game designer 2 design aspect sprung to my attention:

• level design
• narrative design

The former simply took much more time than I had originally anticipated, mainly because the step between white-boxing a level and implementing all of the assets necessary to make it playable and polished was bigger than I had thought.
Another things I came to learn is the “boxes, boxes and more boxes” approach to placing obstacles. A few years back, I came across a very insightful Gamastura article where the author was mentioning that boxes are everywhere and are a level designer’s favorite tool while simultaneously being a game developer’s biggest gripe. The underlying truth of the article can be summarized as: every obstacle is just another box asset with a different coat of paint. We had some variety (benches, columns, walls, holes) but definitely not enough to make a credible environment.

Now onto narrative design… this one was a toughie – here is why. In essence, an unintended narrative perspective emerged because we had decided to cut non-essential features from the game.

Since our remaining time budget did not allow us to produce more content to re-adjust the narrative, we looked at what was still in production and could be changed/adapted in time for our deadline. The answer was the “win screen end-card”.
We decided that the only thing we could realistic do was transform the end-goal of the game from a allegory of “commitment phobia” to a societal critique of existing norms; namely: the belief that marriage can only be between a man and woman and never between two men. After getting a general green light from gay friends and online homosexual communities, we moved ahead in this direction.

Lesson 1: Plan enough time for environmental asset production.
Lesson 2: Do not leave up narrative design until the end and check with communities represented in the game to avoid a biased view – unless it is core to your narrative.

Programming

As a programmer, I became more aware of following:

• nice-to-have but complicated features need to be tested for and introduced early on or cut completely.

We were keen on implementing a 3rd party pathfinding algorithm and would have had the time (3~4 days) to implement it at the end of our project. However, since the design up until this point did not take that into consideration during development, the work required to remodel everything (level design + code base) to fit the feature carried to high a risk. We therefore decided to leave it by the way-side since the risk of breaking the project out-weighed the potential added user value. If we had spent some more time on pathfinding in pre-production, we could have planned it in and prepared the code structure for a potential implementation.

• working a modular and Object Oriented Programming (henceforth OOP) allows for a easy maintenance code.

Having reusable code requires a surplus of check to adapt to the various instances that can use it (e.g. identical health script on both enemies & player). However, this enabled us to fine-tune features in one place and have them be automatically propagate to all relevant instances regardless of game balancing. In the long run we save time and were able to indirectly add nice-to-have features to enemies without any additional work.

• the approach mentioned here above tends to go out off the window in the week before the deadline.

Modular code & an OOP approach are fantastic. When under time pressure dependencies tend to be created because they are easier to setup but this makes the code-base harder to maintain in the future. In our case we could take that liberty since the game’s internal structure will not be changing once handed in – if we had continued developing the game, some refactoring would have been required to break up these dependencies.

Lesson 3: Test nice-to-have features early in pre-production to discard or plan ahead for them in case they can be implemented.
Lesson 4: OOP is the way to go and should be held as a standard for as long as possible.

Production Pipeline

In this course we were introduced to agile game development with SCRUM. It was bumpy ride, but the lessons we learned from using SCRUM were invaluable. Rather than listing all of them again (original article), I will focus on the benefits the daily stand-ups brought:

• A better understanding of the art-pipeline.
• Reformulating scope and iterating when possible

The main advantage for me came in the form of insights gained into the process for art asset development. I have worked in creative productions before (video + photography), however the process for 2D game art is quite a bit different. Having the daily stand-ups with the whole team allowed me to understand the overall steps required to go from a sketch, to a tied-down version, over to coloring, and finally to a polished version of any given asset.

Thanks to the knowledge gained in the point above, reformulating the scope and iterating on aspects of the game became easier as I had a better understanding of how much time & effort it would require on the artists’ side to make/create/re-do an asset.

Lesson 5: Being aware of what is/can be done in other departments helps adjust the scope of the project on the fly to make sure the final deadline can be hit – even if that means killing your metaphorical darlings (i.e. favorite game concepts).
Lesson 6: Understanding the other departments’ workflow does not require you to understand the technical aspects of it.

Group dynamics

Game development requires the combination and collaboration of many different disciplines, people and mentalities. Therefore the importance of internal dynamics of a project group cannot be understated. Team Hastur grew and evolved over the course of these last 6 months and I will try to summarize said evolution in a few points.

• Just like in any social construct up and downs are unavoidable. Using non-violent communication helps you speak your mind and create an environment where everyone else is comfortable of doing so. This in turn generally allows prevent and sort-out potential blow-outs before they happen.
• Constructive criticism is necessary part of all creative endeavors. It is important to keep the end-user/player in mind when delivering the criticism as we are not usually not the target audience. Furthermore we need to be able to separate ourselves from the product as to not take the criticism personally. (One of the most difficult aspects of creative production in my opinion).
• Taking a Systematizing the Person-Group Relation (a.k.a. SPGR) test, like we did, can be beneficial for the group in its entirety if everybody wants to improve the group dynamic. If that is not the case, then the results can harden the existing frontiers and create a schism – thus only alienating team members even further.

Lesson 7: Working on a project requires all team-members to move towards a certain goal together as one entity. This means trusting in each others ability and good working relationships but does not necessitate friendship – even though it would be preferable.
Lesson 8: Taking and giving constructive criticism rather than a simple opinion is key to iterating on an idea/game concept.
Lesson 9: Activities that are meant for team-building can backfire.

TL;DR:

Lesson 1: Plan enough time for environmental asset production.
Lesson 2: Do not leave up narrative design until the end and check with communities represented in the game to avoid a biased view – unless it is core to your narrative.
Lesson 3: Test nice-to-have features early in pre-production to discard or plan ahead for them in case they can be implemented.
Lesson 4: OOP is the way to go and should be held as a standard for as long as possible.
Lesson 5: Being aware of what is/can be done in other departments helps adjust the scope of the project on the fly to make sure the final deadline can be hit – even if that means killing your metaphorical darlings (i.e. favorite game concepts).
Lesson 6: Understanding the other departments’ workflow does not require you to understand the technical aspects of it.
Lesson 7: Working on a project requires all team-members to move towards a certain goal together as one entity. This means trusting in each others ability and good working relationships but does not necessitate friendship – even though it would be preferable.
Lesson 8: Taking and giving constructive criticism rather than a simple opinion is key to iterating on an idea/game concept.
Lesson 9: Activities that are meant for team-building can backfire.

The development of this game has enabled me to grow both professionally and personally, thus giving me the confidence to tackle greater and bigger challenges in the field. Next step: the “Arcade Game” course!

About Timothée Engel

2017 Programming

View all posts by Timothée Engel →