Dev Log #4: Cannonball Z

If you played through the alpha then you probably already saw the cannon, but I figure I'd ramble about it anyway since it's a fun object.

The cannon idea came from wanting a new moving object to manipulate with our transforms. Cannons seemed like a good idea because cannonballs have a simple movement pattern (in a straight line until they hit something) that is predictable when transformed.

So, we can do things like this.

(Yes, the smoke trail is buggy, grr!)

The cannons themselves can also be transformed so that we can shoot in different directions.

We've made it so the cannonballs interact with other objects. They can be used to knock down walls.

They can press triggers.

And they can interact with the sheep. Though the sheep doesn't seem to enjoy it. :'(

Since cannons can hit triggers, they can even shoot other cannons. :)

Right now all the cannons are trigger-based, but we thought about having a version that auto-fires so that every puzzle that has a cannon doesn't require a sub-puzzle revolving around pressing the trigger.

Once again, we still have some things we're debating about with regard to the cannons. The main question being whether they should be cannons at all. Since the game is supposed to be in a magical forest (which is not well established by our current art) cannons don't make a lot of sense, but, everyone understands how cannons work, so it's easy to use that as a crutch. The question is, can we find something to replace them that fits in the world thematically while still being easy to grok. It's easy to think of a Mario Piranha plant-like cannon, but that feels like we're stretching, but grasping the next most generic thing. If you have any ideas on what we could replace our cannons with, we're open to ideas.

Hmm...maybe I went a little heavy on the cannon gifs...

The Shifty, Twisty Forest: Alpha Build

Originally we lost our turtle, but now we're losing our sheep...

We're excited to announce the alpha build of The Shifty, Twisty Forest! This build improves upon our initial prototype with the following improvements:

1. Panels now transition on a tap or click, providing much better visual feedback as the level is changed.
2. We also updated the appearance of movable panels, highlighting them with a dashed line instead of a different background color. This helps to separate the panels from the rest of the level art and make them appear more interactive.
3. The hero is now a lost sheep instead of a lost turtle. We noticed that turtles always seem to know where they're going, so having a game about a lost turtle seemed too far-fetched.
4. Rather than shifting a panel into empty space, panels are now swapped with one another. This fixes some of our collision issues with the prototype wherein a turtle falling through empty space would collide incorrectly with an incoming panel's collision areas.
5. The hero pauses at the opening of a level so the player is able to take in the scene and make decisions without having to catch up with a mindless careening sheep. The hero looks mildly excited about starting though, so don't keep him waiting too long..
6. We made the level elements a bit larger. This should make the game easier to play and see on smaller mobile devices.
7. Bouncy springs are still in, but we also added spikes, switches, and blocks to make things a little more interesting.
8. We removed most of the affine transformations for this build, but they'll be in the beta. We're thinking that the initial 20 levels or so will focus on shifting and then we'll introduce reflections and rotations thereafter.

Start each level by tapping the sheep, and once he's in motion, tap the movable panels to get the key and make it to the exit. Check out the progress and let us know what you think!

Dev Log #3: A Time to Break Down, and a Time to Build Up!

After working on the self-destroying wall, I thought a natural follow-up would be a growing wall. Again, I'm stealing liberally from Kirby here.

This is really the same idea, just in reverse. We start out with all the wall blocks placed, but only the starting block is visible/collideable. When the wall is triggered, it creates a hitbox that triggers all the adjacent blocks in cardinal directions. These again have a fuse timer so that there is a cascading effect.

One unique trait to growing blocks is that they can cut each other off. So, if two sets of growing blocks cross the same part of the level, the order in which they are grown will determine their final shape. We hope this will force players to think a little more about the order they trigger switches.

Hit the switches this way one way and you get this result.

Swap them and you get this result.

A couple unresolved issues with growing blocks are collision and visualization.

Since we are introducing collision on the fly there is always the potential of something being inside the collision when it is created. We currently don't have a clean way to handle this. Destroying the colliding object wouldn't make sense since we're making a puzzle game and won't have extraneous pieces that should be removed. Shifting the overlapping object out of the collision is a better idea, but that tends to look a little junky and in general we'd prefer to avoid that situation. Our current solution is simply to avoid placing objects such that they can get caught inside collision. We'll see how long it is before we break that rule. :)

As far as visualization, right now the 'soon to be grown' blocks are hidden. I'm not sure if that's a good idea or not since the player will have to guess and check to see how things grow which may be fun or may be annoying. We could always show semi-transparent blocks instead of hiding them completely or have the backgrounds inform the player of where the blocks will grow.

Anyway, those are our thoughts at this point, if you have any suggestions on how to handle the collision or a good way to visualize the growing blocks, we'd love to hear them.

DevLog #2: Boom!

We've got most of the basic shifting/flipping/twisting functionality working, so we've started shifting to level design and obstacle creation.

One obstacle we've been working on is a simple switch-gate mechanic. Rather than go for a typical gate, we decided to steal liberally from Kirby and have switches that destroy clusters of blocks.

It looks like this!

The big benefit of this is that rather than having a fixed size/shape of gate, we can create whatever shape we want out of a series of blocks.

Even crazy stuff like this!

The mechanics behind it are straightforward. We have one or more start blocks, which are linked to the switch. When the switch fires the start block explodes and a circular hitbox overlaps the adjacent blocks in the cardinal directions. These blocks have a fuse timer, which when exhausted causes them to explode and trigger their adjacent blocks.

You end up with an attractive cascading effect (which will look nicer when we have real animations and not my ugly ones!) and a flexible system that can be used to create destroyable terrain of all sorts of shapes.

DevLog #1: That's Affine Transformation!

Todd alluded to the fact that we had to rework some of our math to make things work in our zeroth log. Unlike his diagnosis, I don't believe we were lying insomuch as just being sloppy. When I program a 2D platformer, I think in 2D, I breathe 2D, and I calculate in 2D. That's usually fine until it isn't.

For example, in 2D when the character changes direction, a simple scaleX *= -1 gets your character facing the right direction and you're on your way. If we need to rotate a character, setting orientation = π/2 is trivial. 2D rocks.

Click to get a better look at the shiftiness and twistiness.

However, this has its limitations. If we combine these transforms, things get messy. If we rotate and then flip, it's not the same as flipping and then rotating. Also when we flip, does it count as a 180 degree turn since we're about-face? And if we need to change direction again, we've really gotten ourselves in a mess: which way are we actually facing?

The problem is that we're not storing enough relevant information. Both of these cases look the same.

But they're not! This becomes quite obvious when we apply these same transformations to woolly, pixelly sheep.

That's where affine transformations come in. They can store all the data we need to render the sprites correctly. Conveniently, we can also send other vectors through these same transformations to handle other directional information like velocity. Linear Algebra is awesome like that. Essentially, an affine transformation takes a 2D plane and handles it in 3D space to put it back in 2D space in a transformed way. So our 180 rotation becomes a rotation around the z-axis, and more importantly our flip is represented as a rotation through 3D space around the y-axis.

By stacking these transforms, we can keep a record of what has happened to a given game entity and make sure we're rendering the entity correctly. In this method, each transform is represented by a 3x3 matrix as shown below.

As each transform occurs, we multiply it against the entity's current transform resulting in a new transform that completely describes its orientation. For example, if our woolly, pixelly sheep is flipped diagonally and then is later rotated 90 degrees, he's simply been horizontally flipped from his original orientation.

Our intent is to include these graphic enhancements in The Shifty, Twisty Forest alpha to make the visual transitions a bit more fluid. Check back in awhile... ...if you care (about shifty, twisty forests or woolly, pixelly sheep).

Development Log 0: The Shifty, Twisty Forest

We're starting a new game of our own! We decided that we liked our Shifty, Twisty Forest prototype enough to try fleshing it out into a full game. We're going to post regular (or irregular) updates on the development of the game so you can see how things are progressing. So, drop in every once in a while, check it out, and chime in with your opinions.

Here's a quick summary of our progress so far:

We'll get a real artist eventually.

Renovation
We started development last Monday and our main task so far has been taking a quick and dirty prototype and turning it into an upstanding and respectable piece of software. The most obvious example of this is changing how our transformations (the 'Shifty, Twisty' in the title) look. In the prototype all of the rotations, mirrors, and translates were instantaneous. Instantaneous is easy to program, but it's ugly and made the gameplay confusing (particularly mirroring). So we're in the progress of turning all our instantaneous transitions into gradual ones. Here's a gif example of a horizontal flip (it's smoother in game):

See, it's working great...oh wait!

Ok, so maybe they still need some work...

We Are Liars
In process of reworking transitions, we discovered that we are liars. Some of you may have already known this, but this was a revelation to us. Seriously though, we realized that we had been lying to ourselves about how transformations affected the objects we were transforming. In the prototype, we had represented everything in 2D using position and angular orientation. As soon as we started on smooth transitions, it became obvious that we were going to need to use 3D transforms to accurately represent the transformations. (This led to another revelation...3D math hurtz my brane!). So now we're reworking the transformations with that in mind and adding all of this to our engine so that any future games will able to take advantage of it.

+1 Programmer Art of Less Terribleness
Our final big change was revisiting the art. We decided to increase the size of character and tileset so things would be playable on mobiles. In the process we took another stab at making art. Ultimately, we're going to throw away all of the art and have a real artist do it, but Derek and I both enjoy making art and I think it helps us figure out what we want the final game to look like when we get in there and try to do it first.

The old version: functional, but drab.

So yeah, that's where we are right now. Let us know what you think.

The Shifty, Twisty Forest

Wow, that forest is just the shiftiest!

Todd and I spent the past few days putting together a game prototype: check it out! The Shifty, Twisty Forest is a story, err... ...game, about a turtle finding his way through a forest - a very blocky forest with locked yellow doors. Help him get to his destination by shifting the forest around!

We created 12 levels to explore the concept and to see whether it's fun. After you've had a chance to play through it, let us know what you think! Does this game deserve more levels, better art, and a real story line (unlike the stream-of-consciousness that caused the confusing backdrop)? Or should we leave the poor forest alone and not make it twistier and shiftier?

Here's another screenshot in case you haven't time to spend on such frivolity but like to look at things and stuff.