Game Design Part III: The Mechanic

In part II of my series on game design, LINK HERE, I spoke at length about the importance of story. In this next part, I am going to talk about the game mechanic. But first I need to cover some history.

Classic video game mechanics have evolved over the years, influenced by groundbreaking titles that introduced new concepts or refined existing ones. Here are some examples of classic video game mechanics and the groundbreaking games that represented them:

• Platforming: Platforming involves controlling a character to navigate through levels by jumping between platforms and avoiding obstacles. Super Mario Bros
• Puzzle-solving: Puzzle-solving mechanics challenge players to solve various puzzles or riddles to progress through the game. Tetris
• Role-playing elements: Role-playing games (RPGs) typically feature character progression, exploration, and story-driven gameplay. Final Fantasy
• First-person shooting: First-person shooters (FPS) put players in the perspective of the protagonist, emphasizing shooting and combat mechanics. Doom
• Real-time strategy: Real-time strategy (RTS) games require players to manage resources, build bases, and command units in real-time battles. Dune II: The Building of a Dynasty
• Stealth: Stealth games challenge players to avoid detection by enemies, often requiring patience, observation, and careful planning. Metal Gear
• Open-world exploration: Open-world games offer players vast, interconnected game worlds to explore freely, often with non-linear gameplay and side quests. The Legend of Zelda

What is a game mechanic?

The textbook definition of a game mechanic is:

A video game mechanic is a fundamental component or system that governs how players interact with the game world. It's essentially a rule or a set of rules that defines how the game operates and how players can interact with it. Mechanics can include things like movement controls, combat systems, resource management, puzzles, and more. They shape the overall experience and gameplay dynamics, often defining the unique characteristics of a game and contributing to its enjoyment and depth.

Designing a Mechanic

These days it is becoming more and more difficult to design a brand new mechanic that nobody has seen before. More often than not we have to settle on a hybrid that builds on something from the past.

No matter what mechanic I arrive at, I always ask myself the same fundamental questions when implementing a new mechanic:

1. What is the objective and fundamental premise?
2. How does the player win?
3. How does the player lose?
4. What are the obstacles preventing the player's success?
5. How do I keep the mechanic engaging as the levels progress and the player returns?

On the surface those seem like very simple questions. Let's quickly apply it to a very simple game mechanic: tic-tac-toe

1. Player's select either X or O to represent them on a 3 by 3 game grid.
2. The first player who gets 3 of their X's or O's in a row, or diagonally, wins the game.
3. The player who fails to get their X's or O's in a row first.
4. If there are two equally skilled players, the game ends in a stalemate
5. There isn't one. Which is why the game is quickly abandoned by game players.

The Objective and Fundamental Premise

In short: How do I start? First and foremost, whatever mechanic I would be developing needed to tie into the story I had laid out for the game. My game would fundamentally be a hybrid SHMUP (video game parlance for shoot'em up.) Which meant I needed to satisfy a lot of SHMUP criteria with my mechanic:

1. Fast-paced action
2. Enemy waves
3. Power-ups and upgrades
4. Bullet patterns
5. High replay value

That's a pretty tall order. Since my game is a retro game, the easiest way out would be to replicate something like Galaga, Phoenix, and so forth. My game will support multiple mechanics, and those games will be honored in other levels, however, I wanted something a little unique with a twist.

Again, I went back to my roots. I thought about one of the early games of the arcade, Centipede. Now a Centipede clone would not necessarily work in my world, but elements of it would work with a few twists.

So, the first thing I needed to tackle was the story issue. In the previous newsletter, I had established Zuther as the game's villain. So I came up with this premise:

Zuther is trying to take over the galaxy. In order to power his forces and build weapons he needs raw materials, cargo carried by trains, to be obtained from various planets. He decides to strip mine homeworlds of their precious natural resources which he loads onto trains from the mines which ultimately load onto a spaceship and leave the planet.

Each train will run left to right or right to left. Trains will be on a set of tiered bridges. As the train completes its horizontal movement, it will momentary disappear from view, and descend one track tier and run in the opposite direction. The train will repeat this until either all cars are destroyed, or all cars have reached the escape ship.

Trains will be comprised of multiple cargo cars. Each car will contain a variable number of cargo units. Upon that car successfully reaching the escape ship it will unload its cargo which will count against the tally for loading the escape ship.

Once the escape ship has been fully loaded it will take off.

How does the player win?

Based on the premise I developed, there will be a finite number of trains per level. Each train will hold a certain amount of cargo. If the player can destroy all the trains before enough cargo has been loaded onto the escape ship, the player wins the level.

How does the player lose?

If all the cargo needed to fill the escape ship arrives before the player has destroyed the trains, the escape ship takes off and the player has lost the level.

What are the obstacles preventing the player's success?

Although the trains are unarmed there are multiple defense mechanisms deployed by Zuther:

1. There is a laser canon directly mounted onto the track that will shoot at the player's ship.
2. There are free moving flying enemy craft that will come out in waves and shoot at the player
3. Some train cars are booby trapped and will drop bombs
4. Player's ship has a finite amount of shields. If the player depletes the shields by taking too many hits, the ship will ultimately be destroyed.

How do I keep the mechanic engaging as the levels progress and the player returns?

This section dovetails really well into the next installment where I will talk about data driven design. However, lets cover some basics here. When designing a mechanic I look at all the variables I can a tweak .

In the old days of video games on the Atari 2600, the developers had basically two levers they could pull for retention:

1. Increasing the speed of play.
2. Doing variations of the enemy graphics -- usually just changing the color palette.

At the very least there are two things I can do in my mechanic to keep it interesting:

1. Increase the number of trains running concurrently.
2. Increase the speed at which the trains travel.

However, that probably isn't going to be enough to satisfy most players. So there are a few more tweaks that can be made:

1. Variations of the enemies released. Based on level progression unleashing new and smarter enemies who will attack the player more aggressively.
2. Increasing the probability that train cars will drop bombs or booby traps.
3. Increasing the speed on all enemies.
4. Creating variations of the graphics and sprites -- trains, background image,etc.
5. Inverting the level such that trains start on the bottom and work their way up.
6. Using a set of weighted probability tables so that Zuther himself with utter taunts at the player on occasion. (My version of sports trash talk.)
7. Giving the player's ship powerups and the occasional special abilities
8. Varying the background music loop
9. Increasing the rate where the player's ship's shield diminish.
10. Reducing the amount of cargo needed to load the escape ship.
11. Having the escape ship move up tiers so that trains can be unloaded quicjer,
12. Introducing a boss enemy to make the ending of the level of showdown

All of these have to be pre-planned and lead us to data driven design. Stay tuned for the final chapter where I put all of this together with data driven design, game design patterns, and show how I drive my production pipeline with this.