A game development log where I share the hardest game design problems, and share thoughts on the games I'm playing. My name is John Rudolph Drexler and you can find my games at catacombian.com
John (00:08.846)
think is so cool and helpful and like helped me in a bunch of practical ways and I brought a visual aid. How do you like that? Sorry, people who are listening on podcast land. okay so I found this because I heard Jonathan Blow talking about this. Jonathan Blow, controversial figure who I disagree with on very many things in real life, but on games, he has some very insightful and interesting things to say and I love his games. and he was talking about this this
way of thinking about the game mechanisms in your game that and how to the importance mmm
John (01:01.55)
first heard this w listening to Jonathan Blow talk about how he makes some of his games. Jonathan Blow, controversial person with a lot of opinions, many of which I don't agree with. he can be a bit of a nuisance sometimes, but on game design stuff, I find him to be extremely insightful and interesting. And he talked a lot about in the
John (01:33.411)
Okay, I wanna talk about this really cool heuristic tool, diagnostic tool, whatever, for how to think about the mechanisms in your game. And I brought a visual aid. How do you like that? Pretty cool.
okay, so I heard about this initially. I've heard him actually mention it a few different times. Game designer, video game designer Jonathan Blow, who made Braid and the Witness and this new game, Order of the Sinking Star, I think it's called. Controversial guy, a lot of strong opinions, a lot of political opinions and things that I don't agree with. But when he talks about games, he's very insightful and I find it very useful listening to him. And he was talking about this framework, this kind of grid of game mechanisms.
that I'll get into the details of in a minute, that he basically said that he got this from Kim Swift, who is one of the legendary
writers, developers Valve who made portal. And I kept on trying to find where this original thing came from and I couldn't find it anywhere. So if you're able to find this, reach out to me and please let me know. shout out Kim Swift for coming up with this and Valve more generally. and thanks Jonathan Blow for tipping me off to it. And what the basic idea is is like if you make a grid here that includes all the major like mechanisms in your game, and then all the same things are the columns as well as the
You can basically map out like what are their sort of like mechanical relationships between all of the things in my game. So as I always talk about that, I a way that I always love thinking about this is like every mechanism in your game carries some like cognitive weight. and in the case of a board game, it also is like typically like a physical component, extra rules in your rule book, something the player has to keep in their frontal cortex while they play, something you have to explain.
John (03:27.344)
It's extra text. There's some significant weight to everything that you put in your game, every concept you put in your game, every mechanical rule, whatever in there, dynamic that's in there that has a name on it, right? And so the thought is in if it's going to be in there, it should be like a load bearing, exciting, and interesting thing. And part of that, and part of what this kind of framework teases out, is that it should have
mechanical, logical relationships with all the other stuff that's in your game. And so as you can see here, like it's difficult for me to see exactly what I'm doing here. what you can see here is like there's some like core ideas in my game like damage and healing or this whole system I just added of glyphs of of you modif you add these glyphs to the the the
Gollum to change its behavior permanently. you have these monolith shards, these magical things that modify the map, prophecy. These are rich concepts that, and you can see the little checkboxes out here that interact with all of the other mechanisms in the game. And actually it's a really this has been a really helpful heuristic for me to go back through like when I I recently in a recent episode talked about how I shifted to this whole glyph system and I wrote a whole bunch of them, was like, cool, this is cool, this is cool. What if you did this?
What you did this? It felt very rich and exciting. And then I was like, what am I missing here? I think there's some obvious connection that I'm missing. And I was like, glyphs and golem cards, or you know, glyphs and damage or glyphs and music or whatever it is. I could go back through and say, How does this logically and mechanically connect with everything else that's in the game? And I think basically what this helps to do is illustrate like what are the richest and most exciting
parts of the game that all connect together. and that is basically the core and the exciting thing of the game. And it provides this helpful way to go through and say, like, is this glyph idea good? And then go through all of the other existing stuff in the game and be like, could I make a glyph about this? Could I make a glyph about this? What is the relationship between glyphs and golem cards or whatever? And that ends up being a really fruitful way of kind of building out the mechanisms in the game. It's also a diagnostic
John (05:49.985)
Because there are gaps in here. I don't think the heuristic or the rule it should be quite as simple as just like, there should be a check in all of these boxes. But I think there should be a check in most boxes if it's going to be good. And what's the thing that stands out here?
A long time ago I put this concept of traps in the game and they've been there for kind of a long time. I don't love playing with them. They're okay. They basically slow the golem down. and they're kinda fun to play with. They're not like that fun to play with. It's like, cool, I've laid a trap and the golem slowed down. The problem is
There is no meaningful mechanical relationship between traps and anything else. They just kind of exist on an island. It's just a thing that can slow the golem down. Is this a problem?
Not necessarily. is this bad game design? Not necessarily. Like maybe it's so fun that it doesn't really matter. But it does bother me because all of the other parts of my game are so tightly integrated and so complementary of one another. And golems are this just this or sorry, the the tr and and traps are this thing that just kind of exist out on an island and don't touch anything else. And so I think what it prom
Me to do is either to say, one, take it out of the game. It's just not rich and exciting and cool enough. It's like, hey, here's this extra rule, by the way, it's traps and they don't interact with anything else in the game. Maybe, maybe leave it in there, maybe take it out. The other option would be to redevelop that into something that is like richer and more exciting that does interact with all these other things. and I think I'm actually leaning towards the former rather than the latter.
John (07:35.491)
But this was such a helpful exercise. My actual spreadsheet doesn't just have like eight things on it. It's got like twenty things on it. there's not like that many mechanical things in the game, but I have it a lot more refined where it's like healing and damage and all these other things kind of parsed out each under their own row and column. So it's this huge crazy spreadsheet that I'm maintaining that helps to show how it all connects together. and I think a good game is one where it's like you like everything on
The sheet and everything on the sheet connects with everything else on the sheet in some sort of meaningful mechanical way. anyway, short episode, but I really love this tool and wanted to sh share it. So shout out Kim Swift, shout out John Blow. Game Mechanical Matrix TM. We're gonna name it here now.