In my last post, I talked about critical mechanics and how to use them to prioritize work. In this post I want to talk about an easy way to turn a critical mechanic into a task list using a very simple concept: the use case.

---

By Reading This Post, You Will Learn:

• What a use case is
• How to write a use case
• How to utilize a use case to identify tasks

---

What Is a Use Case?

Put simply, a use case is a description of a user’s experience with a product. They can come in diagram form, but, when it comes to using critical mechanics to prioritize work in the earliest days of a project, I prefer writing a narrative of the experience. More specifically, I write out, in plain English, what a user will experience when he/she plays the build. If the critical mechanic I need to test is Critical Mechanic X, and I want to assemble a build to test Critical Mechanic X, I describe the experience of playing that build.

Let’s look at how this works, using the platforming in Super Mario Bros. as a critical mechanic as our example. Let’s say I’m making the original Super Mario Bros., and I think platforming is my critical mechanic. I want to assemble a prototype to test it as efficiently as possible.

Step One: Write the Use Case:

Step one is simple: sit your ass down and write out a description of the player’s experience:

Upon booting the game, the player arrives at the main menu. The player pushes “Start” on the controller to start the game.

Once in game, the player sees a 2D level with a single character sprite. The character can run and jump, and the view changes and scrolls based on his movement.

As the player moves to the right, he/she encounters platforms to jump on and a few instances of a basic enemy type. If the character collides with these enemies he dies, so the player must jump over them.

Once the character reaches the end of the level, the player wins and is dumped back to the main menu.

Step Two: Identify the Implied Features/Functionality

Go through your use case and highlight every implied bit of functionality you can find. The more you can atomize the use case into smaller items, the faster it will be to develop each one:

Upon booting the game, the player arrives at the main menu. The player pushes “Start” on the controller to start the game.

Once in game, the player sees a 2D level with a single character sprite. The character can run and jump, and the view changes and scrolls based on his movement.

As the player moves to the right, he/she encounters platforms to jump on and a few instances of a basic enemy type. If the character collides with these enemies he dies, so the player must jump over them.

Once the character reaches the end of the level, the player wins and is dumped back to the main menu.

Step Three: Identify the Implied Tasks

Take those implied pieces of functionality and list the impliead task:

• Main menu – we need a main menu
• pushes “Start” on the controller – we need basic controller input
• Start the game – we need a level manager to move the player from the main menu to the game itself
• 2D level – we need a single level
• Single character sprite – we need a single player character sprite
• Run and jump – we need running and jumping animations for the sprite AND controller inputs for running and jumping
• View changes and scrolls based on his movement – the camera needs to scroll
• Platforms to jump on – the level needs platforms
• Basic enemy type – we need a single enemy type
• Character collides – we need collision detection
• He dies – we need a character state manager and a death state
• Reaches the end of the level – we need a game state manager
• Player wins – we need a defined, detectable win condition
• Dumped back to the main menu – the game state manager needs to send us back to the main menu when we win

Step 4: Get To Work!

And finally you have your task list. From here, start grooming the tasks into actionable items, and estimating and prioritizing them:

• Create a main menu
• Code a level manager
• Receive basic controller input
• Design single level
• Generate a single player character sprite
• Add running and jumping animations for the sprite
• Trigger animations and player movement from controller inputs
• Scrolling camera
• Add platforms to level
• Generate a single enemy type
• Add collision detection
• Code a  game state manager
• Code a death state for the player
• Define and detect win condition
• Dump player back to main menu upon completion of the level

---

Further Reading If You Enjoyed This Post

What Makes This Game Tick?: Prioritizing Development Using Critical Mechanics

Sunk-Costs and Ugly Babies: On The Value of The Scientific Method – Game Planning With Science! Part 8

Perfection is the Enemy of Productivity, Or: Why You Should Be Like Stan and Jack

---

Summary

Starting a project can be a bit like wandering out into an open field – which way should you turn? What should you do? Option abundance can often be more of a detriment than an advantage. So, remove options from the table – focus on what you need to do to test your design, and ignore any other work that doesn’t specifically contribute to that test.

---

Key Takeaways

• A “use case” is a description of the user’s experience with a product (or game, in our case)
• Use cases are traditionally done in diagram form, but a written version works well to define a player’s experience
• By writting the player’s experience as a narrative, it is easy to pick out implied functionality
• That implied functionality can then be used to identify an actionable task list

---

If You Enjoyed This Post, Please Share It!

“Where Do We Start? – How To Build Our Your Initial Task Lists With Use Cases” by Justin Fischer is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.