This is part 9 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we talked about ships and the various systems involved with movement and stacking. This time we’ll talk about combat and the joys of stub mechanics.
I’m scared to design the combat system in SpaceCrack. All the actions we’ve built up so far are meaningless without a combat system makes these past choices apparent and meaningful. The conflict resolution mechanism needs to embody all past decisions pertaining to the two competing ships.
- Players spent a lot of time and energy creating territories. The combat system must give this investment value.
- Players spent a lot of thought picking the right planets to focus their ships. This must matter as well.
- Players spent a lot of thought picking which ships to merge. Poor ship merging must have an effect on the outcome.
I also have some big design goals. I want to reward the thoughtful player over the action player. Heaven forbid that building the biggest ship fastest wins. I also need the combat to be entertaining for thousands of encounters.
What is a poor designer to do? This is a difficult problem with lots of variables. I have a few vague ideas, but, there is a 99% chance my solution will suck in its first incarnation.
To get me out of this stalemate, I’m going to employ a very tricky and difficult design technique. First, I’m going to admit that I don’t know the perfect answer. Then I’m going to do the simplest thing and evolve the design by iterating on the concept.
Evolutionary Game Design: A theoretical underpinning
In my dreams, game designers are vastly intelligent creatures who are capable to bringing forth entire worlds verbatim from their foreheads. Like Zeus. Every little detail, every rule is sitting pristinely in our noggins just waiting to be transcribed onto a sheet of clean vellum.
Then I wake up.
The reality is that game design is a messy, miserable process filled with dead ends, convoluted designs that aren’t fun, and long theoretical rants that are ultimately useless. These are complex systems we are dealing with and the best ones have deep, difficult to predict results. Tools like risk / reward sequences and design testing point us in the right direction, but they are ‘steering’ mechanisms, not methods for ‘deriving’ game mechanics.
Ultimately, game design is a heavily iterative process that involves frequent prototyping and an evolution of crude game mechanics into a reasonable form. This is especially true of core game mechanics that differ even slightly from established genre conventions.
I’ve covered this topic in much more depth in past articles (https://lostgarden.home.blog/2000/01/01/evolutionary-design/), so I won’t belabor the point.
Choosing a fundamental activity
Let’s follow the rules laid out in my previous essay. First I have to define my fundamental activity. I’ve got a good start:
- Collect tokens (ships and upgrades) and move one token collection (a super ship) onto an enemy token collection.
- Based off the various properties of the stack of tokens, one token will be destroyed.
This isn’t complete because I haven’t specified either the property of the tokens or rules for determining a winner. At this point, I create a stub mechanic so I can play the game.
The Stub Game Mechanic: A simple, easily implemented placeholder mechanic that fills in holes in the game design and lets you play the game. It is generally not well balanced, nor is it the ultimate desired system. It’s key benefit is that it lets you get a working iteration of the game play up and running quickly.
Stub mechanics are wonderful. In many ways they are the secret to good iterative game design. With stub mechanics, you can lay out a game design in broad strokes and then rapidly implement a trivial set of simulation rules. The game will suck, but you can start immediately getting a feel for the system. At this point, real evolutionary game design begins. Stub mechanics kicks a designer in his philosophical ass and says “Enough waffling and jabbering. Let’s play the damn game.”
Stub mechanic for Space Crack combat
- The ship with a higher power rating will defeat the ship with the lower power rating.
- The winning ship will lose health equal to 50% of the defending ship’s power.
‘Nuff said. Time to move on until we get to play the game.
For those of you who get turned on by intricate systems, this is no doubt one of the worst posts of the entire series. Still it contains an important lesson in both humility and process:
- You aren’t going to have the best answer all the time.
- If you don’t know the perfect game mechanic, try the simplest thing possible.
- Play the game and identify problems.
- Create variations on the existing mechanic that solve those problems.
Very impressive brother. Watch out, your brain will get hairy! -Tnerb
I\’m really enjoying watching the progression of SpaceCrack. I know a few friends and I are looking forward to a playable build.
Great article on the benefits of stub mechanics.For completeness, it might be worth explaining why you chose for the bigger ship to take HALF of the smaller ship\’s strength in damage. If you\’re going for a stub that you know is wrong anyway, and the point is to be as simple as possible, then taking 100% damage would make the most sense (as it\’s simpler — no fractions).
100% damage would indeed be the simplest thing. I have a habit of throwing variables in front of constant so that I have something to play with when I get to the polishing stage. So 50% was an arbitrary factor tossed in because it was an easy balancing lever that shouldn\’t take major engineering time to implement. Often I\’ll judge the simplest thing as \’anything that requires one to two orders of magnitude less effort than what is probably necessary in the final product.\’ It is less about mathematically simple and more about the ease of implementation. This distinction comes into play later on in a design when you have a lot of existing systems to build upon. A \’simple thing\’ will sometimes involve rather sophisticated behavior (physics systems come to mind) Horribly fuzzy, admittedly. Danc.