For the past month, I’ve been working on my entry to the Idle Thumbs community game jam, Wizard Jam X. This is the final Wizard Jam, due to the Idle Thumbs podcast going into a long-term hiatus from which it may never awake. I really wanted to make something special for this one. I think I achieved about half of what I’d hoped to do, but I am reasonably satisfied with the result.
Without further context or explanation, I present Eight Seconds: Manipulated Through Time.
The concept of Wizard Jam is to take the title of one of the Idle Thumbs podcasts – or one of their several associated podcasts – and to make a game with the same title, which may or may not have anything whatsoever to do with its source material. Later Wizard Jams have diverged from this formula somewhat in order to keep things fresh, but I’ve always been a fan of this approach so I stuck with it. In this case, I chose the title “Manipulated Through Time”. I always find it interesting imagining to what degree we might be capable of representing time travel in video games – We have tremendous control of allowing the player to revisit everything prior to the current moment in the game, since we can freely record and play back those previous game states – but can we make it possible for them to interact with the future in a meaningful way?
Well, that’s still an interesting idea, but I wasn’t really able to robustly pursue it here because it turns out my hands were quite full with allowing the player to interact with the past – though the idea of these two interactions being equivalent is also presented. It was important to me to make it so the player interacted with that past in a meaningful way – not just as a static recording, but as something more tangible – and, in so doing, that also means that you are directly affecting your future self with the actions you’re taking now.
This is always true, just revealed a bit more explicitly here.
My original concept of the game was that every minute, time would be reversed. For each minute, you would interact with your shadow self, which was doing everything you just did but in reverse, and by so doing you would navigate puzzles and so forth. While thinking about this, I realized that in that first minute, before there was any shadow to interact with, the player would have no idea what was going on – and that even once the idea of the time reflection began to make sense, controlling your inputs precisely, with reversal in mind, for an entire minute would still be nearly impossible. The obvious solution was to shorten this feedback loop to a shorter period of time so it was more feasible to observe the results of your actions. I waffled for a while considering different time values and eventually settled on eight seconds as an appropriate length for the time loop. I also eventually ended up making variants on this time reflection idea – you’d have reflections that reversed the flow of time, or echoes that moved the same temporal direction as you but with an eight-second delay, or reflections that had an echo of their own, and so forth. This undermined the original idea of a time loop where you were interacting with yourself directly, but by the time I got to this point I’d forgotten that was the original idea – and only remembered just now, when describing it here. I included the duration into the title to make it a little bit clearer what was happening (the tutorial for a game can begin with the title!) and also had some slight visual changes with each tick and each “reversal” to add to that clarity.
Because the concept was so innately difficult to wrap one’s brain around, I tried to make the game’s other elements as simple as possible. I had some idea of physics puzzles, of raising platforms with your reflection in order to traverse them, of tossing items to yourself – and, while these aspects are not entirely absent, they’re all done within the incredible simple framework of doors, switches that open doors, and boxes that can go on switches. However, because the player can be duplicated, and because whatever the player is holding when they’re duplicated can also be duplicated, even the simplest of these can become remarkably complex in practice.
What I came to realize over the course of the project is that there’s two somewhat contradictory sets of goals at play: That which builds interesting and thought-provoking puzzles using the mechanics, and that which builds an interesting moment-to-moment experience using the mechanics. These aren’t entirely contradictory of course: The idea of a fraught cooperation with your past selves implies challenges to be surmounted, so developing the theme requires challenge and developing challenge requires use of the theme, but there are points where these impulses push me in opposite directions. For instance, a huge amount of clarity could have been added to the puzzle solving if I locked the camera into a top-down perspective and made the movement turn-based – but this would also reduce the sense of the self being reflected, and reduce your interaction to a player and a pawn rather than a player with an avatar representing that player. In this case, I made the decision to present the game in first-person early on in production before realizing these ramifications – so, in the end, it becomes more of an experience than a proper puzzle game, with most puzzles being solved by fiddling with the scenario until an answer emerges rather than actually being thought through.
When it came to the appearance of the game, I wanted something highly detailed but not necessarily realistic. I was imagining the hyper-detailed surreal scenes of Twin Peaks or the minimalist stop motion of the 1989 Oscar-winning animated short Balance, something that felt very physical and real but without any grounding in the physical limitations of reality. I ended up leaning heavily on a free (deprecated) 3d tileset called Simple Corridors – because it was free and had PBR (Physically Based Rendering) materials, which is a fancy name for including a standard set of rendering textures that approximate the appearance of real materials. I originally planned on having a few separate environments, but since I didn’t have the time or skillset to make this type of asset on my own and didn’t want to break the bank buying professional assets I ended up making every area of the game a variant on the first tutorial zone I created – which, honestly, was probably all for the better, since it added to the thematic idea of being suspended in time.
For the music, I wanted to integrate both reversed and unreversed instruments, and have it be at times unclear which was which – it was also, since timing was such a huge part of the game, an opportunity to convey the eight seconds conceit through another information channel. I could have, and perhaps should have, executed this as a static music track, but instead I created a simple adaptive music system using several separate music stems for each instrument, each being 8 or 16 seconds long and each with an assigned intensity value. Trigger volumes set the music intensity as the player progresses through the level, which randomly plays a random sample of the appropriate intensity at timed intervals – many of which are reversed versions of other samples. The basic idea of this worked really well, creating something that sounded more or less intentional and built over time – but, because Unity’s support for playing arbitrary sound samples is much less robust than it is for creating a dedicated sound emitter, I had a number of issues with controlling these sounds, from slight desyncs caused by frame timing to large variations created by the game being paused for the settings menu. Also, as I built the musical components out more the administrative overhead of managing even this relatively simple song structure became significant. It was a worthwhile experience, but I’ll likely try to integrate one of the existing middlewares for adaptive music next time I want to do something like this, just to have a proper editor at my disposal. All in all, I’m pleased but not entirely satisfied with how the musical component turned out – it sounds interesting some of the time, and seldom degrades into true cacophony, but it does sound like a slipshod implementation of the idea it represents – which it is. I decided that sound effects would just detract from the surreal experience, though, and didn’t bother with them.
Other technical difficulties emerged through the time reversal system itself, which should be a surprise to no one. Recording and playing back a character’s history is fairly trivial, but recording and playing back a history in a way that still acts on the world, and that can be acted on, is a more significant challenge. All values must be relative instead of absolute – and movement values must be relative both to the world and to the facing of the character. Partway through the project I decided to vary the levels by mirroring them and scaling them, and I hadn’t considered earlier on what effects this might have on game entities which existed within these worlds. The reflection of the player was modified by the transformation of the world it was placed in, which is thematically interesting but absolutely not my desired result. Suddenly whenever they were supposed to turn right they’d turn left, entirely because right and left had traded places in the world they were now put in. Other issues came in when I added the ability for the player and the reflections to grab and throw each other, which then created rotational feedback loops where, when the rotation of the character was recorded for the next playback, it would record both the player and the reflection’s rotation summed together. Some of these issues may still exist, though I tried to stomp out as many as I could – but even aside from the technical challenge of implementing a solution, figuring out what a solution even ought to look like was frequently a non-trivial design challenge. What does it mean to pick up or drop an item in reverse, and what effect should these actions have on the world? What degree of physical interaction between the player and their reflection enabled interesting outcomes, and what was unfeasible to implement? What was likely to break the game? I had to answer each of these, and though I ended up approaching most of these conservatively it was still an unpredictable game and prone to weird breaks which I had to take a few extra days to debug.
I’m happy with how the project turned out, but I don’t think my methodology was very good. I dropped everything to work on this, and I think the end result of that was unhealthier work habits and hours, a lack of focus, and a bunch of extra stress I probably didn’t need to deal with. Though this is the last Wizard Jam (for now?), I will likely participate in some other game jams in the future – and these tough lessons are ones I think I’d better keep in mind when I do.