Tearing Down to Build Up

We’ve ranted enough on this site about how we can improve the ability to mechanically implement things, but we need to talk a little bit about how we do the actual building. We’re going to stretch a restaurant metaphor a bit.

The Restaurant Problem

Imagine you’re opening a restaurant because you’re a chef. You go out and you hire a bunch of people who know how to do restaurant things. Cooks. A sommelier. A Host. Some Servers. And then you sit them all down and ask “What kind of Restaurant should we open?”. Or maybe you decide to open a Mexican restaurant and then you sit down and say “We should try to figure out what good Mexican food tastes like”.

I don’t want to belabor the point, but so much of game dev is “Finding the Fun”, which takes us so long to get to because of the amount of exploration we THINK we need to do.

Building a Recipe Book

But what if, similar to a restaurant, we just had some recipes? We built out a shared framework that we used to build the things we want. This concept is discussed in great ways in the Head First Design Patterns book, and if you read The Timeless Way of Building and other classic design books we talk about, essentially, tropes.

We think there’s a path forward to build out a game that we can do with some high level descriptions of tropes. This allows us to lay out a path to execution and still leave room to find the fun, and as we abstract away these high level features, it also allows us to better scope and understand our project.

To build out this recipe book, we’ll need to build a shared lexicon (What is the difference between mincing and dicing an onion?), as well as some good abstractions (If we all can agree how to make a bechamel then we can just say ‘Make a Bechamel’ in our recipe, and we don’t need to spend a lot of time talking about what we need). Along these lines, we can create a rough recipe for our games by outlining the features we want, and the assets we might require. Be careful of chasing an MVP!

Witch It! Breakdown Example

One way we’re going to approach this is by doing a teardown of an existing game. We’re using Witch It! on Steam as an example. If you haven’t played it, it’s a great little implementation of ‘Prop Hunt’ that you may have played on Gary’s Mod or Roblox. It’s got great reviews and is a good example for us to use here on what it takes to make a game.

For this breakdown/teardown we’re focused on identifying what Witch It has, rather than what we would potentially want to implement. We’re just categorizing existing behaviors.

UI Screens (21 Unique Screens)

We’re starting here because these are easy to catalog. As we outline these screens we’ll call out any specific functionality we see as well. Hopefully you can begin to see how many of these features aren’t specific for this game but are good “patterns” we can identify and know how to implement.

• UE / Company / Publisher Logo Screens
• Title Splash Screen [Push to Start]
• Main Screen
  • Nav Bar
  • Daily/Weekly quests (with easing animations)
  • Social Links
  • Player Card (Name/Icon/Level)
  • New Content Notifications (iOS Style Red Dot)
  • Animated/In-Game Background Scene
• Collection Screen
  • Unlockable Customization Options
  • Search Customizations by Name
  • Customization Sets
  • Preview / Drag to Rotate Preview
  • Tooltip Info Popups
  • Tabbed Navigation
  • Basic Crafting System

This is just a taste of the full breakdown - the point is that by cataloging what exists, we can build patterns we can reuse.