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.

Indies: Why Make Contract Games?

On the road from a traditional job in the game industry to full-time independent game development, we have found ourselves in the position of doing contract game development for a period of time. My initial response to the idea of contract development was less than excited. I feared that it was ultimately no more than a change of bosses rather than the life-changing adventure I was looking for. To my surprise contract game development has proven to be closer to independent development than I had expected. Working with the right companies, contract work can offer many of the benefits of independent game development and act as a stepping stone toward full-time work on your own games, while providing some of the benefits of a traditional game development job.

When you order cheese puffs in bulk, you get a developer as a prize.

Why do contract games at all, you might ask. Well, it's simple. Dependable money. The independent game scene is filled with heroic stories of cash-strapped developers mortgaging their houses, maxing out credit cards, subsisting off of cheese puffs and will-power to create their dream game. While these stories make for a great read and sometimes result in an incredible windfall for the developer, they also sound like a terrible way to live and are one-shot solutions to lack of funding. Miss the mark on your first game and all you've got is debt and regret. Our aversion to taking on debt and desire for a 'normal' lifestyle have led us to take a slow and steady approach to making games. Contract games, though they lack the potential windfall of an independent game, offer a source of dependable income like a regular job. Using this we pay ourselves and by keeping our costs down we have been socking away money until we have enough to make a game of our own. With the revenue from each independent game we release we hope to slowly work ourselves off of our dependence on contract work. In this way, contract game development provides us a (relatively) steady income, similar to a traditional game development job, while providing a path toward greater independence.

Sorry Johnny, it wasn't my call.

At the same time that contract development provides revenue it also provides much of the sense of control that I found lacking in a regular game development job. As a mid-level employee at two different game development studios, I often felt like a horse wearing blinders. The extent of my knowledge of the company's direction and my role in it was limited to the task in front of me. With such limited perspective, I've frequently been confused and surprised by company decisions. I've had projects that dragged on far longer than they should have, while others were cancelled before they were given chance. I worked on a game that had its genre changed on a near monthly basis. Reasonable ideas I suggested were rejected for unknown reasons while company heads made bizarre decisions without my input, such as shoving a poorly drawn Jack Sparrow and mini-games into an otherwise coherent mini-golf game. Working in a small studio has greatly clarified the decision process that goes into making a game. With a better understanding of the decision process has come a sense of control and in-turn fulfillment that I never had when working for a large studio. While contract work still has the limitation that parts of the project are dictated by an outside force, having an active voice in the discussion makes it easier to accept even the bizarrest decision. Additionally we've found that different companies and projects offer varying amounts of freedom, and ultimately we always have a choice of whether or not to take a project. 

Entanglement iOS, does no one love you?

Since contract work provides much of the freedom and control that comes with independent development and also provides a secure supply of revenue, it offers an excellent sandbox in which to learn how to build a company. Derek and I started Gopherwood Studios without any previous business experience. This means we've made a LOT of mistakes over the last two years. Mistakes such as promising an expansion to the iOS version of Entanglement that we ultimately couldn't provide, or giving it an art style without reflecting on the target audience for the game (we still get complaints about that). And while we still make mistakes with regularity, we're much better businessmen than we were. At the same time we've had two years to build up a base of technology and knowledge that make each new project easier. While there is something to be said for diving directly into a passion project from the get-go, there is value in taking some time to work the kinks out of a business before taking a significant risk. 

That doesn't mean that you can't take any risks if you take our route, instead contract games provide us with regular chances to take risks within the confines of a project.  Each project provides new challenges and opportunities. We take advantage of each project to try out new ideas and techniques. With each project these experiments helps us to grow as developers and prepare us for future projects.

While my initial concept of being an independent developer didn't include contract game development, I've been pleased to find that it offers many of the benefits and pleasures of independent development while still offering a path toward full independence. If you've got the ability to a more direct route to independent game development, you may find yourself there sooner than us, but for more risk adverse developers contract game development offers a viable route.

I like whitespace.