?

Log in

No account? Create an account

t3knomanser's Fustian Deposits

Probabilities and Game Making

How Random Babbling Becomes Corporate Policy

run the fuck away

Mad science gone horribly, horribly wrong(or right).

Probabilities and Game Making

Previous Entry Share Next Entry
Podlek
I got a bug up my ass the other day, and started working on making a set of rules for a miniatures strategy game. Being the sort of person I am, this is no normal combat game- it involves time travel.

Not the whimsical variant of time travel you'd see in a game like Chrononauts, where you're looking down on all of history and playing with it. No, this is a game about time traveling soldiers on a battlefield, where events from the future ripple back into the past and vice versa. Essentially, I wanted to do something more like Chronoton (awesome game, if you haven't played it, btw).

As you can imagine, it's a tricky game to design.


The players are stuck in the present, like you or I. We cannot predict the future, and we cannot alter the past. But time moves forward. Beside the main battlefield, there's a timeline board, divided into squares that represent "ticks". A "Time Vortex" marks the current turn. No one may travel farther back into the past than the Time Vortex. As each turn completes, the Time Vortex advances to the next tick (obviously, the timeline won't be infinitely long in practice, but it will be logically).

Now, let's say I want to alter the past. Well, I can't, now can I! I just said you can't go back in time farther than the Time Vortex. But my future self, who isn't here, can time travel back. So units from the future can travel into the present (and units in the present can skip ahead into the future, but that's far less interesting).

So, imagine we have lowly Pvt. Jenkins, fresh out of boot camp and faced with the confusing scrum of a temporal battle. She needs to carry a message across a bridge, but two snipers are on the far side of the bridge. She'll never make it across alive. But then- on the opposite side of the bridge, a second Pvt. Jenkins appears- from the future. At point blank range, she makes quick work of the snipers. The present day Pvt. Jenkins is now able to cross the bridge. The future Jenkins continues on to deliver the message, while the present Jenkins, once across the bridge, has to travel back in time to kill the snipers she just watched her future self kill (because she's going to become the future self in a moment).

Pvt. JenkinsP can't cross the bridge until Pvt. JenkinsF arrives from the future and kills the snipers. Pvt. JenkinsF can continue along normally, but now Pvt. JenkinsP must go back in time and kill the snipers (and become Pvt. JenkinsF as she does so).

If you didn't follow that, please, comment below. I'm trying to figure out how to explain this, because it's the crux of the game.

Now, the instant JenkinsF appeared, JenkinsP was committed to go back in time and fulfill what she saw her future self do. This idea of "commitment" plays a key role in the game. Let's try the story again, with some modifications.

Maj. Shaftoe is an experienced, grizzled sniper, and he needs to hold this bridge. When he sees Pvt. Jenkins approach, he gets ready to blow her head off. The cracking of a twig nearby alerts him to the fact that Pvt. JenkinsF has just appeared next to him. With a point blank shot, she kills his buddy, and is about to turn towards him- but wait! Maj. ShaftoeF appears a short distance away on the middle of the bridge, and fires at Pvt. JenkinsP, killing her. This means Pvt. Jenkins never survives to cross the bridge, which means she could never have gone back in time to become Pvt. JenkinsF- paradox!

Because JenkinsP died, she never fulfilled her commitment to cross the bridge and travel back in time, so JenkinsF could never have existed.

As odd as it may sound, I had an easier time figuring out a workable time travel system than I did working out a combat system. I've got enough of the rules sketched out that I can unit test them, but this raises another problem- with all these Dopplegängers running around, it's going to be a pain in the ass to track all of them. Which brings me to my real question: how would you rather track these sorts of things?

The options I've come up with so far are these:
Logsheet
This is my least favorite option. I don't want to make the players track lots of things with paperwork. It also means that you can't tell the state of the game without asking the other players, "Is this piece the Doppel of this one or that one? How many wounds does it have?"
Token madness
Lots of things have to be represented by tokens. Declarations to travel, commitments to future actions- these have to be easily seen and obvious to all players. But what about using tokens to track doppling? The advantage here is that one can have a bunch of generic "Soldier" units, for example, and identify which piece is Pvt. JenkinsP and which is Pvt. JenkinsF (and, since we could have all sorts of future actions, F1, F2, F3...). When JenkinsP departs for the past, JenkinsF becomes JenkinsP. This means establishing parent-child relationships via tokens, and that means the tokens have to be unique enough that every unit on the field could Doppel multiple times and you could still tell them all apart.
Pre-printed Planning
There's an absolute number of Doppels that could appear for any given unit. For some units, like a Time Master, it could be quite a lot. For your average soldier, it will only be 3 or 4. So perhaps I could print off a bunch of pieces all labeled "Pvt. Jenkins". The programmer in me balks at this approach- we're essentially hard coding in the numbers. I could drop a counter marked "0" on the first Pvt. Jenkins, and when she Doppels, I can put another Jenkins on the board with a "1" counter. When the present day Jenkins travels back, I can move the "0" over to the "1", the "1" to the "2", etc.

What other options do you think I could use? I'm preferring the last one in the list- it seems to be the easiest to track that's also the most visual. At a glance, you can see who's who, and where they originated in the time line.
  • Doppelgänger / Doppel

    (Ich bin Nazi der deutschen Grammatik!)
  • so, in your scenario with Shaftoe, is he buddy dead at the end of the round?

    • Yes, the buddy stays dead. That's why there's a paradox- events have happened (and we never undo events, because that would get confusing), so instead we punish the side that perpetrated the paradox with something Bad™.

      I haven't fleshed out the paradox rules, yet, but it'll be Bad™.
Powered by LiveJournal.com