next »

[Bryan Gale]

Hello! I'd like to introduce my game Induction, a puzzle game about using time travel to create strange loops of cause and effect.

The goal of each puzzle in Induction is simply to get to the exit, and your first ability is to jump back in time to the moment you entered the puzzle. This allows you to co-operate with your past self (or selves) to find a path to the exit. You also need to keep the timeline consistent - anything that travelled back in time in one run must still travel back in time in the next run.

With later puzzles and abilities, things get weirder, with solutions that require creating self-sustaining time-loops, where your past self depends on your future self, but your future self depends on your past self.


Goals and Inspirations

The biggest inspiration behind Induction is films such as Terminator, Bill & Ted, Looper, etc., that show interesting consequences of time travel. John Connor's causality-challenging parentage is a particular inspiration for Induction's loop-building. While these films are cool, they suggest a not-quite-realised coherent model of time travel, which is sort of frustrating. So that gave me something I wanted to address with my game, I wanted start with with an 'honest' model of time travel, then see what puzzles fell out of that.

Of more amorphous influence, Gödel, Escher, Bach by Douglas Hofstadter for the general idea of strange loops. And then The Last Question by Isaac Asimov, and Walking On Glass by Iain Banks. The endings of these two each gave a feeling that I hope to capture a hint of in my game. I don't know how yet, but I'm mulling over ideas for the overall structure.

Background

I've been working on Induction on-and-off since October 2013. The game has had a lot of playtesting, experimentation and revision to get to its current state, a short, well polished demo, with mechanics that I'm actually happy with and can communicate to the player. Generally, revisions have been in the direction simplifying the design, and then simplifying it some more. Stuff I've ditched from the game along the way is probably a post in itself.

I've shown Induction at a few events, with EGX in London being of particular significance to the game's development. Induction getting accepted into EGX is probably the reason that it's in any fun state at all. Without the motivation of an unmovable date that I'd be exhibiting the game to a huge number of people, I suspect I'd still be flailing around down design dead ends. It was also significant for being the first time I'd shown the game to a large mainstream audience. As well as being a good opportunity to gather play testing data, it was incredibly motivating to see so many people play and actually get my game.

Technology

I'm developing Induction in Unity, though I'm not touching a lot of the Unity magic, and instead treating it as a nice cross-platform C# runtime. I'm focusing on developing Induction for desktop platforms at the moment, though I'd like to release it on everything I can. It's running pretty nicely on Vita at the moment, though I've yet to have any official contact with Sony.

Next Steps

I've a few low hanging fruit to implement early this year. The most significant is allowing multiple jumps through time. Much earlier version of Induction had this, though I disabled it because players were getting confused and I realised I'd have to delay introducing it until later in the game. The rest of the game has moved on in its absence, and it forces some extra design decisions about my model of time travel.

The big missing feature at the moment is the outer-game, the overall structure connecting the puzzles. I don't want to do a full overworld (this is one of my tried-and-dropped features) or link the puzzles in a single continuous world (also tried and dropped), but I really really don't want to have some dry level-select menu. Sokobond and English Country Tune's level selects feel roughly like the kind of thing I should be aiming for.

Beyond that, lots and lots of puzzles. Or as many as makes sense...


Thanks for reading my first post, hopefully I'll have a progress update soon

[valrus]

For an "outer game", it might be cute to have "ghosts" of previous level-select cursors running off and selecting levels that you've already completed, as if after every level you're sent back in time to the beginning of the "outer game", and are choosing levels in parallel with your past selves.

It could be a purely cosmetic effect, but would reinforce a thematic connection to the inner game.

[Bryan Gale]

Hmmmm. I do want to do something like that - the mechanics of the inner-game seeping into the outer-game (and visa-versa). In general, I like the idea of 'layer breaks' (not sure if there's a proper term), like in eXistenZ, when the boundaries between the different layers of reality get muddled. Though I do want it to be more than a cosmetic thing.

The idea that each time you exit a level, you're back at t=0, I like that, one to think about...

[Bryan Gale]

Update #1 - Path Markers

Something I've been working on in the past couple of days is path markers. When your player cube jumps back in time, these show where the younger version of yourself will travel. I actually had these in place ages ago, back when Induction had an entirely different art style, but they were one of the things that got left behind in the transformation.

Here's the markers in action:

If you switch cubes to take control of your younger self, the markers will dissolve:

They also indicate when your younger self is obstructed, though I'm torn on how to animate this. This was my original approach, though I've had feedback that it's too subtle:

And this is an alternative approach, which I think is clearer, but doesn't indicate direction of motion as well as the first approach:

Next update will hopefully be on enabling multiple time jumps, and the design problems that raises.

[Voltz.Supreme]

I like it! Looks great and seems like an interesting game.

[bdsowers]

I can't wait to see multiple jumps in action. I feel like this is where your game is going to start to *look* interesting and be fun to watch. One jump probably makes for decent gameplay. Multiple jumps probably make for interesting play & a nice YouTube video.

though I disabled it because players were getting confused and I realised I'd have to delay introducing it until later in the game. The rest of the game has moved on in its absence, and it forces some extra design decisions about my model of time travel.

Wouldn't delay that feature too much. I feel instinctively (I may be wrong) that it'll be one of your game's hooks and something worth letting the player toy with sooner rather than later.

[thelastonestanding]

The game seems really fun to play and in my opinion you have found the perfect combination of colors. I look forward to the next updates

[Paul]

Nice work! Really like the look and the concept and there's a lot of potential for different types of puzzles playing with large multiples of your past self.

I'm playing through Super Time Force at the minute and although its a completely different genre, the core concept is similar so might give you some ideas. Using your past self as a platform to get up to inaccessible planes might also lead to some early puzzles to get the player used to the concept

[Bryan Gale]

Wouldn't delay that feature too much. I feel instinctively (I may be wrong) that it'll be one of your game's hooks and something worth letting the player toy with sooner rather than later.

Heh, that was my instinct for a long time, but from playtesting I'm pretty comfortable holding it back. I originally wanted to give it to the player right from the very start, and it took a lot of hearing no, seriously, make it easier before I finally caved and made a build with single-jump only and a set of puzzles around that, and that was when people actually started getting the game.

Part of the problem is that there are so many things that can go wrong once you have multiple copies of your player cube, which you can deal with once you have some idea what's going on, but are super confusing at the start. Like it's fairly easy to end up with a deadlock situation, where two past-player cubes are blocked trying to move into the square occupied by the other. There are solutions, but it quickly turns into workaround upon workaround.

I'm playing through Super Time Force at the minute and although its a completely different genre, the core concept is similar so might give you some ideas. Using your past self as a platform to get up to inaccessible planes might also lead to some early puzzles to get the player used to the concept

Super Time Force is something of an anti-inspiration . I totally totally don't mean that as a diss, just very different aims . This talk by the devs was a good reference point for the kind of things I didn't want to do, basically adding complexity to try and make readily intuitive something that isn't.


Thanks for your replies! Proper devlog post to come tomorrow, should have some nice gifs of multi-jump working .

[marcgfx]

Looks cool, it reminds me strongly of a mobile game called edge (iOs 2008). Maybe you can get some inspiration from it. I like the idea of using your past self and that you get to interact with it.

[Bryan Gale]

Update #2 - Multi-Jump

I'm now allowing multiple time jumps. The max number of jumps allowed is currently configured per-puzzle.

Portals

The 'portal' effect you can see in the gif is one of the things I'm most pleased with in Induction. I'd rejected doing a straightforward rewind effect, since you can rewind anyway and I wanted time jumps to be marked with a distinct effect. (Like Braid, you can rewind arbitrarily, but it's not something that gives you any extra puzzle-solving power, it's simply for convenience). I'd been trying to present the temporal leap as a spacial one - the entire world geometry scrolled down, revealing a new, reset, copy above, as though the timelines were literally stacked on top of each - but I couldn't get to not feel jarring, and so gave the portal effect a try.

I first tried to go for the same effect that Willy Chyr wrote about for Relativity where a sphere expands from the player's position, revealing the new timeline. But in an isometric game, and where there are geometry changes as well as texture changes occurring, it just looks off. It was though promising enough for me to try flattened version of the effect, which is what I have in place now.

To achieve the effect, every shader in the game takes the parameters _BoundaryCenter (the center of the portal in world-space), _BoundaryRadius (the size of the portal), and _BoundarySide (1 or -1, indicating whether to render the scene inside or outside the portal). Then for each fragment, I use these to calculate if we're inside or outside the portal boundary, and discard the fragment if we're on the 'wrong' side. I also do some blending over the distance of a single pixel to get some nice anti-aliasing on the portal edge. Here's a snippet of my shader code:

Code:

float4 frag(fragmentInput i) : COLOR
{
	float2 radius = i.viewPosition.xy - i.viewBoundaryCenter.xy;
	float radiusLength = length(radius);

	float boundaryDistance = (radiusLength - _BoundaryRadius) * _BoundarySide;
		
	float fade = smoothstep(-_HalfPixelSize, _HalfPixelSize, boundaryDistance);
		
	if (fade == 0)
	{
		discard;
	}
		
	return lerp(float4(1, 1, 1, 1), i.color, fade);
}

When rendering the scene, I first render the timeline the player is currently entering and the timeline the player is leaving, with _BoundarySide set to 1 and -1 respectively.

I then render the 'small' portals, the ones you see when a non-player controlled cube jumps through time, or when I want to indicate that something in the timeline you're trying to jump to is blocking you. These are each rendered with their own Unity Camera instance, with the camera.rect property set to the bounds of the portal. First I clear the depth over the area where the portal is to be rendered, then render the revealed timeline with _BoundarySide set to -1, so we only draw inside the portal.

What you see through each portal is a distinct running simulation. Right now it gets a bit chuggy when there's lots of open portals, but it should be sufficiently optimizable that it's ok .


Models of Time Travel

I want to write a bit about how multi-jump has changed the model of time travel I use in Induction. I'm not sure if any of this will make sense to people who haven't either played the game, or lived inside my head John Malkovitch-style for the past 12 months, so apologies .

In my original model, everyone who jumped in timeline N, would arrive in timeline N+1, and they would all start timeline N+1 in the spacial positions they jumped from timeline N.

The only thing that would influence how timeline N+1 starts, is how timeline N ended. The upside of this model was its neatness, and to me feeling like the naturally right model of time travel. It allows a nice, clean, visualization of the timelines existing in an infinite linear stack. The downside is that when the player jumps, we can't go to the next timeline until all past versions of the player have also jumped (or got stuck before being able to), because before then we don't know what timeline N+1 is going to look like. We can only move our perspective to timeline N+1 once we know that there are no more time jumps coming from timeline N. (I could just fast-forward the simulation in the space of a single frame, but then I'm potentially hiding important information from the player).

In my new model, when the player jumps from timeline N, they arrive in timeline N+1, and the start of timeline N+1 is identical to the start of timeline N, but with the addition of the player in the spacial position they were in when they jumped from timeline N.

It's a distinction that only makes any visible difference when you have multi-jump (and only then if you disrupt the paths of your past selves). In the second model, we can instantly move our perspective to timeline N+1, since it doesn't depend on knowing where everyone else jumps from timeline N, only where the current version of yourself jumps from. It's not as good as an intuitively satisfying model of time travel though, since potentially each past version of yourself that jumps from timeline N has their own distinct version of timeline N+1 (and yes, it is this distinct version that you see through the portals ). I suspect though this is a no-one-but-me-will-care-about thing. Many more people would care about being kept waiting without understanding why.


My next task is to actually build and playtest some multi-jump puzzles .

[Bryan Gale]

Update #3 - Multi-Jump Puzzle Walkthrough

I thought in this post I'd discuss one of the new puzzles I'm working on. I'm afraid it will very much spoil this (and another) puzzle. I had debated to what degree I wanted to put spoilers in this devlog, but it's impossible to talk intelligently about certain aspects of the game without doing so. Hopeful anyone reading will have forgotten the solution by the time the game comes out .


'Carry'

'Carry' (a lot of my puzzles are named after the solution - this isn't shown to the player) is one of my current early puzzles.

Your cube needs to get to the exit on the right, but can't climb the two block high step to reach it. You can push the cylinder on the left and stand on top of it, but you cannot climb it.

The solution, as shown in the above, is first to push the cylinder from left to right, return to where you started, and then jump back in time. Then in the second timeline, stand on top of the cylinder while your past self pushes it, replaying your inputs from the first timeline. You can now climb the step to reach the exit.

One of the wrong solutions that players sometimes attempt is to wait on top of the cylinder, jump, and then in the second timeline push the cylinder along with their past-self on top. This sorta looks right, but can't lead to a consistent timeline. I thought though it'd be interesting to try and build a puzzle where this is the solution, and this is an idea I came back to now that I can do multi-jump puzzles. (This is actually how a fair few of my puzzles come about - designing for the attempted incorrect solution of another puzzle).


'Doozy'

'Doozy' (I need better names) is a work-in-progress puzzle that require the player to make two jumps-back-in-time. It looks like it might have the same kind of solution as Carry, but it's not so clear how you get back to your starting position. It looks like you'd need to press the switch on the right, but to do so you'd kinda need to have already solved the puzzle...

I'll walk through the solution timeline by timeline.

In the first timeline, you stand on the cylinder, then wait again as imagine yourself being pushed along to the right. You then stand on what would be the switch had you been pushed to the right, wait, move back to the cylinder, then wait as you imagine yourself being pushed back along to the left. You then step off the cylinder, and actually push it to the right. Then you jump to the second timeline.

On the second timeline, you now do all the stuff you were imagining was going to happen when you were in the first timeline. Push the cylinder to the right, let your past-self do her thing, push the cylinder back to the left, then jump. Though you've not got the exit yet, you've laid the groundwork and the timeline is still consistent.

Now on the third timeline, because the orange cube is pushing the switch, you can get back to the starting position, and ride the cylinder across to the exit on its second leftward journey.

So yeah, this one is a bit tricky.


Playtesting and Next Steps

I playtested this one on a friend, someone who knows the game very very well at this point. He found that my initial design had a solution that was basically identical to Carry.

Here, you could use the middle 'prong' to climb on top of the cylinder, skipping the entire crux of the puzzle. I find I do this quite a bit with new puzzles - I'll design them with a particular thing in mind that I want the player to do or learn, and be completely blind to the far simpler solution.

Once I fixed this, his main conclusion was that this puzzle is way, way too hard, at least without introducing the concepts behind it first in simpler puzzles. This is the first puzzle where the player is required to alter the path of a past-self, and one of the first that really makes a thing of the need to keep the timeline consistent - where you can easily reach the exit in an inconsistent timeline, but not so easily in a consistent one.

I'm actually pretty pleased with this outcome. A lot of the single-jump puzzles have come from starting with a single way-too-hard puzzle, that I've then been able to break down into multiple, more focused puzzles. Switching from refining my single-jump puzzles to creating new multi-jump puzzles has been a hard change of gear for me. It puts me back where I was months ago, needing to get the crap obvious stuff out the way before I can get to the interesting stuff. With this one, I feel like I've actually hit an interesting puzzle, and one that will serve as raw material for other interesting puzzles.

As a sidenote, another thing I want to fix is the general layout of this puzzle. My favourites feel like they have some natural balance, where this just feels lopsided.

[Bryan Gale]

Update #4 - PAX East/EGX Rezzed Part 1

It’s been a while . Shortly before my previous post I received notification that I’d been accepted to exhibit Induction in the IndieMEGABOOTH at PAX East in Boston. This would be the biggest event I’d shown Induction at, and my first time showing the game in the US. I’d also recently committed to taking a spot at EGX Rezzed in London, running the follow week.

In my next few posts I'm going to talk about my experience at these two events and the preparation leading up to them. Willy Chyr's post gives a great overview of being part of the IndieMegabooth, which I personally found super helpful, whereas I'll probably pick a few specifics to write about. Today, I'll focus just on the trailer I made in preparation. Here's the

.


Trailer

For both PAX and Rezzed, I needed to produce a trailer for Induction. The IndieMegabooth would use this in the marketing materials that went out when they announced their line-up, and at Rezzed it’d be played on monitors outside of the section I was exhibiting in.


Production

Overall, it took me a couple of days to capture and edit the trailer, plus a lot of time spent listening to licensable tracks.

The software I used was:

• Windows 7 (I couldn't find any sufficiently fast screen capture software for OS X, so I had to switch to Windows to make this)
• FRAPS for screen recording
• Adobe Premiere for editing
• RAMDisk to create a virtual hard disk in RAM

I’m developing Induction on a fairly elderly MacBook Pro, so Induction running at 1920x1080 at 30fps, with FRAPS capturing lossless video, was just barely possible at 30fps. There was a bottleneck with writing the video to disk, so I had to use RAMDisk, to create a virtual hard disk in RAM to work around this. Frustratingly, this meant not being able to record more than a handful of minutes at a time.

I don't yet have a composer for Induction, so I licensed music for the trailer from BeatPick. I’d originally spent a lot of time looking through iLicenseMusic.com (the new name of the site Jon Blow used for Braid’s music), but didn’t find anything suitable.

For Rezzed, the requirement for the trailer was for it to be around one minute, so each game would have a fair amount of time on the screens looping through the trailers. Or it could be around 30 seconds and the trailer would be included in the loop twice. A whole minute felt intuitively like a long time for my first trailer, so I targeted 30 seconds.

I didn’t do any formal storyboarding for the trailer, but I did have in mind which levels would look good on screen and what things I wanted to show off. The music heavily influenced the structure of the trailer, and I decided to build it around the ‘drop’ at 0:14, where I’d show the time travel effect for the first time. Once I’d captured some footage, it was quite an iterative process of editing it together to the music, seeing what worked and didn’t, then capturing some more with a better idea of where it’d fit. I generally tried putting the cuts to the beat of the music, and oddly it felt like it worked best if the cut was slightly behind the beat.


YouTube and Content ID

Once I had the trailer, I uploaded it to YouTube, listed as private, ready for when I wanted to share. Then this happened:

A company called The Orchard (previously called IODA) has some kind of ownership over track I’ve used, and without YouTube knowing that this has been uploaded by someone who has a legitimate licence, it gets flagged as copyright infringing. In practice this mean that my trailer displays adverts, with revenue going to IODA, and that there’s a link to buy the track below my video. Also anyone else using the trailer in their videos will face the same problem (I’ve seen

of someone dubbing over my trailer to avoid this, which is pretty grating).

There is a process for disputing claims such as these, but YouTube warns that the outcome may be your video being pulled and your account having a strike against it. I decided to dispute the claim, and in the field provided I explained where I’d licensed the music from, on the assumption that someone from YouTube would get in touch for anything further they needed, such as a PDF copy of my licence. Instead I got a response about a month later rejecting my dispute, and informing me that any further disputes would have one of only two outcomes - deletion of the video and a strike against my account, or complete withdrawal of IODAs claim. I’ve so far decided not to risk pursuing my dispute any further.

I later found out that it’s not YouTube at all that rule on disputes, it’s the copyright claimants themselves, which seem feintly absurd. I did find an email address on The Orchard’s website to contact about YouTube Content ID disputes, but there was no link to this from YouTube, and it was pretty hard to find given it’s non-obvious that IODA and The Orchard are the same.

The lesson here is to upload whatever music you want to use to YouTube first, and if it trips any Content ID stuff, use something else. The exception being if you can upload your video a couple of months before you need to release it, and can be bothered with the dispute process. Unfortunately, it doesn't seem like this is just a danger for licensed music; false positives against original score can occur. An alternative lesson is that if you can remotely afford it, use Vimeo Pro. Hosting a trailer somewhere that won't let you actually talk to a human being is risky.


Release

I released my trailer on 26th February, at the same time as the announcement of the PAX East IndieMegabooth line-up. I was leaving the trailer release as late as possible - at this point a response to my dispute was still pending, so I was reluctant to share it before I had to, given the possibility of it being pulled. Ideally, I would have liked to have released the trailer ahead of the Megabooth announcement, as a distinct 'thing' to contact press about. As it were, my emails to press ahead of PAX were a confused mix of ‘hey here's a trailer’/’hey I'm in the IM'/'hey let's meet-up', though more on contacting PAX press my next (I think) post. I did get a couple of write-ups just from the trailer, and it has been included in most recent press coverage, so it’s definitely a valuable addition to my press kit.