indie games and experiments

The red beacon allows you to move stacks of objects easily. Say you have a stack of objects. This stack can be there already, or you could create one by summoning boxes on top of each other. Start by marking the top box with your red beacon.   Now when you summon the highlighted cube, the red beacon that was attached to it will fall on the box right below it, automatically marking it red. Now you can continue the cycle and summon the second box again. That in turn highlights the box under it.  When you summon the last box, since there are no boxes under it, the mark will remain on the box you just summoned.  This mechanic allows you transport structures quickly. Notice also how the boxes emerge aligned on the other end. Whenever you summon a box over another box, it automatically aligns. This enables you to create more stable structures. 

This explains the bring mechanic. You need 1 dynamic object.  Aim and fire the red beacon at the dynamic object. If the red beacon hits a dynamic object, it will become marked, just like the blue beacon. Similarly, nothing will be marked if you hit a wall. One object can be marked at a time.  Now, with the object marked, you can summon it under you. Even if the red object moves, it will still be marked. You can use this ability to place cubes where you want them (for example on a door switch, above an enemy...) You  could also build stacks of objects quickly(we will see this in detail in part 3). 

Bloom is still not where I want it to be. Some foreground/background separation is still in order.

My demo uses the amazing (and opensource) BOX2D physics engine for C++. You can check it out at: http://box2d.org/ The gameplay involves a lot of discontinuity in the physics due to all the teleportation (character teleporting into objects, objects that teleport into spaces that dont fit them...), and BOX2D handled the resolution of these unstable states very well. In fact very little extra programming was required for the engine to reach a very stable steady state.  What the BOX2D test bed looks like. 

This explains the teleport mechanic. You need 1 dynamic object (say the box).  You fire your blue beacon at it. The blue beacon arcs when it travels (doesn't travel in a straight line), and it has a physical weight. You can fire as many blue beacons as you want.  If the blue beacon hits a dynamic object, that object will become marked, and will start to glow blue. If the blue beacon hits a wall, or a non-dynamic object, nothing will be marked. You can only have one object marked at a time. So if you mark a second object, the first mark will disappear.  Now, with your object marked, no matter where you are, you can teleport back to it (on top of it to be precise). So you can use it to get to places you cant reach, go back to previous places, and most importantly, you can create temporary save points before a difficult jump or trap or enemy. 

Besides all the regular fancy shaders you would normally find (reflections, normal mapping...) the demo features one advanced fullscreen shader to produce the painterly effect. Its different from the usual cel-shading techniques because it doesn't rely on silhouettes or a different lighting model to produce the effect. Instead, the shader utilizes a brush pass ( the scene re-rendered with a brush texture applied to everything) and the depth pass, alongsde the main color pass to distort the image in a specific way. The brush pass is used to define the  magnitude  of the distortion, and some math applied to the depth pass to define the  direction  of the distortion. Its useful to note that the main color pass is rendered completely normally, the lighting is baked from Maya into the textures, and shaders are applied normally for reflections and normal mapping. Below are screenshots of the passes with a brief explanation of how it works. 1.  The brush pass. The color v

The smoke-like material seen during the intro and during teleportation is a a real time 2D fluid simulation (a small Navier-Stokes grid for the savvy). Initially, this fluid simulation was meant to occupy the whole screen space (kind of like Little Big Planet), and then emission would occur where needed (where the character is most of the time). The fluid simulation is run as a separate thread and updates at a different rate than the game (slightly slower). The fluid equations are adapted from Dunkan Brinsmead's fast maya fluid equations, which he so kindly make available to the public. Ultimately, I couldn't simulate a fluid this large becuase I was simulating on the CPU (I've seen several implementations of fluid dynamics on the GPU, but sadly didn't have the time to try them).  So, the end result was a low res fluid centered around the character at all times, that resets its contents when a new teleportation occurs. It still provides a nice subtle randomness to e