General game design

Created: 2017-03-23 18:07:47 -0700 Modified: 2023-10-17 17:56:52 -0700

One-liner notes

Octalysis is a gamification design framework that lays out the drives for motivation (e.g. empowerment, ownership, unpredictability, etc.).

Testing for “fun”

You test that a game is fun by making a prototype and playing it. If the game is multiplayer, then you have to simulate other players in order to test if it’s fun. Without that, you’d need to find real people, teach them the game’s rules, make sure they’re all appropriate skill levels, coordinate their schedules, etc. That’s still important at some point in testing, but the prototype should still be fun with bots.

Ideally, the bots act similarly to smart human players. Think of good games like Super Smash Bros. or StarCraft:

AIs aren’t just performing random inputs
AIs aren’t often doing really stupid things (like getting stuck on walls)
AIs aren’t performing the same inputs in every situation, so they’re not as predictable

I’m adding this note because I remember stupidly trying to test the first iterations of Bot Land (the realtime version in ~2017 or whatever) with real people. I spent way too much time to learn that the game loop wasn’t very fun.

Designing a brand new game

I think these are good ideas for when you’re starting on a brand new game:

Questions to ask:

“What kind of gameplay do I want to encourage?”
- E.g. if you want players working together, then your incentives need to align toward that.

Things to do:

Start jotting down any concrete system that will satisfy a game-design need. E.g. if you’re making an RPG and you want character differentiation, simply go with a talent tree even if it’s not the best. The point isn’t to come up with the final system, it’s just to give a concrete comparison point for future systems, that way you’ve narrowed down the infinite possibilities.
- Also, that was just an example, but skill/talent trees in particular have hundreds of successful incarnations in the history of gaming, so try not to get too caught up with what works unless you plan on having >100 skills per character or something.
- Especially decide to move on when a system or mechanic wouldn’t take that long to change. For example, suppose you can upgrade buildings in your game, and you’re deciding between whether buildings should be upgraded linearly (“Lv. 1: +1 troops, +1 food”, “Lv. 2: +2 troops, +2 food”) or selectively (“Choose one: +1 troops or +1 food”). The difference in coding those two choices is pretty negligible, so just pick one and move on.
Sections to make in a document:
- Overview: what is the game about at a high level? This is great when you start having tens of game design documents.
- Ideas: things that might be fun but may not fit in with the game
- Questions: <see the “Systematically list and answer questions” section>
- Design: the so-far finalized design decisions.
- Scratch: random thoughts you have as you’re thinking about the questions you have. This is intended to be used to arrive at conclusions for the “Design” section.
Systematically list and answer questions. E.g.:
- “What does the endgame look like?"
- "How long do matches last?"
- "How many people play in each match?“
- …then, pull out one of those questions to a scratch pad and plan things out. “How long do matches last?” “Well, if they’re 10 minutes, then people can play in a single session. If they’re 30 minutes, then the strategies can start to show more depth. If they’re a day long, then players would only be able to check in a few times per day, so maybe we’d be hurting the experience for players who want to be active for the entire game.”
- Don’t hesitate to say “we’ll have to figure this out through prototyping”.
Make many simplification passes. A simpler game is easier to get into and easier to understand. After designing most of your game, you probably changed several assumptions.
- Is this system needed? What value does it provide?
- Is there a way to provide the same value with a simpler system?

Good ideas:

Design without a deadline, that way you can pump any “residual creativity” into it. Sometimes, after stewing over an idea for a week, I come up with something good to add, and it’s much easier to add that thing when early in the design process. The design should make enough sense as a complete game before starting to prototype.
Involve others! They don’t need to be professional game designers themselves, they just need to be willing to work with the information you give them and help spark creativity.
- Designing almost anything totally alone has almost always led to worse results in my experience.

Some effects only seem equivalent

Consider “double your life” vs. “take half damage”. In total isolation, they have an identical functional impact (you’ll take twice as long to die), but they interact with other mechanics differently:

Absolute (as opposed to percentage-based) healing effects are essentially doubled if you’re taking less damage per hit
Percentage-based effects (e.g. “gain attack if at <30% life”) can be easier to achieve if your life is doubled

My conclusions from this:

Simple effects can sometimes combine to form more interesting systems
Some effects only seem like duplicates at first glance

Memorable differentiation

Take any card game like MTG or Hearthstone and imagine no graphics/SFX. The cards themselves are VERY boring:

2-mana 2/3 with “beast” tag
2-mana 3/2 with “beast” tag
2-mana 2/4
2-mana 4/1 with stealth

These sorts of minor tweaks are hard to keep track of until you add names, graphics/animations, and SFX. Then, River Crocolisk immediately stands out from Razorfen Raptor even though the only change is that their attack and health is swapped.

I think the lesson here is that if you’re going to have ten weapons in your game that vary only in damage or attack time, find some other way to memorably differentiate.

Systems

(6/23/2020)

Don’t add systems until they’re actually solving a problem. Not every RPG needs an inventory, crafting, trading, exploration, and skill trees. Maybe just battling is enough, and maybe it’s not.

Also, sometimes it may seem like you’re designing a game, but you’re really just designing a system or mechanic. E.g. I thought of a deck-based auto-battler, but that’s not actually a game, it’s just a battle system.

Magnitude of numbers

I think that incredibly large numbers are hard to understand for users, e.g. doing damage in clicker games eventually gets to “You did 5*10²⁴ damage!“. On the other hand, very small numbers (“You did 1 damage!”) can sometimes be underwhelming; I felt that as I was playing Paper Mario for the first time.

There’s one other consideration that caused me to write this note though; in Bot Land, some players missed that they earned in-game currency by winning a game. The amount that they’d win per game was 1 Botcoin. By having the number be the lowest possible positive integer, it’s less obvious if you were to animate the number rising since it’s only changing by one.

Currency vs. tokens

This is just a random thought, but suppose you have an in-game currency that can buy practically anything. It may still be worthwhile for you to have “tokens” that can only be spent on specific things. Reasons:

A token can’t be spent on anything else, so the impact to economy-based balancing is easier to calculate.
A token can be given as a reward when granting the in-game currency would be too general.

As an example of the above pros, imagine a game like World of Warcraft where respecializing your talents costs gold. If you give a player gold, then in general, they are much more likely to spend it on something “more important” like gear, skills, items, etc. However, if there was a “respecialization token”, then it could be a fun reward since you may not have prioritized respecializing enough to spend money on.

I don’t think tokens work for everything though in a game. For example, in an RPG with repair costs,

Balancing

When it comes to balance, make sure there are knobs to tweak. E.g. a weapon that has “freezes target” is hard to balance because it’s all-or-nothing. Instead, a CHANCE to freeze the target can be something that you can balance, that way you can make it only happen every so often.

9/9/2017 - it’s an interesting thought experiment sometimes to say “why not make this infinite?” For example, a game called Redungeon that I tried out is a tile-based infinite runner with a bunch of different characters. One of them has a “gold magnet” that draws in coins from either 1, 2, or 3 tiles away depending on its level. Given that it’s a tile-based game and only so many tiles can even render on the screen, if they ever had a fourth level, it may as well just say “draws in all coins on the screen” (i.e. an “infinite” range as opposed to a 4-tile range). It doesn’t always make sense to have an infinite range and sometimes it can be confusing to the player, but it can help you as a game designer to determine the function of a particular ability/balancing.

Objectives

Sometimes there should be tension between different objectives. For example, expanding your base in StarCraft costs money, which means you’re usually expanding your base at the cost of army strength since you’re not spending your money there. You want to make expanding your base appealing (in this case, it’ll increase your earning capacity), but you also want to make harassment/attacking appealing (in this case, it’ll win you the game).

Polish

The presentation of a game has a huge impact on how much fun players seem to have. I feel like the core gameplay of Bot Land didn’t change for about a year and a half, but the presentation just kept getting better and better to the point where new players hit fewer road bumps each time the game got an update.

Juice

This article does a great job of including visual examples of how to make your game feel responsive/juicy:

Make controls responsive: the game should react to input immediately even if it’s just to queue an animation
Ease vs. lerp: use easing instead of linear movement
Idle animations: when nothing is happening, the screen shouldn’t be 100% static
Don’t abruptly delete objects: fade them out, show a smoke burst, etc.
Add gravity to primary actions: a primary action can be given many secondary actions, e.g. screen-shake, particles, wind, pieces of a target monster flying off, etc.
Send a clear message: cut down on unnecessary UI. When UI is needed, draw attention to something with animation/motion.

Inspiration

Playing even a vaguely similar game to one that you want to make can be great for coming up with ideas. I don’t want to go into tons of details here, but in planning for a particular RPG, I happened to be playing Skyrim a lot, and I would come up with ideas for enemy fights, spells, etc. as I played. What’s more is that they weren’t copied from Skyrim; they were just obliquely related.

It’s also helpful to talk to a friend who is both capable of helping and enthusiastic about doing so.

Finally, this isn’t something I’ve proven, but I have a feeling that ideation can be aided by playing music.

Automation games

Writing this mostly for myself.

Fully automating a character (like in Bot Land) means that the game becomes about automation rather than just involving it. You need a suitable interface for automation (scripting and/or a visual system) and then some way of debugging that system. It’s generally tedious, so these games are best done as puzzles or educational games.
Anything short of full automation means that the player should be providing some kind of input at regular intervals or else they’ll feel like they don’t have any control over the game. E.g. even Ogre Battle 64 had fully automated battles, but you were constantly positioning units, using items, etc. Even within a battle, there was a limited set of manual actions you could perform.
Automation that doesn’t have to be perfect will always lead to the automation “smoothing over” any bumps in the game. For example, imagine automating Pokémon. The difference between an optimal battle and just a winning one isn’t such a large difference, so most players would accept “good enough” and probably follow very simple rules in their automation.