Design by stumble redux

content/blog/design-by-stumble/index.md

@@ -0,0 +1,149 @@
++++
+title = "Design by Stumble"
+description = "The first game design mistake we all make"
+date = 2023-12-10
+authors = ["Rose Peck"]
+
+[taxonomies]
+tags = ["game design"]
++++
+
+I think everyone who dabbles in game design at least sometimes gets the feeling of "what if [thing that I like], but made by me!"
+
+"I love God of War. Wouldn't it be awesome if there was a game that was a lot like God of War, but like, I was the one who made it!?"
+
+"Man, Minecraft is so cool. I'd love it if I made a game and at the end of the process, it was just like Minecraft, because Minecraft is really cool."
+
+"I love Dungeons & Dragons, and I love making games! I want to make a games that are just like Dungeons & Dragons."
+
+We all get this feeling!
+It's a common thing, and it's a great way hype yourself up and build motivation for projects you're working on.
+There's no shame in it.
+
+But, this outlook generally doesn't lead to good outcomes.
+Obviously, following this instinct blindly leads to very derivitive work, but there are lot of more subtle issues at play here.
+I've seen a lot of designs and projects by amateur designers that feel boring, derivative, bloated in scope, full of vestigial features and lacking in cohesion.
+It's probably the most common single problem I see when reviewing designs by hobbyists, especially those working solo.
+So, what's going on here, why does this happen, and how can we do better?
+
+## Design by Stumble
+
+**Design by stumble** is a design pattern where you start with something that you like, make a few random iterative changes, and then call it done. 
+For me, the classic example of this is taking an exisitng tabletop RPG, changing the core dice mechanic to something else (like changing from d20 to 2d6), removing a few skills, and then adding a few new ones.
+One of *my* earliest design projects was basically just taking a boring JRPG template (like Final Fantasy 6) and replacing the class list with 4 much less interesting ones.
+(Unfortunately the original notes for this project have been lost. Otherwise I would *love* to rip it apart publicly sometime as a learning experience.)
+I've also seen *a lot* of homebrew for *Dungeons & Dragons* that falls into this category.
+
+To be clear, this is distinct from taking *inspiration* from previous work.
+Firstly, works which inspire a game are a bit further removed from the game being made.
+When designing by stumble, the inspiring work is used as a *starting point*.
+It's like taking a whole painting and then painting on your own additions over top of what's there.
+Healthier inspiration is more like taking the outlines or broad strokes from a painting, sketching it on the canvas using a pencil, and then using that as *guidance*.
+
+More concretely, when a skilled designer takes inspiration from other work, they typically start not by hacking on it, but by *analyzing* it.
+The first stage is focused on determinging which parts of that work were effective, which parts weren't, and *why*.
+Instead of grabbing mechanics and ideas uncritically- those ideas are evaluated against the project's *goals* to see if they would be a good fit.
+
+And that really is the key piece here: design by stumble *isn't* defined by taking functioning pieces from other works.
+It's defined by a lack of *goals* and *vision*.
+
+And, to be clear, there's nothing inherently *wrong* with that!
+Designing by stumble is a great way to experiment, try out new ideas, explore new genres/mediums, and most importantly, to learn and improve as a designer.
+Up above, I mentioned one of my early design projects. 
+And although that project was a mess, I don't hate or malign it.
+It was a valuable learning experience for me, and doing projects like that made me a better designer in the long run.
+
+But... that project *was* a mess.
+And that's the rub.
+Because design by stumble really falls apart if you want to make something that's, y'know, *good*.
+
+## Why doesn't design by sumble work?
+
+The core issue is that, since design by stumble is unpricipled and unmotivated, the random changes are both unlikely to result in meaningful improvement, and likely to result in unintended problems.
+Let's break down some of the knock-on effects of designing by stumble:
+
+1. **Derivative work:** If you're starting with someone else's idea, it's hard to stand out and be original.
+2. **Iteration needs direction:** Iteration isn't inherently flawed, but it needs *direction* to evaluate if the iterative changes have actually improved the project. And direction means you need high level *goals* to evaluate against. Changes made at random are just as likely to harm a game as they are to improve it.
+3. **Unintended side-effects:** Even seemingly small changes can have significant and far-reaching effects, often unintuitively. Anyone who's played a competitive video game has seen how very small balance changes can dramatically shift the optimal stratigies. (I could (and probably should) write a whole series of posts about times this has happened.)
+4. **Poor team alignment:** When working with others, having clear goals and vision is very useful for keeping everyone aligned, and making sure everyone understands what they're working on.
+5. **Scope creep:** If you're not careful about what you're adding/changing and *why*, it's very easy to bloat the scope of your project into something huge. Unless you clearly know your constraints and limits, you might end up adding more and more and *more* features until it's just too much to handle.
+6. **Huge starting scope:** When working in video games, copying other popular games is often much harder than it seems. Large AAA games require hundreds of people working over the course of years. Starting with that as a template would sign you up for far more work than most studios have the budget to complete. (As a sidenote, this problem doesn't exist on the tabletop because copying someone else's TTRPG is as simple as copy/pasting the text of the rulebook. I'm not sure if that's a good or a bad thing.)
+7. **Static analysis:** Iteration is great, but a lot of iteration time and work can be saved by carefully analyzing mechanics before adding or changing them. Thinking through designs, running small tests on paper, comparing to existing work, building internal frameworks for balance, and more are all great design strategies. Think before you stumble!
+
+## Doing better: a Principled Approach
+
+So, how can we do better?
+Having a clear goal in mind is the main theme here, but there are lots of specifics that go into that.
+Here at Leafwing Studios, we've developed a fairly robust list of questions that we use whenever we start a new project.
+For us, *this* is the first step for a new idea.
+So, here are some questions and topics to help you refine the goals and vision for *your* next game:
+
+- Overview
+  - What are the overall goals of this project? Why are we making this thing? (Money, fun, practice, to play with friends, to advance the state of the art, etc.)
+  - What's the core concept (mechanically or thematically)? What idea made you want to pitch this project?
+  - Elevator pitch: In one short sentence, what is this game about?
+  - What are the themes? What is the fantasy we’re trying to create? What message are we trying to send?
+- Audience
+  - What's the target audience for this game?
+  - What kind of player would really enjoy this game? What else do they like? What would they like the most about our game? (There may be more than one group!)
+  - What kind of player would not vibe with our game at all? What about our game would rub them the wrong way? (There may be more than one group!)
+- Prior art
+  - What inspirations are we drawing from? (Because inspiration is good!)
+  - What are our anti-inspirations? What existing (but similar) works do we *not* want to be like?
+  - What genre, if any, does it fit into? What genre conventions are we interested in following?
+  - What other works exist in this space? How are we going to be better than them?
+  - Are there major existing works that we're not very familiar with? We should check them out!
+- Practical constraints?
+  - How many team members do we have on our team, and what are their skills?
+  - What's the budget? (Y'know, in dollars)
+  - What timeline are we aiming for?
+  - What are our team's main skill gaps, and how able are we to hire out that kind of work? (If you can't cover those gaps, then you'll need to design around them.)
+- Business
+  - Monetiziation strategy: How are we going to make money from our players?
+  - Marketing strategy: What channels are we going to use to reach our target audience?
+  - Marketing hooks: What game design elements can we focus on to push the marketability of this game?
+
+## Dear Princess Celestia, Today I Learned...
+
+...that having goals is important!
+
+We all want to make art like the things that we love, but we should make sure we're *intentional* about it.
+Why are we doing this, and what do we want out of the project?
+If all we want is to mess around and learn some new stuff, then to hell with all this preplanning nonsense!
+Get out your fattest paintbrush and slap some color on that canvas!
+But if we want to make the next great thing, we should make sure we know where we're going.
+
+And *then* slap some paint on that canvas :)
+
+## Bonus section: Two interesting tangents
+
+The post is over, but I ran into a two interesting cases that are related to the topic at hand.
+I felt like I had something interesting to say about each of these, but I couldn't find a natural place to fit them in the post, so I've just collected them here.
+Consider it a bonus, or a sprinboard for future discussions :)
+
+### Mainstream games can often be derivitive, but for different reasons
+
+A natural question is: "so, is this the reason that AAA games are so derivitive?"
+Although design by stumble does often produce derivitive work, I don't believe it's is the reason why many released games are derivitive of others.
+I think the simple explanation for this trend is that some publisher or executive saw a successful game and said, "Look at all the money they're making! We should be making that money!"
+And then they told the studio to copy said successful thing.
+(In some cases, the successful thing being copied is just the last thing the studio released.)
+This outlook *is* very similar to design by stumble, but it's subtly different.
+In this case, the goals are actually very well defined, but the project is lacking in vision because the "why" behind the project is explicitly to try to copy someone else.
+
+It's a mindset born not of blind XXX, but of risk-aversion.
+
+### Copying someone, but doing it better
+
+Another similar but subtly different pattern is to try to copy a flawed game, but just fix all the flaws.
+Doing this properly requires doing some real analysis on the thing being copied.
+That way, you have a clear understanding of what the problems are, why they don't work, and how to fix them.
+But, if you can do that analysis, this can be a winning strategy.
+
+The difference here, again, is that the goals are quite clear.
+The work is still explicitly derivitive, but the strategy and motivation are sharp: take something else and improve upon it.
+The downside is that it's still difficult to stand out.
+Making one or two small improvements isn't going to get a dedicated player base to move over.
+But if there are significant problems with the original, or if there are significant improvements to be made on the formula, then you can really run with something like this.
+
+If you've ever heard a reviewer say "This game is basically an X clone, but it's a *really good* X clone", then I'd bet that this is what happened.