top of page
Game Design Icon.png

Why is Game Design Important?

Is there a person in the world who would want to play a game that is dull? or confusing? or redundant? Is there a person in the world who would want to make that game?

Game design is arranging activities to provide specific feelings and mental states to players. It is also surrendering your ego to discover how.

Game designers have differing opinions. Good game designers know how to persuade, listen, evaluate, and identify the true problems to solve.

Games wield incredible power. They enable people's minds and actions. Games can enable player's bad habits for profit, or they can enable learning, connection, achievement, and healthy rest.

Game Design

Intended Experience
rainbow.png
rainbow.png

Spooky Time

Ghost Cute.png
Ghost Horror.png
Spooky Time MDA Meeting_edited.jpg

Making Cute Horror

My game-jam team agreed to make a game about ghosts who transformed between cute and horrific. But, we did NOT agree on how the types of ghosts would work. Could horror ghosts pass through walls? Move faster? Hurt you while stunned?

To resolve this, I invited the team to discuss MDA framework.

The experience we agreed on included terror, danger, hope, fairness, and "skill succeeds". One by one, we went through the proposed mechanics and critically evaluated whether the dynamics
 they caused would lead to our intended experience. We even made paper simulations.

When our conversation finished, we had a lo
gical grounds for our game mechanics that we all believed in.

game loop teal.png
flow channel.png

Stress-and-Rest Flow

Presenting our unfinished game, a professor asked us, "Why does your horror game have a cute section? Why not just horror?" We gave two answers to this question.

1. An optimal flow graph has building challenge with alternating high and low points. Our game's design fit this perfectly. The difficulty rose steadily as ghosts spawned. It also spiked or plummeted when ghosts changed between horrific and cute.

2. The best horror has anticipation. Those moments of rest let the player relax enough to get scared all over again. It also gave players hope to fight through the horror.
 

A Game from a Toy
rainbow.png
rainbow.png
heckspawn title.png
ezgif.com-gif-maker (15).gif
toy.PNG

GIF

mouse.png

A Fun Toy

Our first assignment was to make interactive fun WITHOUT any win conditions. In other words, a toy.

While discussing twinstick swordfighting, I suggested that the sword could deflect bullets. It was very fun, even in a test room with no goals! We simply stacked more ideas on that fun mechanic to make our game.

spikeball.gif
spike spit still.PNG

GIF

mouse.png
good and bad mechanics.png
zinger still.PNG
A7Y+yp.gif

GIF

mouse.png

Interpreting Player Feedback

Every early playtester was annoyed by the "ninja star". Ninja stars could damage players just by touching the bat. Players were killed again and again, not helping them feel mastery.

I winced when I heard players wanted ninja stars GONE from
 the game. I had fun bending out of their way. Worse, if the bat could hit every projectile, then players could be safe forever by spinning the bat.

Asking my professor about the question, he advised that players are good at finding problems, but can offer the wrong solution.

Players explained a natural instinct to hit ninja stars at enemies - it looks like a good attack. After I changed them to a quivering lightning bolt, players instinctively kept their bat away. Now players dodged through them, feeling skill.

PXL_20230222_010337705.jpg

Secrets and Calling Bluffs

To make a dungeon-builder with hidden traps and treasure, all we had was brains and paper scraps. We tried several approaches that failed.

A face-down grid that each player shared and moved through stood out. Players bluffed what cards they played and took risky paths. That was a start to our game.

Card Back door.png
Card Back door.png
Card Back door.png
Card Back door.png
Card Back door.png
Card Back door.png

Reducing Memory Overload

This game had a VERY strong memory burden for a long time. Every facedown card was identical!

Players boringly stumbled into their own traps, and they had no mental bandwidth for more clever strategies, like tracking which cards their opponent avoided.

Now, card backs point towards whoever played them, and players can check their own cards. Players make more interesting choices, and less blind guessing.

Negative Board Control Loops

The main game rules have a big positive feedback loop:
More Board control = More Movement = More Board Control. It needs to be balanced against.


Energy Cobra is often ignored when it is discovered, but becomes more valuable as more dead cards are revealed. This gives both players a chance to trade health to seize board control.

Sizzling Bomb and Coin on a string will be avoided by players with board control because of their negative effects. But they will give extra board control to the other player.

Synergized Master Traps
 
Certain traps restrict the options of whoever falls in them. Bait them, play dumb to the enemy, and chain them with other nasty effects - then jovially recount how it was your dastardly plan all along.

rainbow.png
rainbow.png
Shareware Timebomb White.png
loveball pitch slide.png
loveball prototype.png

GIF

Loveball Protoype.gif
mouse.png

An Underwhelming Pitch

My "One-Month Game" teammates were surprised and unconvinced by my pitches. Instead of strong visions, I showed greyboxes.

I explained that even in these barebones mechanics, there was already fun to follow. 1 month would be enough to explore a fun game.


In my "Shareball" pitch, frantic rescues and careful communication would form close interaction between players. That experience goal had potential and eventually persuaded my team.

character controller.png
Player Controller Diagram
image (2).jpg

GIF

mouse.png
big_kick_another_case.gif

Prototyping Early Questions

Quickly, we disagreed about the player's abilities. Should the player kick and dash? or carry and throw?

Both prototypes worked well, except that carrying the ball simplified the challenge too much. We ended up with dash-kicking and stand-still throwing.

We also disagreed on our physics settings. A game with a much faster ball would be more chaotic and exciting right?

More discussion showed we weren't ready for the design revisions that required, such as much smaller rooms and boss fights. But the fast ball bouncing everywhere was definitely fun. Instead of making the ball inherently that fast, we added obstacles that made its speed go out of control.

rainbow.png
rainbow.png
tlass title.png
TLASS Old UI.png

Killing my Darlings

To flex my usability skills, I designed UI that would inform the player of the consequences of their choices.

However, a teammate noticed that this encouraged ignoring the story.


While the feature showcased skills I am proud of, I immediately saw she was right. Our game's goal of "feeling like a pirate" needed our choices to have more narrative weight than "number go up or down". I cut the feature.

rainbow.png
rainbow.png
SNO.png
unkno n.png
image.png

On-boarding

Playtesters weren't using their tools when they needed to, which concerned us.

Ethan and I joined a call and discussed what we could do. What happened was a very satisfying design session where we reordered events, gave them more punch, added a small tutorial hill next to town, and spread teaching moments across the map.

After implementing the changes, players understood and applied safety techniques better.
 

image.png
image.png

Awful Scene Editing

Our main scene held the entire 3D environment, made using "Polaris Low Poly Terrain". It would occasionally crash, losing any progress.

Without our programmers, usability updates were stalled. Adjusting components and splines was extremely tedious work.

I did organize, learn shortcuts, and improve components, but too little too late.

This problem both wasted time and drained morale.

image.png
image.png

Avalanche Safety Gameplay


The game's loop challenged players to set off for resources, avalanche detect along the way, and spend resources to repair bridges and lookout points.

So how did our edutainment game turn out?

Learning through dialogue was slightly heavy-handed, but applying avalanche safety skills in the game felt natural and put the concepts in the players hands.

The game was passably entertaining - getting collectibles and progressing was fun, but our overscoping left some areas feeling empty or slow. I'm confident that with a little more time, we could expand on the fun we built here and fill in the gaps.

This game was a partial success, and shows me that education
and game design are two tasks, not one when put together.

bottom of page