jam23

HL / AD / left right  => move
space (hold, release) => jump
enter / return        => convert to block and end time loop
left shift   (hold)   => expand field of view
left control (hold)   => contract field of view
R                     => restart time loop, clear current gate

input ticks at 120 fps.

all spoilers

jam23 is a short experiment in time travel, time paradoxes, and the create & play loop loosely inspired by the countless hours I spent playing trackmania sunrise as a kid.

it is a racing platformer in an 'open' world. every life must end by modifying the world in some way--this is how you create the track. whenever an agent converts itself to a block, time resets from the beginning and you play alongside yourself, using previous versions of you to reach various 'time gates' scattered throughout the map.

a time gate is a special device that returns you to the point in time marking the beginning of your first run (time trial) to itself. this allows you to essentially build a platforming level off the backs of your previous characters, and then run it over and over again against yourself. every time you find and pass through a new gate in the world, you start another run: another loop.

of course, modifying the world has consequences. if you mess with the path of time, and someone sees it, you might cause a paradox. there are fundamentally two kinds of paradoxes. check out the section "what is going on" below for more info (or just launch into the game and figure it out).

because 'seeing' stuff is so important for time paradoxes--if you didn't see it, it didn't happen, after all--each character has a field of view that determines what is visible to them. you can control this yourself, with sightless runners hopping blindly from block to block, or all-seeing agents, immediately invalidated by even a hint of timeplay.

meta

jam23 is a game made in ~24 hours for an 'unannounced' collective project.
the prompt was the following:

- motivated by a well-known game genre
- there is always something for the player to do
- two week deadline
- no time constraint, but must provide an hour count
- must have at least one playtest before the one week mark
- embed a virtual world in a real one
- this virtual world contains three kinds of things
- players easily tell stories about this world

it was my turn to write the prompt this week. I threw in the first bullet to force me to make something recognizable as a game. the non-process bullets are more or less motivated by this blog post: https://blog.aaronsee.media/normative-creativity/

certainly a tall order that I didn't expect to actually hit, but I gave it a go and had a fun time.

made in https://github.com/acgaudette/txtquad

tips and playtest notes

• gates are somewhat randomly scattered around the map. you probably won't see one immediately, but there is always a low-lying one nearby. they look like spinning orange diamonds.
• you can convert in midair! this is a good way of building long and challenging tracks quickly. I noticed that players might instead tediously stack blocks, one by one, until they reach a gate.
• R was a difficult action to communicate to players. there isn't much feedback. the purpose of this action is to watch the 'replay' of all time (i.e. all history, starting from the very beginning). this has the effect of creating 'observer' agents, which is neat. but really the action exists because I find replays to be the most fun part of the game: recording long sessions of building and racing, then watching it all go by.
  • replays are useful for another reason as well: they can be a good way to learn how the paradoxes work. you can shadow an agent that was invalidated, see what triggered them, etc.
  • all R really does is reset any active time gates, returning the start time to zero. however, it also trashes any active recording.
• gates actually go 'all the way up'. this was something the game had difficulty communicating during playtest.
  • the challenge / fun of the game ramps as you build paths that are longer and longer / higher and higher.
  • I observed players sticking close to the ground and making many short paths up to low-lying gates, instead of exploring from old ones.
  • there are various ways this could be addressed. for example, I could replace the infinite surface with a small island.
• you can use old gates as 'checkpoints' in a sense. passing through a gate will 'move' time to the point at which you entered it; this cuts down the time spent waiting for tracks to be built. alternatively, you can go explore somewhere else.
• there are 32 gates in the current build. I didn't put much (read: any) emphasis on completion, competition, high scores, etc. and maps regen at launch, but you can at least compare yourself against... yourself!

what is going on

paradoxes

• a paradox requires two ingredients: a 'write' and an observation of that write.
• there is only one kind of write in this game: converting yourself to a block. so, only block conversions can trigger paradoxes. if an 'invalid' write is observed, it causes a paradox. if a valid write is observed, there are no problems. so, we should define what makes an invalid write.
• there are two kinds of paradoxes: the 'simple' paradox and the 'expected' paradox.
• in both, we are essentially following a single underlying assumption: whatever you see (or feel)--at any point in time--must be a true representation of the world. the future cannot change the past.
• paradox 1
  • simple paradoxes occur when agents observe writes from the future. this is straightforward--if an agent sees something that "wasn't there" when "they were alive", then they should become invalidated.
  • this constraint exists because agents we have previously recorded cannot change their behavior to accommodate information that was not present when they were recorded.
  • an easy way to trigger this paradox is to record one agent, then record another. the second agent should convert at some point during the first agent's lifetime, while ensuring its conversion can be observed by the first agent.
• paradox 2
  • 'expected' paradoxes are a little more complicated. essentially they occur whenever an agent 'expects' to see another, but actually does not. this can happen if an agent depends on another for something, but the agent it depends on was itself invalidated, somewhere far far away and a long time ago.
  • one way to trigger this paradox is to record one agent that converts into a block, then record a second agent that moves away for a bit. after moving away, the second agent comes back and uses the first as a platform. finally, record a third agent, which converts within range of the first agent while the second agent is away. when the second agent comes back to use the first one, it will invalidate as soon as it 'sees' the missing agent.
• observational potential can be mediated with the FOV control keys. when left control is held, you cease being able to see anything. in this state, the only thing that can possibly trigger a paradox is touching an invalid block. when left shift is held, you can see just about everything, and are very vulnerable to the future.
• how are paradoxes resolved? recorded agents always get the short end of the stick, and the recording agent (the player) is assumed to be the source of truth. if a recorded agent is invalidated, it changes color (to magenta) and freezes in time. invalidated agents are always frozen at the point in time where they observed the invalid write. however, I also render a 'living shadow' (where they 'would have been') for readability.

timers

• two timers are shown at spawn, one above the other. the timer on the top displays the absolute, or 'world' time. the timer on the bottom displays the relative, or 'player' time. time gates will always send you back to a specific world time, but the player time always ticks from zero starting at the time they were 'born'.
• if a gate has been reached successfully at least once, it will display one timestamp next to it in orange: your best time or 'fastest loop' to that gate. note that this time is set from the player timer, not the world timer.
• at any given time, there are either one or zero time gates that are marked as 'active'. the last time gate you have entered becomes the active gate. the active gate takes on the color of the player and displays an additional timestamp under the best time. this additional timestamp indicates the 'warp' time, i.e. the absolute time at which the next agent will appear at spawn (either after a conversion or after entry at the same time gate).

platforming

• as long as you are in contact with a wall, you can jump
• holding a directional key against a wall will cause you to slide more slowly
  
• jumping while gripping a wall in this way will shoot you in the direction opposite the wall
• holding and releasing space will result in a stronger jump

discussion

the loop (after scaffolding) was more or less intended to be:

• explore: look for a new gate
• create: build a path (track) to your new gate
• play: race yourself on your new track
• look for more gates, starting from an old path (loop to first bullet)
• after a long linear run, press R and watch the replay

I would like to do a better job of encouraging players to create interesting tracks. one limitation is the physical model itself, but another is the single block type. having at least another block type, like a spike, would be interesting.

I originally wanted to do something more creative, with agents building things like houses and tunnels, bunkers and castles, then wandering around them together. I would like to explore that more in the future. in particular, digging--moving everything to a subterranean environment--sounds interesting.

this is why I didn't put any landmarks in the world or otherwise spend any time generating an environment for the player: I was attempting to channel the classic MC creative mode vibe. I didn't want to cash out and provide the player with premade track guides and templates in the form of static terrain features or buildings. this needs further development--the game doesn't feel effortlessly creative and constrained enough yet.

ultimately the conversion ability--while decent for making tracks--doesn't satisfy the requirements necessary for building interesting structures. and the racing regime does funnel the kind of structures that are ultimately built. at one point I think I was considering spinning this into a survival game (versus the environment, not versus mobs) and incorporating some kind of (e.g. food) resource that can span multiple timelines at once. or, this could probably work well with tower defense.

on a separate note, the platforming is too tight, the physics too constrained. I would like to experiment with a more dynamic and emergent control model, so that watching replays is more fun at the lowest level of engagement.

R should be better integrated with the gameplay. there is no mechanical reason to reset, so it becomes a creative tool rather than a necessary one. this isn't a terrible outcome, but I would like to bring the loop reset to the forefront since it plays a role in rubbing timelines up against each other and spawning branching paths.

of course, there are a bunch of crazy directions you can take the time mechanic. for example, you could enable players to embed themselves in paths from previous timelines (to ensure observation invariants) and allow splitting at any point. you could have gates that reverse or change the speed of time, and so on.

the same thing goes for observation. I could imagine plenty of interesting stuff with light, for example: agents carrying torches to illuminate other agents, agents from multiple timelines shuffling around each other in the dark, multiple senses, raycasted visibility, etc.

ultimately a lot more work needs to be done to consider how the time mechanics can play a larger role in fostering player narratives.