I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the sixth episode on different game design approaches:
Welcome to the Adventure Mechanics Side Quest, and today, it's just me, Chandler. I've been hard at work getting some mandatory features into The Mapper, such as saving and getting chunking to work, so today I wanted to talk about different approaches to game design. For those who don't know, there are a bunch of different ways to approach game design. There are fundamentals that cross multiple different approaches and not all approaches are truly unique. So, what am I talking about? Well, simply put, it's the process that the designer uses to guide how they design the game.
So, the most fundamental design that I've found so far stems from how a game is defined. For the purposes of this talk, I'm going to call this the fundamental game design method. In this design approach, you see a game as a start point, a goal, some opposition with decisions to work around them and a ruleset to interact with. What is the value of designing from such a low level? To put it bluntly, you'll have to take nothing for granted. This is particularly useful if you are designing a simple, puzzle, or tabletop game. When designing for tabletop, specifically, you can't necessarily assume that the player will know the state of the game off the top of their head, so you'll have to distill everything down as much as possible to conform to some part of this game definition. And by having to put it into one of those very limited fields, you'll have something ready very quickly. As soon as you have something more complex, however, this will quickly become unwieldy. An RTS where there are many decisions or a casual game where the goal is nebulus at best won't really be nice to work with in this framework. Explicitly writing every rule and how the player can interact with them is also going to become quite tedious, especially if it's going to be taken care of by a computer. This can quickly double the workload and extend the design time beyond what is acceptable to get the game out. That being said, being aware of this fundamental game design method is incredibly handy, especially when making small or simple games.
Let's say that you don't have a simple game in mind, but still need to have something to work from. What could you use then? Another option is to abstract a bit higher up and use transactional game design. In transactional game design, the core of the play space is between the player and the game itself. That means it focuses on Mechanics, Feedback loops, interaction between the player and the game, player agency and action verbs. This is more useful for making more interactive games. What are the core mechanics you're going to use? Take a look at the list of mechanics you wrote out. With this style of game design, you look at what many consider game design, like how a game feels, how the mechanics interact with each other and how it's all shown to the player. In this context, it's not one type of player, specifically, but rather, all players in general. Transactional game design is focused on the interaction of the player with the game itself. This attitude towards game design is especially useful for action oriented games, such as twin stick shooters or platforming games. All of the focus being on the interaction of the player with the game forces the designer to really make sure that everything added makes the game better.
Transactional game design isn't the only game design method that focuses on the player interactions and mechanics, however. One other popular game design methodology is design pillars. For design pillars, the core idea is to focus on the primary aspects the game should have and how the player will interact with the game. The pillars can be a feeling, mechanic or game style. Moreover, pillars can be modified and added as development progresses, with some caveats. Why use this design methodology? It's a zoomed out view that allows a designer to make sure that the whole project is working towards the same vision. If a developer is going to add something to the game, they will need to cross-check that added mechanic against the existing pillars added and make sure that it still follows the design goals of the original design. If it's not in service to one of the pillars, then adding it isn't usually a good choice. The drawback to this high view of the game design process is that some of the smaller details can get lost.
Let's say your game isn't small or fast paced. What if you want to look at specific players and a more meta-level play level? This is where situational game design can come in handy. In situational game design, the play space is more focused on the player. Situations, contstraints, anticipation, interpretation and finding meaning are all explicitly given focus in situational game design. What is the player doing/thinking about while waiting for their turn? How are they engaging with the game when they sit back and think about their next action? These are all areas the designer will consider when using situational game design. In this method, the constraints are things like the ruleset, controls and visual representations. It can also include the constraints the player may put on themselves as well, like additional challenges or thematic constraints that may not actually be in the game. This is particularly useful, since it can inspire more mechanics and aspects that fit the game. This builds into the core loop that situational game design uses: With constraints, moves and situations, a designer can come up with a compelling game loop. The constraints structure the situations that the player is put into. Situations offer the player a variety of moves to take and moves ultimately alter the constraints that the player will have as they move forward in the game.
So, let's say that you start out making an intentionally difficult game, one that demands the player to have some familiarity with your game. You can't exactly expect them to know the ins and out of your game from the start. So how do you get the player into your game? One design approach that lends well to this game style is rational game design. For this design methodology, the ultimate goal is to keep the player in a state of flow. What is flow? The cliff-notes explanation of this concept is that you want to keep the player in a goldilocks zone where the game is just the right difficulty. It's not too hard that the player is frustrated, but the game is not so easy that the player is not bored by the experience. How do you keep a player in that flow state? It requires the designer to consider the main gameplay loop and make sure that there is enough there to keep the player engaged and that it's the right difficulty, or at least gives the player options on how to solve a situation that matches their skill level. Early on in the game, the challenge level should be just above tutorial, since the expected skill level will be low. As the player makes their way towards the end, the difficulty can then build upon the previous completed challenges, ideally culminating in the player mastering the game itself by the end. This particular approach to game design lends itself to linear games, like a story-based shooter or tower defense style game.
This is by no means all the methodologies for game design, but these are the ones that I have found to be most useful for me. So, the ultimate question is what game design methodology am I using for The Mapper? For my purposes, I've been using the design pillars. Instead of focusing on mechanics as my design pillars, I've been using the thrill of discovery, non-violence and cartography as the core of the Mapper. The Mapper obviously began as a game about cartography, so I had to make it one of the design pillars. The thrill of discovery ties nicely into the same, since mapping the unknown isn't necessarily the same thing, but still close enough to my first pillar to complement it. My final pillar that I wanted was non-violence. There's no part of cartography that necessitates violence, and I didn't really want to cobble a combat system to the game, especially if it could potentially overtake the primary goal of making a game about cartography. In the end, these three pillars were enough to make a compelling game for me. All of the mechanics that I have added to The Mapper so far have been in service to these three pillars. Despite me using design pillars as a primary framework, I have used the other design methodologies at various times as needed.
As for the latest build of The Mapper, I do have something for you this month. I still don't have all the mechanics implemented, yet, but I do have a large step forward in terms of the look and feel of the game. I have implemented the rudimentary save system, along with a flag system to allow players to place on both the map and in the world. There have also been a number of rather large changes on the back end, but in the end, that's to make my life easier and not necessarily visible to the player. I am also going to be releasing The Mapper onto Itch.io moving forward, since I feel that it has progressed far enough along to be somewhat presentable to a wider audience. If you have any feedback or suggestions, leave a comment! Any and all feedback is going to make The Mapper better.
That's all that I have for this Side Quest. As always, you can find me on Twitter as @jcsirron. This has been The Adventure Mechanics, and I'll talk with you next time.
Bibliography:
Designing games for Game Designers: https://youtu.be/ke_kOD2D-bs
An introduction to Situational Game Design: https://youtu.be/K4xfduXlM6s
ThursDev: Game Design Pillars - Better design through definition and restriction: https://youtu.be/_EtxKlctpXw
Rational Game Design: https://amberstudio.com/whitepaper_post/rational-game-design/
