Creating turn-based mechanics: advice on how to practice using paper?

I'm an aging hobbyist who has made a few small games in GameMaker Studio 2 (a Tetris clone, a chess engine, a terrible deck-builder), and a 5-minute visual novella in Ren'py. I'm semi-retired, and I don't need to do this for money. I just like playing and making games. I'm mostly interested in turn-based strategy games, 4X, XCOM-type things, wargames, tycoon/management, RPGs, card games, adventure games. With arthritis, I tend to avoid real-time games, though I did have fun testing my take on Tetris. I don't love puzzle games.

Anyway, I can't beat the first level of game design -- creating an interesting game loop. It's one thing to clone someone else's, as with Tetris and chess. It's another to try to create one's own, as with my terrible deck-builder. For that game, I made several prototypes with index cards, and I coded variations, and it never grabbed me. The decisions weren't interesting. This week I've made a few paper-and-dice prototypes of a management game (deploying scarce assets to stave off a threat), and each iteration was as uninspiring as the last. Either my system's reaction to player input is too obvious or too weak, so either way, the player's decision is not interesting.

I'm reading "The Book of Lenses," which has some good ideas on how to practice prototyping with paper. Last year I read a book with drills on making board games, which helped some. Can anyone point me to exercises to develop my skill in this area? Or offer any advice generally? (I'm posting here because I think it would be fun to learn Unity as part of my next project, but also because this design forum here is much livelier than the equilavent forums in Godot or Gamemaker.) Thanks in advance.

 

I think the fun decisions to make are when there isn't clear best. Rock paper scissors stands the test of time because which is best? Nobody can figure it out.

I'd limit variables to three or less, try to get something that simple working, and only add one tiny thing at a time and then test thoroughly to make sure fun is still there.

I think it's just too easy to try and juggle too many balls at once and get overwhelmed - lose sight of bigger picture.

When player makes a decision then there is anticipation to see what the result will be. Ideally, before the result is delivered, then a new decision has to be made. This way all questions are never answered. You have to keep playing.

Same pattern used in stories, movies, etc. Raise one question, let player see the answer is almost coming, raise another question, answer the first.

How many questions player is working to answer at a time is probably what determines how fun the gameplay is. Too few and its boring, too many and they check out so it gets boring. And obviously they have to be intrinsically interesting questions.
"Did I doom Bill to death?"
"If Bill is dead, can Bob make it?"
etc.

In the end it's all just numbers but nobody wants to just balance spreadsheets. A touch of humanity, I think, is what separates the real winners in the genre. In some cases, even games that are kind of poorly balanced as games still win for players because they create stories and characters people love. So even if you are making chess with a twist, some touch of character may still be the deciding factor between a ho-hum game and something special.

I think I'd start by copying other games, and then try to change up the recipe until it resembles something new entirely. But still keep to extremely limited number of things to juggle. So strategy games where you got like 30 units and you need spreadsheets to balance numbers would be something I'd avoid.

 

Thanks for that very helpful reply. I like your idea of limiting variables to three or fewer. In my deckbuilding game, I had a half-dozen variables, some of which really didn't do anything, and I got overwhelmed. When I brainstorm, I'll tell myself "keep it simple," but before you know it I've written a page and a half outlining a complicated 4X-meets-RPG kind of thing, or a detailed description of an XCom in the 19th century, or whatever. Always too complicated!

I'm also interested in your suggestion of giving the player a second decision before the first decision is completely evaluated. I will think more on that. In the Civ games, we make a research or construction decision and may not know whether it was the right call for many turns, if ever. Even chess is like that in some ways. Sure, you know exactly what the immediate result of your move is, but even the greatest masters often can't predict whether that move will look good five moves down the road.

Anyway, I appreciate your taking the time to respond. If others have comments, please feel free to weigh in.

 

I recommend thinking about ways to get your game mechanics in line with the "fantasy" of the game. In Jagged Alliance 2 for example you're commanding a group of mercenaries that would fit right into an 80s action movie. The choices you can make in that game and the mechanics help sell that fantasy. E.g. some of the mercs don't like each other and don't want to work together. In context of the theme it makes sense and helps sell the fantasy, but in a game like x-com it would be just annoying. Personally I consider JA2 the gold standard for turn based tactics, you might have your own favorite. There is a book about JA2 with some insights into how and why they designed some aspects of it. It's not heavy on gamedesign lessons, but maybe it still inspires you in some way:

https://bossfightbooks.com/products/jagged-alliance-2-by-darius-kazemi

And check out "Into the Breach" for a small scope turn based tactics game from the makers of FTL.
https://store.steampowered.com/app/590380/Into_the_Breach/

 

Definitely continue with the paper prototyping first. You have a good instinct there. If it's not fun on paper, then the extra challenge of translating it to run on a computer isn't going to change that.

The Game Design Round Table podcast is a treasure trove of information and ideas -- especially for turn-based games since they cover tabletop games as least as much as videogames.

 

I like to think in terms of "objectives" and "challenges". What are the things the player is trying to achieve? And what things make it hard to achieve those things? Then I can come up with a list of actions the player can take, and pick ones which give rise to sets of seemingly interesting choices. Being inspired by the theme (or: the fantasy) helps a heck of a lot.

Objective: figure out who committed the murder. Challenges: witnesses and suspects lie, evidence can be ambiguous. Actions: ask questions of suspects / witnesses (select person, select question, get clue if successful), search for evidence (select room, select focus point, get clue if successful), accuse (select person, means, motive - must get all correct). The writing of the mystery might be able to make it work, but mechanically it's pretty boring because with patience it's easy to reach a "best" outcome even on the first try - just try all possible questions and searches, then the clues definitely have the answer.

So let's throw a spanner in that. New challenge: you must evacuate due to an incoming storm. This gives the player only 20 moves to investigate, then they are forced to make their accusation. This means they can't ask all questions and perform all searches. That has two implications. First, they are going to have to make their accusation with incomplete info, so choosing what info to gather is important. Second, clues now have two purposes: identifying the killer, and also hinting at what to ask about or where to search. It has seemingly made the repeated "what do I do next?" decision far more interesting because a) you now have to choose (you can't just do them all) and it now has stakes (your choices determine how well equipped you will be for your accusation).

Assuming that works in testing, you could tweak the time challenge to add another layer: give players a reason to accuse early. Now they're constantly choosing "accuse now or get more clues?" Easy decision early on, but later? Now it's a dynamic element (it changes as the game progresses).

Brainstorm many actions / challenges before mentally experimenting with different sets. Think about different ways you can express each before settling on one, and maybe try more than one. And as someone already said, minimise how many of each you use.

 

Thanks for those really helpful replies. @Martin_H , I played the heck out of JA2, and I had no idea there was a book about its design. I'll check it out. I've read a Vice article discussing the book. It sounds very useful. And yeah, that's my kind of game! I hadn't thought about it in years. I stared at that UI for hundreds of hours, hehe.

@TonyLi That podcast seems awesome. I'm listening to an episode as I type this. I'm not listening to anything these days, so I'll fire it up while exercising.

And yeah, the cards and dice do help. Today I had an encouraging dice-and-cards session. I had the player make a choice, then rolled a die that partly determined the outcome of that choice, which in turn gave the player partial info on whether her choice was optimal, which in turn gives the player a new decision, which is followed by a new die roll, etc. For the first time, I found myself smiling as I was playing this little "game."

@angrypenguin Thanks for that thoughtful post! As it happens, I spent an hour reading about the "Sherlock Holmes Consulting Detective" series today. (I'm thinking about buying it to play with my adult son.) It sounds like it incorporates some of the time-pressure mechanics you described.

 

Good call on Lenses, can’t recommend that book enough.

I would definitely make sure you know A* (aka, A star) pathfinding. It’s crucial to tile TBS game design.

As for making something interesting, I’d try to make something minimalistic that works then layer in top of that.

 

Thanks for your reply. I have implemented A* pathfinding before, in a little wargame I wrote in Game Maker Studio last year. It's an ingenious algorithm that I never would have thought of myself. I've spent a lot of time looking at Amit's site on hexes, too.