I’m going to spend next Friday to Monday making a game. I was inspired by Oryx’s 16bit sprites, they’re a beautiful, cheap resource for game prototyping (the license is a bit confused for business purposes). I’ve been wanting to (and failing to) make games for years, so I’m going to ensure I succeed by defining the game by the time I spend rather than the infinitely long wish list plan I can invent.
I’m going to make a turn-based strategy multiplayer game of capture the flag. (I’m partially inspired by the old DOS CTF game and also League of Legends, but mostly by the lovely fantasy art.) I don’t want to go into too much detail about the gameplay, suffice to say that it’s largely about making good decisions with very incomplete information.
I have a public Trello board with design notes and my to-do list. If you’re curious to follow along, watch that or follow me on Twitter. That public board accepts comments and some items are tagged as open questions, so please do contribute your thoughts.
Visibility and Randomness
Making the most of limited visiblity is the core of the game, directing your units to evade notice while searching out your opponents. This mechanic needs to feel believable at first play and be simple enough for experienced players to think through in detail without painfully slowing down the game.
Visibility starts with a unit’s Sight stat. Then subtract the visibility penalty of intervening terrain. If the resulting number is higher than another unit’s stealth stat (modified by whether they’re running or hiding), they’re seen. Here’s an example of a knight with 28 sight looking across some terrain to perhaps see a rogue with 7 stealth standing in some trees:
This is where randomness might come in. Maybe instead of a simple subtraction, the searching unit could roll 4d6, or the hiding unit could roll for its stealth score, etc. The searcher might be unlucky and miss a poorly-hidden unit, or get lucky and see even a well-hidden one.
This would allow for false negatives: the searcher might be wrong (“false”) in thinking they see no one (a “negative” result). And it opens the door to adding false positives: occasionally display a unit where there is none, just to confuse the searcher. With the randomness, the player must wonder if the unit they saw for just a turn was a glimpse of a well-hidden unit or a mistake.
Rather than keep digging into that, let me explore other opportunities for randomness. Though I doubt I’ll be able to fit it into the weekend, I’d like to randomly generate maps.
Each player will control five or six units in each game, but I want to eventually have something scores of character classes (but only three or four this weekend). So there must be a selection process of some kind, which I’ve created a Trello card for.
I’m leaning strongly towards the Highgrounds-like system, where a player selects a pool of 10 characters and are given a random five when the game begins. Perhaps a new, unused charackter will be chosen to replace units that get tagged out. The player will have choice in team composition, but also have to adapt to the circumstances. (If players have perfect choice in their squads, it’s likely a few combinations will come to dominate unless the game is balanced incredibly well.)
Internal vs. External
I’m averse to randomness in visibility (or tagging, for that matter) but eager for randomness in maps and squads. I’m writing this post after kicking around game design ideas with @karstencode and @sourcecodenomad all day and struggling to articulate why.
After writing all this, the best I can explain is that the difference between randomness in visibility and in map or squad selection is whether that randomness is in the core game actions or not.
When the map or squad layout is random, that’s external to the core mechanics of game. It sets up the circumstances under which the players act rather than tinker directly with their ability to execute on their plans. I like Chess960 for similar reasons, randomness changes the early game from a test of how well the player has memorized standard openings to dynamic reaction to changing circumstances.
What I really don’t want is for the outcome of a game to be based on randomness. Late in the game a single missed spot, false positive, or other quirk of fate could push a pivotal unit out of place and cost a player the game. I suppose another difference is that the places I like randomness are the setup of the game rather than during interactive gameplay.
I’m having a lot of fun designing this game and talking through tradeoffs with friends. If you liked this glimpse into the process, please drop by my Trello board to see more and throw in your two cents. And watch this space; I’ll be tweeting and liveblogging as I go.