Timeworks (2024) was the first Steam release by Starworks Studios, a group of 11 Drexel students including myself. It is a singleplayer 3D puzzle-platformer, similar to Portal but with time-travel.
The original idea spawned from a game jam game I created in 2020. I pitched it to the team in October 2022, and we worked on it for over 15 months with support from Drexel's Entrepreneurial Game Studio.
I worked as one of two dedicated programmers, as well as a game designer and writer.

Recognitions

Process and Documentation

Inventing Time-travel

Timeworks is a game about interacting systems. It has a first-person character controller, like many other puzzle-platformers. It has an item-crafting system, which facilitates the goal of each level. The unique, emergent fun of Timeworks comes from how a player navigates and interacts with an environment bound to a time loop.Players have a limited number of time loops to repeatedly play a given level. Each time a player rewinds, they are effectively making a parallel “clone” of their character with whom they must cooperate and plan around. For instance, you may throw an item during the first loop so that you can catch it during your second loop.

I was responsible for designing, architecting, and implementing the time-travel system of Timeworks. Throughout this process, I had three important qualities to ensure:

Two Approaches: Recording Input or States?

My first instinct was to record the player's keypresses throughout the time-loop period. I would record the times they pressed or released any button, like when interacting or moving left. Theoretically, a clone using accurately recorded input would change its environment in a deterministic way, since it would pick up and use items at the same times and places.However, this approach had a problem. If any recorded clone were later physically nudged off-course, the timeline becomes inaccurate. There may be up to six concurrent time loops, so this butterfly effect could quickly spread until the level is in an entirely different state than how it was recorded. This time system, although Deterministic, was not Predictable.

Instead, I chose to record object states instead of player input. Several times a second, the system instructs every time-bound object to record a “key” struct representing its current state. Depending on the object, this key may include the object’s position or rotation. When later playing back the recording, keys may be interpolated for in-between frame updates so objects appear to move smoothly. This time system is also Deterministic, and hopefully much more Predictable.

The Non-Determinism Bug

The new system was working pretty well. However, we noticed during playtests that past clones occasionally failed to perform interactions or catch items in the way those events had been recorded. Although these instances were rare, the time system was non-Deterministic. This was a big deal. Players couldn’t trust the system to support them by accurately recreating their actions.

This revealed an invalid assumption I had made. When a clone performs an interaction, I would record it in the next key, which might be milliseconds later. I assumed that, since keys were recorded so frequently, and that the camera angle was interpolated between keys, this small time inaccuracy would be unnoticeable. However, players interacting with a button stand while moving their camera quickly sometimes caused the interaction to slightly miss the button hitbox when replayed.My solution was to record an additional key immediately when a clone performs an interaction. This ensured the clone’s camera angle was always pointed exactly the same way at the important moment. I watched many playtests after making this change and never saw the time-travel system behave non-deterministically again.

Rhythm games are usually about hitting buttons along with music notes. They are fast and reactive experiences. So, what would a rhythm-puzzle game look like?Synck is a game about synchronizing metronome-like shapes called “mets”. Each met may have a unique ticking speed and pattern. The goal of each level is to tap and start all mets at the right times so that they all have one simultaneous tick.

Synck was a solo project I made. With such an experimental gameplay premise, I had to rely on playtesting validation. At the first playtest, here's what I heard:

"Your game is too hard!"

Whenever a met ticks within 0.2 seconds of another met, a visual and auditory effect plays. With this, prototype playtesters apparently understood the premise and goal of the game to sync all mets. And they were having fun! However, they hit a recurring problem. Sometimes, all mets apparently seemed to tick simultaneously without being counted as a victory:

This is close, but not valid. Why? While each met ticks within 0.2 seconds of another met, they don’t ALL tick within 0.2 seconds of EACH OTHER.

How frustrating! Players suggested that I increase the time window. If I did, players would hardly need to be precise or strategic with their timings. The time window would be even longer than the beats themselves! I needed to find a more targeted solution that would still feel good and forgiving.

An Invisible Improvement

I suspected that Set Theory would solve this issue. At the start of the level, I put each metronome into its own “set”. Any time a metronome ticks within 0.2 seconds of a metronome from another set, I combine the two sets and snap the timings of all those metronomes together.

Functionally, my new implementation invisibly fixes players’ small timing imperfections as they start metronomes. This stops the imperfections from accumulating towards an almost-but-not-quite synchronization. When I showed this new version to the playtesters, they said it felt better because I made the timing window longer. I didn’t correct them.