Boss Design Review | Gohdan from LoZ: WindWaker (Spoilers)

I have recently been watching my fiancée play through The Legend of Zelda: The WindWaker on the Wii U; a game I have played through the GameCube version several times and loved. Today she tackled the Tower of the Gods, and the accompanying boss encountered, Gohdan. Now, Gohdan isn't going to get the Boss of the Year award, but it does have very cohesive mechanics and theme, which I personally find fascinating.

Image source: zelda.wikia.com

Mechanics & Theme:

Gohdan is a mechanical implement stationed to test the worthiness of any challenger for the power of the Master Sword. It's not some foul beast the hero needs to slay. Gohdan isn't programmed to murder, it doesn't need to be destroyed. It is a test!

Mechanically, it does very little damage, and requires the use of some of the techniques learned from its dungeon. Chiefly among these being shooting moving targets with arrows, and throwing bombs into mouths to destroy enemies (such as the Armos Knights enemies). Once again, the test theme comes up.

The fight itself is shoot arrows at the eyes on the hands to deactivate them, shoot arrows into the eyes on the head to deactivate it, then place a bomb into the head's mouth. Rinse repeat. This seems simple enough, but the complexity lies in dodging the multitude of attacks, hitting the targets as they move, and deactivating the hands within a specific window of time, or they will become active again. Gohdan doesn't require the player to overpower it, it requires the player to have the skill and the timing to execute on what they learned. 

Image source: www.zeldadungeon.net

My favorite part of this fight is what happens when you run out of Arrows or Bombs. Most boss fights have jars laying around the exterior of the room to allow refills. Not this fight. Gohdan sneezes out some ammo for you when you run out! How nice! Unfortunately for the player, it will also reactivate one of its hands every time you run out of ammo. This will push the player to make good, accurate use of the 10 arrows presented to the player, before you run out again. This helps emphasize that this machine isn't trying to kill you. It is simply providing you with the opportunity to prove yourself.

To wrap everything up, when you defeat Gohdan, it does not explore. It does not fall apart. Gohdan simply returns to the fixtures in the wall from which it came. You passed the test, and it has completed its programming.

Image source: www.zeldadungeon.net

End Note:

As I stated earlier, Gohdan isn't going to win Boss of the Year. Never-the-less, this fight has still stuck out as one of my favorites in WindWaker for these many years, and now I know why. It just goes to show that cohesiveness of the mechanics and theme can help make an immersive and memorable experience. That is something that I strive to emulate in my own work: Cohesiveness, and creating a memorable experience.

Swords, Shields, & Sorcery | Creative Brief on Matchmaking

Objective: 

Provide a quick, accessible matchmaking system that keeps players actively engaged in multiplayer and single player.

Experience:

·         Toggle Matchmaking on to show others you're ready for a fight.

·         Bump into real-life opponents as you continue on your journey.

·         Take down challengers for currency, rewards and prestige!

Vision:

·         Easy to start and stop matchmaking.

·         Minimal data transferred to prevent excessive data usage on mobile.

·         Snappy access to basic Player vs. Player matches.

·         Clear information presented with minimal UI.

Anti-Vision:

·         Long waits in queues and menus for matchmaking partners.

·         Excessive screen flow between the initial menu selection and gameplay.

·         Custom parameters to set-up specific match types.

Details:

Matchmaking Toggle

·         Toggle matchmaking on and off with a single button.

o  Matchmaking button is clearly surfaced in the main player interface.

o  Toggling matchmaking on will attempt to connect to the server.

§ If no connection can be made, an error message is displayed.

·         Player visually update based on matchmaking state.

o   When matchmaking, the player's character appears battle ready.

o   A Player vs. Player banner is placed behind the player character.

o   An unobtrusive notification message should also be displayed on screen after toggle, then fades out.

§  eg. "Searching for challengers!" and "Avoiding challengers."

Search Criteria

·    All players are subject to the same search criteria.

·    Search checks for players of the same level first.

·    If a player of the same level is not found, the search checks for players one level lower, then one level higher.

o   This process should repeat until all levels have been searched through, then restart the matchmaking process until a match has been found.

·    Players should not be matched with the same person repeatedly.

o   Players that have recently fought each other are not matched together for a short duration (~5m).

o   This should provide more matchmaking variety and prevent potential griefing.

o   If there are no other players online, this rule will be ignored.

·    Searching is halted when already in a match, or a single player fight.

o   Searching resumes as soon as combat has concluded.

·    Once an appropriate match has been found, both players are notified with an Accept/Decline Notification.

o   If a player declines, the other is notified. Both players return to matchmaking.

o   If a player does not accept within a certain time limit, they automatically decline.

o   If both players accept, a fight will start.

Matchmaking Flow

·    Matchmaking Flow Chart:

Disconnections

·    Players who disconnect from the server will have matchmaking toggled off.

o   An appropriate error message will be displayed.

·    Disconnecting when a match has been found but not accepted will automatically decline it.

o   Like above, an appropriate error message will be displayed.

·    Disconnecting in the middle of a match will result in a loss for the disconnected player.

o   An appropriate error message will be displayed outlining the loss to the disconnected player.

o   The player who has not disconnected will win the match.

o   Match win/lose data will be discarded for situations where both players disconnect during the match (eg. Server down).

Other Considerations:

·    Desyncs and Lag

·    Countdowns

·    Leaderboard Statistics

·    Rewards

·    Transitioning to a match from various screens

© Scott Balmer - Game Design - 2014

Blob Platformer | Creative Brief on Player Mechanics

Objective:

Provide a simple, yet compelling gameplay experience for traveling through a world, that is easy to pick up and learn.

Experience:

·         The fun begins as the player launches around the game world with a single touch of the screen.

·         Quickly discover and feel rewarded with new ways to interact with different surfaces in the world.

·         Feel relaxed while exploring and collecting food.

·         Witness your progression through player size increases.

Vision:

·         Simple, accurate controls.

·         It's easy to play well.

·         Enough variety to keep the player interested.

·         No pressure from timer count-downs.

Reference - Angry Birds (Mobile/PC/etc) - Simple, one-touch control. Launch where you expect to be launched.

(Image Source: blog.mrmeyer.com)

Reference - Tales from Space: Mutant Blobs Attack (Vita/PC) - Blob changes scale based on consumed food. Uses physics based mechanics.

(Image source: Drinkbox Studios)

Anti-Vision:

·         Control style or mechanics that take practice and patience to master.

·         Multiple types of input that determine what the player is doing on screen.

·         Energy/health meters, timers, and other resources to manage.

Gish (PC) - Tricky platforming, takes a while to get used to the controls. 

(Image source: www.fun-motion.com)

Super Metroid (SNES) - Tight controls, but some are very difficult to master. Multiple 'abilities' to equip and use.

(Image source: Wikipedia)

Details:

Slingshot-style locomotion

·         Touch the screen and the blob will jump.

o   Touch and drag to 'pull' back and get more launching power.

o   Direction and distance movement accurately represents the player's expectation.

o   Plenty of visual and audio feedback to show the outcome of movement

o   Blob color changes slightly when aiming in the direction of objectives. Prevent the need for maps and UI.

·         Direction arc displayed to show initial course

Physics based environment

·         Blob will roll down surfaces as expected in real life.

·         Larger blob will gain more momentum/speed

·         Other objects in the game world can take part in world physics as expected.

o   eg. large rock rolling down a hill

o   eg. Knock down a piece of fruit normally out of reach.

Growth

·         Eating food increases blob size

o   The larger the blob, the larger the food it can consume.

o   Larger blobs can jump higher and can interface with surfaces in slightly different ways than smaller blobs (large blobs can float on fluids, where smaller blobs will sink).

·         Levels visibly scale to the perceived growth of the blob

o   eg. level 1 is from the view of an ant

o   eg. level 15 is from the view of a small bird

o   eg. level 30 is from the view of a bear

o   Player can complete each level with a minimal amount of food, but will need to collect them all to access all areas of the game.

o   Collecting more food than the minimum allows the player to access further areas of the game earlier, if desired.

o   Camera adapts to blob growth.

·         Can split to become smaller, in order to fit through smaller areas

o   Splitting reduces size by half, and leaves a 1/2 size empty blob behind.

o   Player can re-collect discarded blobs to grow bigger again.

Surfaces

·         Blob can interact with different surfaces in different ways. Examples:

§  Sticky surfaces slow movement, and allow for wall jumping.

§  Rubber surfaces allow the blob to ricochet off.

§  Weak surfaces can be broken through, depending on blob size.

§  Colored barriers can be passed through when the blob is of the same color

§  Liquid surfaces can be floated on with a larger size blob.

§  Slick surfaces can be slid on to maintain, or increase momentum.

§  Molten surfaces harden the blob, allowing it to roll instead of jump.

§  Fluffy surfaces add fluff to the blob, which will allow it to float on breezes.

Damage

·         Being hit by threats and hazards splits the blob in half (similar to splitting)

·         Must re-collect blob bits to get larger again

·         Blob recollection should ALWAYS be possible, and never prevent a player from continuing

·         The player will never die.

© Scott Balmer - Game Design - 2014

About This Blog, And The Man Who Writes It:

A fine welcome to all those who should happen to wander to this little slice of the internet.

My name is Scott Balmer, an aspiring video game designer from Vancouver, Canada. I have spent the past 6 years working in Quality Assurance and Development Support for a few of the larger Video Game outfits here in B.C., working hard, learning and studying fiercely. In that time, I have discovered that knowledge can be of little consequence without having the field experience to back it up. 

This blog is dedicated to the design documentation and prototypes I hope to use to prove out that I have not only the knowledge, but also the skills required to be a professional video game designer in this simultaneously vast and minuscule industry of ours. Be it through future employment, or self publishing, I am determined to share my thoughts, feelings, fears, hopes and dreams through game design.

This is my dream. This is my story. This is my craft.