Design from the ground up.

#1
I've been working on the design concepts needed to design a strategy game from the ground up, instead of just copying some other strategy game and paring it down or changing a bunch of its rules to come up with something new. Discorders encouraged me to post my thoughts here for posterity and further long-form discussion, so here they are.

(EDIT: This is an exercise to solidify core concepts in strategy game design. I do not intend to design games this way. I think designers would benefit from having the below concepts in mind when designing their games, and can use them to help make good design decisions.)

The basic formula I've arrived at: Start with low-level directed graph of non-transitive relations, then come up with some way of allowing players to switch strategies in local scopes. Add conditions that reverse some relationships. Add localizing conditions--usually space.

The core concepts are localization and non-transitive interactions between game elements.

Non-transitive relationships are e.g. A > B > C > A, as in Rock Paper Scissors. No one game element sits at the top of the hierarchy--there is a loop within the graph of what beats what. All deep strategy games seem to be based off of some number of overlapping non-transitive relationships between core design elements, like unit types in RTSes. Situational exceptions to the non-transitive interaction are an important factor that makes gameplay significantly more complex and interesting.

E.g. in RUSE, tanks beat infantry which beat AT guns which beat tanks. Tanks easily beat infantry, but if infantry are in the woods they are hidden from tanks, and infantry have a powerful bazooka attack they can use at short range to instantly kill tanks, so baiting tanks down roads through woods lets infantry reverse their interaction with tanks.

E.g. In a deckbuilding game like Slay the Spire, cards synergize with one another to create powerful combos, so having pieces of one combo instead of another can lead you to prefer choosing one card to add to your deck over another. Your deck contents are situational. If you didn't have the combo components for card A, maybe card A is way worse than card B. With the combo components, though, card A may be WAY BETTER.

Localization of mechanisms' effects in time or space mean the game must be played through a few, if not many, iterations of core game loops (i.e. subgames) where strategies can be tested at varying levels of maturity and players can make adjustments based on what they see from the system/their opponent. This leads to a very appealing back-and-forth of investment, system/opponent feedback, prediction-guided adjustment, then further investment.

--

Here's an application of these basic principles to produce a design sketch from the ground up. Start with RPS, which is the simplest possible non-transitive interaction graph. R, P, and S can represent low level strategies which each consist of three parts, two parts are shared with other strategies. Iterate the selection of R, P, or S, but only let the player change one or two of the parts. Break this into three "spaces", you can only choose one part move per turn, players get a point for each round they win in each space. I think that's the foundation of a workable deep strategy game.

--

The combination of non-transitive interactions and localization means that a game isn't a "race to the top" but instead a game of opposition-sensitive exploitation which must be catered to various minor and major changes in game state. Two plays of the game may turn out markedly different because the feedback loop mentioned above emphasizes different parts and loops within the non-transitive interaction graph. In an interesting strategy game, the player has to react to lots of situational variables which make decision-making complex and thought-provoking. I think this is what makes strategy game systems substantially deep.
 
Last edited:

BrickRoadDX

Maker of BrainGoodGames
Staff member
#2
Here's an application of these basic principles to produce a design sketch from the ground up. Start with RPS, which is the simplest possible non-transitive interaction graph. R, P, and S can represent low level strategies which each consist of three parts, two parts are shared with other strategies. Iterate the selection of R, P, or S, but only let the player change one or two of the parts. Break this into three "spaces", you can only choose one part move per turn, players get a point for each round they win in each space. I think that's the foundation of a workable deep strategy game.
Can you expand a little on "R, P and S can represent low level strategies which consist of three parts, two parts are shared with other strategies. I got lost in your example here.
 

keithburgun

Administrator
Staff member
#3
This is interesting, and makes sense to me.

I guess the thing I don't exactly get is, like... why? Why do you want to start from scratch - what's the value in doing that? My concern with doing that is that you're going to end up making really alienating, weird, hard to understand systems. I think maybe 5-10 years ago I would have been a lot more excited about this, but I now feel increasingly more like, if you want to make strategy games that people will actually play, you have to almost do the exact opposite of start from scratch. You should find some existing specific popular game that people already like, and then figure out the stealthiest way to make it secretly a good, deep strategy game.

The other problem I foresee is that yeah, while you're in this super abstract form like you are in the "Here's an application of these basic principles" section, it works. But I feel like once you get SPECIFIC enough to implement, and COMPLEX enough to be a good strategy game, this whole idea of starting from scratch is going to get exponentially harder and less practical. You're going to need some thematic guard-rails, and not just thematic guard rails, I would say, but like "existing game guard-rails" if you want other people to play it (back to my first objection).

At the very least, I think that this is an interesting academic project and worth thinking about. It may also be useful for designers in just shaking up their view, especially if they're like most people and have a pretty myopic view of what games are. For me, I feel like I have the opposite problem, where I am sort of fundamentally coming from this like elemental, from scratch perspective, so maybe this is less useful for me than it would be for others.
 
#4
Keith, I don't think that this is how one should design strategy games. I don't think you should start from the ground up like this and work so abstractly. It's way too cognitively expensive and you'll probably design a game that's really hard to understand for players, as well. I agree with you there.
I am pursuing "from scratch" so that I understand what a solid skeleton of a game actually consists of. So I can design games with a solid skeleton, and more easily identify weaknesses in the skeletons of other games I'm interested in borrowing from. All of this is so that I have a clearer idea of why I should or shouldn't make certain design decisions.

Can you expand a little on "R, P and S can represent low level strategies which consist of three parts, two parts are shared with other strategies. I got lost in your example here.
Low-level strategy just means they're like units you could build with resources in an RTS. Something like that. The idea is that you start with the "concepts" that have the non-transitive relationship, then you add in details to complexify the situation until the game becomes non-trivial to solve. So you add in resources that you could spend to make R or P happen, and you institute different payoffs for winning with R, P, or S that shift as you exploit R, P, or S to win subgames--that kind of thing.

You would not actually do this abstractly like I did. You'd have some theme and identify concepts that fit the pattern, then identify resources you could build those concepts out of (if you wanted to have one game element per concept). Or you could treat the non-transitive interaction as a high-level strategy concept you want to keep alive in your design, though I'm unsure that's as good as breaking things down a bit more.

On second thought, having such an example was misleading. I wasn't intending this as a serious way of designing games, but as a clarifying exercise to help people do game design without making as many mistakes. (Like if you design a strategy game that DOESN'T have non-transitive relationships and localization featured pretty clearly, you're probably on a road to failure in terms of depth.)