Unity: Simple GUI

Well, aren't I just feeling productive today? Anyone else feel like a spam sandwich?

A basic GUI is in and working. I've created a separate GUI camera and layer group, incase I want to render 3D GUI elements over the gameplay. For now though, I'm simply using the OnGUI() method to draw a heart texture to the screen, one for each hitpoint the player currently has.

You can lose all of your hitpoints in the lava on level 2, but you don't currently die. You will however see the GUI update in real time as your hitpoints are depleted. I accomplished this entirely with magic. Possibly also a single line of basic code that makes posting about it seem kind of tacky. Maybe I should hold off on the updates until I make some significant advances...

...However, that TODO list is getting quite short!

I may just have to update it soon with the eleventybillion art assets I'll need to create. Well, aren't I glad I thought about that? Excuse me while I crawl under my desk and sob uncontrollably.

Unity: Fit to Zone Width/Height

So it turned out to be easy to calculate the required z-position of the camera to fit the view plane to the zone's width or height. Once I was thinking about it the right way. The code is below:

// Calculate the difference between viewplane and zone width.
float xFit = m_zone.Boundary.width / m_viewPlane.width;
float yFit = m_zone.Boundary.height / m_viewPlane.height;
// Apply to the existing z-pos of the camera.
if (m_zone.Fit == FitMode.FitHorizontal)
 z = position.z * xFit;
else if (m_zone.Fit == FitMode.FitVertical)
 z = position.z * yFit;

Stupidly easy.

And would you believe, I figured it out all out by myself?! The demo is up. Please forward all gold stars of achievement to my postal address.

Unity: Zone Boundaries

Just a short update: Zone boundaries work well. I removed the BoxCollider and added a custom OnDrawGizmos() method to display the boundary as a wire rectangle on the zero-z-plane. I also, quite surprisingly, figured out how to project the camera's viewing area onto the zero-z-plane. Now, to prevent rendering outside the zone, I clamp the camera's position.x to (minimumX + halfViewPlaneWidth) and (maximumX - halfViewPlaneWidth), and similar for position.y. Now I need to solve how to zoom the camera in when the zone width is less than the view plane width, and I'll follow with a playable update.

And in the spirit of honesty, I also need to track down my high school math teacher and apologise for telling him I will never have a use for the shit I now desperately wish I had been more attentive to. Rochelle, if you're reading this, I'm just going to blame YOU for that!

Unity: Conceptualising Zones

So I'm out and about, enjoying a coffee and snack with Heath, and I start thinking about Zones. Luckily, I have my iPad with me and I can proceed to completely ignore the guy - who is currently, I might add, devouring some tasty looking seasoned chips with sour cream - and take some quick notes.

So the things I know I'm going to want Zones to support:

1. Region boundaries, defining the visible area in (x,y) of the zone.
2. The camera's fit-to-zone behaviour, i.e. Whether or not the camera zooms to fit to the zone if the zone is smaller than the camera's visible area.
3. The camera's boundary behaviour, i.e. If the camera clamps at the boundary, or zooms to attempt to keep the player center frame.
4. Minimum and maximum zoom extents and the smoothing factor of transitions.
5. The camera's perspective FOV (for now, static).
6. The camera's background colour or skybox.
7. The default overlay colour.

Zones are currently displayed in the world viewport as a simple icon, and when selected, a bounding box. Right now I'm being lazy and attaching a BoxCollider to the Zone just to visualise the Zone's boundaries, but that's unecessarily expensive. I'll remove the BoxCollider and write a custom OnDrawGizmos() method.

I can assign a Zone directly to any Camera by simply dragging and dropping it in the editor. I can also assign Zones to Portals in the same way. When the player arrives at a destination Portal, it assigns its preconfigured Zone to the Camera. This means that currently Zones are hardwired to Portals, but I may take the time later to make Zones more independant and introduce Zone transitions, if I have a need for it. Right now I can only imagine needing Zones on a per-portal basis, but that may change.

Another limitation is that Zones are rectangular only, and I have no clean way to transition between Zones without using a Portal. This makes L-shaped (or T-shaped or anything other than box shaped) levels currently impossible to implement. It gets considerably more complicated binding a Camera to a non-rectangular boundary. At least, for me it does. I could compose more complicated Zone shapes using multiple rectangles, but right now I can't think of an elegant way to handle the transitions across connecting borders.

Worst case scenario isn't so bad anyway, and realistically keeps things nice and simple: Stick to rectangular bounding zones.

Unity: Hazards Working...

...Player response, not so much.

Implementing hazards was super easy.

1. Add a collider.
2. Make it a trigger.
3. OnTriggerStay, call Harm(damage) on the Player.

Right now, the player starts with 5 hitpoints, and falling into the lava on level two takes away a hitpoint every second. Once the player's hitpoints reach zero, they are respawned with 5 hitpoints.

I added some extra control, such as an immunity timer after the player is injurred, giving them a temporary reprieve from more injury. Additionally, I attempted to implement a knockback effect, which throws the player back a little, temporarily disabling controls: A slight penalty for taking damage.

It works, and it doesn't.

The controls accurately disable for a short time. And the knockback kind of works. The problem there is I'm attempting to wrap the knockback effect up in the standard player movement for the sake of tidiness, but it's actually getting quite untidy. So instead, I'm going to implement a simple FSM (finite state machine) that has two states: normal, and harm. In the normal state, we calculate regular movement, but in the harm state we calculate the knockback movement.

But I have a big problem I'm not currently sure how to fix: Respawning the player in the Update() loop doesn't update the player's collision volume, so the lava is triggered one frame after the player respawns, causing the knockback and damage. I am assuming this is just the nature of rigidbodies, and I need to find a way to circumvent the delay to collision-updates.

I was going to post a demo, but it's too buggy. For some reason, the player registers an injury the instant the game starts (even though there's no damagers in the first level at all). I've had a full day, and I have a drive to Sydney tomorrow, so I'm a bit unfocused. I expect part of the problem is a lack of concentration. Coding while distracted is not a good idea.

There's other productive things I can do, anyway.

There's a Minecraft update that needs my attention.

Unity: Sticking to Platforms (Fixed)

So, thanks to an awesome guy named James Podesta and the wonders of social networking, the player no longer sticks to the platforms. There are some excellent fringe benefits to befriending genius programmers on Facebook! He played the demo, and immediately identified the problem: When headbutting a platform, I was setting the player's velocity.y to zero. What I should have been doing was setting the player's velocity.y to zero only when the player had been moving into the platform on the contact frame. I was going to use collision normals to fix the problem, but I realised it was easier to just test previous velocity to see if the player had been moving upwards at the time of the headbutt.

So more or less:

void OnHeadbutt()
{
 if (velocity.Y > 0.0f)
   velocity.Y = 0.0f;
}

Seriously, as easy as that! I think there is still an occasional sticking problem, when moving at speed horizontally and jumping into the platform. And I think it might be related to the capsule collision object penetrating the platform enough while the platform is also moving downwards that gravity alone is not enough to move the player entirely out of collision. I need to sift through the (now quite messy) code this evening.

As I said in a previous post, a hacky solution might be to disable collisions between the player and the offending platform for a couple of frames. A more complicated solution might be to track the vertical motion of the platform and the player and compare to see if the player needs to be pushed further. It's what I do to keep the player on the platform when they land on it, so I essentially need to reuse that code (with some refactoring of course) to work downwards instead of upwards.

So anyway, a huge thankyou to James for fixing my code on a Facebook wall post! And apologies in advance. I don't think he realises what he's volunteered himself for.

I wonder if he keeps his phone number on his Facebook profile?

Programmers are usually awake at 2am, right?

CLICK HERE FOR THE MOST RECENT TODO LIST

Platformer WIP: TODO List

Updated: 14/06/2011

Recent changes in green.

An (attempted, and somewhat laggy) updated ToDo list:

• Custom editor gizmos for invisible nodes such as locators, spawnpoints, etc. (done)
• 2D platformer-style character movement (done)
• Smooth follow-camera movement (done)
• Portals that teleport the player to a new location (done)
• Linked portals (done)
• Portals that can be activated via contact, or by the player pushing up/down (done)
• Simple camera effects such as fading to black (done)
• Layered camera transforms for additional movement effects such as screen-shake (done)
• Scripted sequences (done)
• Fix: Air control to smooth direction changes (done)
• Improve air control acceleration (done)
• Fix: Can double jump through the moving platform... not good! (done?)
• Fix: Jumping against a low ceiling causes the player to 'hover' (done)
• Simple pickups (done)
• Complex pickups that cause a temporary effect or event (done)
• Moving platforms (done)
• Portals working between levels (done)
• Fix: Player 'sticking' to the underside of moving platforms (done)
• Player health (done)
• Environmental hazards, such as spikes and lava (done)
• Player 'knockback' effect on taking damage (done)
• Second-chance jump timer for slight jump-while-falling allowance (done)
• Camera blocking (done)
• Camera maximum speed setting (done)
• Improved Camera blocking with zones (done)
• Zoom-to-fit when Zone width/height is less than view plane (done)
• Min/max zoom extents (done)
• Basic GUI (done)
• FIX: Fit-to-zone flickers when the alternate axis is less than the view plane
• Improve zoom options to include smooth zoom in/out at zone boundaries
• Simple enemies
• The ability to attack and kill enemies
• More complex enemy behaviours (some examples)
• Flag objects to spawn only once to prevent respawning on level load.

Unity: Inter-Level Portals

Okay, that was far less painful than I expected. To fix the problem of multiple instances of singletons, I simply had each object check that no instance existed in it's Awake() method, and then destroy itself if necessary. This is much easier than trying to write a manager object clever enough to only instantiate the right things at the right time, and it means I can throw a player/camera/etc. into any scene I'm currently working on without fear of destroying the universe.

So: Inter-Level Portals.

Not much to say, really. They're working! If you play the test case, cross the platforms, and make contact with the 'door' at the far top-left of the level, you'll be teleported to another level. There's nothing in this demo that makes it clear it's another level. Which is a good thing, I guess. But it does make this demo kind of pointless:

CLICK HERE TO PLAY THE DEMO

Or not entirely, as a new task has been identified:

• Flag objects to spawn only once to prevent respawning on level load.

That can wait though, as I'm really keen to get some kind of player health system working. What I'm imagining for my platformer will only involve a handful of once-only collectables anyway, which I could always just flag in a global variables container of some sort.

And working on the health system will mean I can spend time drawing pixel hearts. I'm totally going to get a pixel heart tattoo. People will think I'm all gangster and shit.

Unity: Player Movement Physics

I took a break from fixing the inter-level portals (and holidaying in happyrainbowland), and decided to focus a bit on cleaning up player movement. There's been a few small things really bugging me about the physical properties of the player:

• Hovering at the jump apex when hitting a ceiling.
• Sticking to the under-side of moving platforms.

Both problems are kind of related, or at least have similar visual symptoms. However, they require entirely different solutions.

The case of hovering was easy to fix: remove any continuous upwards force when the player hits a ceiling. This involved tracking down a couple of lines of code and nuking them. And the result was perfect - no longer can the player hold jump to grapple on low colliders.

The case of sticking to platforms however, is much harder to fix. At least, as far as my understanding goes. It's a combination of the CharacterController component settings and the physics engine. Neither of which I have a great deal of control over.

I tried tweaking the skinWidth variable for the CharacterController, with varying degrees of success. Decreasing the width (which decreases the collision tolerance) resulted in many more visible errors. However increasing the width didn't particularly improve the situation at all. I gave up when the player was hovering two feet away from every surface.

The second attempt involved tweaking collision parameters for the platforms themselves: things like changing the collision type from discrete to continuous, and fooling around with other settings. But this didn't have any noticeable impact either.

I'm trying to solve the issue in code at the moment, by detecting a headbutt and correcting it. Detecting is easy: Unity has a bunch of built-in methods and properties to help you do that. I can reliably detect a headbutt every single time. But correcting it? Not so easy.

I've tried resetting all of the velocities of the player object on a headbutt, which gave a very slight improvement, but nothing to write home about. Then I tried reflecting the vertical velocity to actually rebound the player away from the surface, but that just seemed to make it worse (and I really have trouble comprehending why). But other than these things, I'm really not sure what to do.

I have access to the platform that the player has collided with, so perhaps I can simply temporarily disable collisions between the two? I have to say, physics is not my best asset. That is, the understanding of physics. Actual physics I'm perfectly good at. At least, I can't recall the last time I didn't sink in the bath.

Unity: Loading Levels

What a night. I've got a Machiavellian wisdom tooth with aggressive plans for cranial domination waging war on my face. Luckily, I also have a pack of capsules filled with some incredible magical rainbow potion. My teeth feel fuzzy, in an oddly pleasant kind of way, like they're wrapped in two feet of cotton swaddling.

I can't say I'm in the best mental state for programming. Nevertheless, I got inter-level portals working.

It was an uphill struggle. Understanding code isn't an easy task when I'm prone to drifting off into happyland every time I blink. Most problems have been a result of having the memory span of a goldfish, but I did have some major difficulty with the Application.loadLevel() method. It turns out, this method doesn't actually pause operation or anything. So my code kept doing its thing believing it was operating on the newly loaded level, when it was in fact working on the old.

The Application.loadLevel() action doesn't actually occur until the end of the frame, so the solution was to wrap it up in a coroutine (I love those things!) and then yield, to wait a frame before continuing execution.

I still have another problem to solve before I can publish an example: In building the first level, I went ahead and dumped all of the persistent objects (things like the player and camera) in that level. Now, when I return to the level, it loads duplicates of these persistent objects and screams errors in my face. I need to refactor with a main controller that instantiates the persistent objects only if they don't already exist. But I'm going to go ahead and do that tomorrow. It's getting hard to concentrate with all of the unicorns running across my ceiling.

Unity: Player Movement

So I was playing around with code to (subjectively) improve the feel of the player's movement. I began to think about the variety in 2D platformer physics, and just how much difference to the feel of a game tweaking a single value can make, to the point of defining an entire franchise.

I've listed the variables that come to mind below:

Movement

• Speed - What is the player's movement speed?
• Friction - Does the player continue moving when releasing the controls?
• Momentum - How quickly does the player change direction?
• Acceleration - How quickly does the player reach maximum speed?
• Walk/Run - Can the player hold a button to toggle between walking and running?
• Air Control - How much of the above applies to airborne movement?

Jumping

• Force/Gravity - How fast does the player launch? How fast do they fall?
• Verticality - How high can the player jump in total?
• Variable Height - Can the player hold the jump button for extra height?
• Boost Jump - If running, does the player jump higher than while walking?
• Double Jump - Can the player tap jump while airborne for an extra, airborne leap?
• Ceiling Bump - Does the player 'hover' if the jump apex is cut short by a ceiling?

Quite a lot to think about! One set of values gives you Mario, and a few tweaks gives you Sonic. That's a lot of importance in what amounts to a few floats and integers in a single MonoBehaviour.

So, subjectively, what do I prefer? That's hard to say. I find myself flip-flopping a little between contrasting schemes, and alternately preferring one and then the other. I'm leaning towards modeling the mechanics on something I know - something I already like. Wonderboy is the obvious choice, as the game I'm seeking to make is similarly modelled on Wonderboy's gameplay. There's a good reason the designers chose the mechanics they did, and a good reason they work.

But there's some things missing from Wonderboy's scheme that I do like, such as double jump, and a greater velocity to the jumps in general (think Mario's spring-loaded leap, for example).

In theory, I'm leaning towards:

Movement

• Speed: Moderate - Mario-ish speed
• Friction: Very high - The player stops on a dime
• Momentum: Very low - Very rapid changes in direction
• Acceleration: High - The player reaches maximum speed quickly
• Walk/Run: No - There is a single movement speed
• Air Control: Full - The player has the same range of motion in air as on the ground

Jumping

• Force/Gravity: Moderate (both) - Mario-ish again
• Verticality: Low to Medium - Close to character height, rather than building height
• Variable Height: None - Jump is a standard height
• Boost Jump: None - No walk/run distinction
• Double Jump: Yes, once upgraded - Great way to open new areas
• Ceiling Bump: No hover - It feels like a bug rather than a feature

Of course, I might change my mind later, but at least if I make penciled-in decisions now, then I can start thinking about the overall design of the game. For example, if there is no variable height, there is no need for ceiling traps such as spikes. If there's no variable walk/run, then I can standardise platform-to-platform distances. Et cetera (yes, it's two words, omginoright?).

Unity: Moving Platforms

Done! However I'm adding to the list of features (and fixes):

• Fix air control to smooth direction changes
• Improve air control acceleration (noticeable when jumping while standing still)
• Can double jump through the moving platform... not good!
• Jumping against a low ceiling causes the player to 'hover'

CLICK HERE TO PLAY THE DEMO

That's all! XD

Platformer WIP: Playable Demo

This post will be updated with the most current demo of the game.



Instructions:

LEFT & RIGHT arrows to move.
SPACEBAR to Jump.
Push UP to enter a door, and DOWN to leave through the same door.

Unity: Coroutines

So a quick description of coroutines, in the language of this utter noob. Coroutines are essentially a method/function which can be sequenced to operate independantly of the standard Update() game loop.

For (a pretty lame) example, in my last post I added a power-up which caused the player's speed to double for 5 seconds. The MonoBehaviour which triggered the power-up effect looked something like this:

// Simple Coroutine
public class PowerUp : MonoBehaviour
{
 // Called when the player touches the power-up
 void OnTriggerEnter(Collider activator)
 {
  StartCoroutine(PowerUpSpeed(2.0f, 5.0f));
 }

 // The Coroutine which handles the power-up
 IEnumerator PowerUpSpeed(float multiplier, float duration)
 {
  Debug.Log("Powering up the Player!");
  Player.Instance.MovementSpeed = Player.Instance.MovementSpeed * multiplier;
  // The next line causes this method to pause execution for 'duration' seconds
  yield return new WaitForSeconds(duration);
  Debug.Log("Powering down the Player! Aw!");
  Player.Instance.MovementSpeed = Player.Instance.DefaultSpeed;
 }
}

So in this example, the OnTrigger() event (which is called automatically by Unity) in turn starts the coroutine PowerUpSpeed(). The coroutine prints "Powering up the Player!" to the console, then increases the player's speed. Then the yield statement is used to pause the coroutine until the yield's specified method returns. In this case, the method is WaitForSeconds(), which as the name suggests, waits for the specified number of seconds before returning. After the WaitForSeconds() method returns, the coroutine prints "Powering down the Player! Aw!" to the console, and the player's speed is reset to the default value.

Coroutines ROCK! I also use a Coroutine to control the Portal sequence: fade to black, teleport the player, teleport the camera, fade up from black.

Now:

StartCoroutine(GoToWork(8.0f * 60.0f * 60.0f));
GoBackToBed();

Unity: Making Stuff Happen #2

Some additions to working features. Namely pickups, and a power-up which increases player speed by an arbitrary value for an arbitrary time frame (in this case, x2 for 5 seconds). The pickups created a bit of a problem in that they're rigidbody objects (ie. they collide with stuff) which had to not collide with the player (which would cause hitches in movement), but instead act like a trigger (which detects a collision, but doesn't actually respond to it). So in short... the pickups had to be both a collider and a trigger, which isn't possible.

The solution was to parent one gameObject under another. The root is the rigidbody which collides with the world, while the child is the trigger which responds to the player.

The power-up, once the issue of collecting it was solved, was actually ridiculously easy. Coroutines are the best thing about Unity. Seriously.

Didn't get the moving platforms done tonight, but that's the next thing on my list.

Note: The playable demo has been moved to its own post. CLICK HERE TO PLAY.

Time to collect some coins!

Unity: Locator.cs

My first code example! It shows how I draw the custom gizmo for the Locator game object (an empty game object which I use to define nodes such as waypoints or spawnpoints). Not very exciting, but this was one of the harder things to find in my googling, so if a beginner like me stumbles across this page and has a bit of a lightbulb moment, it'll be worth it!

The OnDrawGizmos() MonoBehaviour override is, as the name suggests, the method in which to place Gizmo drawing, as it's called automatically by the editor, but not during the game. I believe there's also an OnDrawGizmosSelected() method which you can use to draw a custom gizmo when the entity is selected.

Just drag this MonoBehaviour onto an empty game object to create a visible locator. Easy as that :) Best of all: You can select the entity by clicking the gizmo!

Unity is so clever, amiright?

// Basic Locator object
public class Locator : MonoBehaviour
{
 // Draw Gizmo
 void OnDrawGizmos()
 {
  Vector3 pos = transform.position;
  Vector3 scl = transform.localScale;
  Vector3 posX = new Vector3(pos.x + scl.x, pos.y, pos.z);
  Vector3 negX = new Vector3(pos.x - scl.x, pos.y, pos.z);
  Vector3 posY = new Vector3(pos.x, pos.y + scl.y, pos.z);
  Vector3 negY = new Vector3(pos.x, pos.y - scl.y, pos.z);
  Vector3 posZ = new Vector3(pos.x, pos.y, pos.z + scl.z);
  Vector3 negZ = new Vector3(pos.x, pos.y, pos.z - scl.z);
  
  Gizmos.color = Color.white;
  Gizmos.DrawLine(posZ, negZ);
  Gizmos.DrawLine(posY, negY);
  Gizmos.DrawLine(posX, negX);
 }
}

Unity: Making Stuff Happen

So I don't really have a design document. But I do have a feature list - a collection of bits and pieces I want to learn to create before I go about designing the game. You can't build the house until you have the tools, right?

Here's where I'm currently at:

• Custom editor gizmos for invisible nodes such as locators, spawnpoints, etc. (done)
• 2D platformer-style character movement (done)
• Smooth follow-camera movement (done)
• Portals that teleport the player to a new location (done)
• Linked portals (done)
• Portals that can be activated via contact, or by the player pushing up/down (done)
• Simple camera effects such as fading to black (done)
• Layered camera transforms for additional movement effects such as screen-shake (done) 
• Scripted sequences (done - coroutines freaking ROCK!)
• Simple pickups
• Complex pickups that cause a temporary effect or event
• Moving platforms
• Portals working between levels

This effort represents about 8 hours of work. My hope is to have the pickups, moving platforms, and inter-level portals working within the next 8 hours (of active Unity time, not real time). I'll try to keep posting updates either at qualifiable milestones, or time-based intervals.

Future updates will include:

• Player health
• Environmental hazards, such as spikes and lava
• Simple enemies
• The ability to attack and kill enemies
• More complex enemy behaviours
• And more!

It's all so exciting! I'll try to figure out syntax highlighting for C# in blogger (I tried earlier and failed miserably) and then I can post my code stuff, for anyone who cares.

And here is a playable 'demo'. Not much happening, but everything starts somewhere!

Note: The playable demo has been moved to its own post. CLICK HERE TO PLAY.

I've never been happier to be a nerd :)

Unity: Love at Second Sight

So, as promised, here is my first entry, post-changing-teams.

I began playing around with Unity about a year ago. Up until that point, my impressions (sadly) were formed on unsubstantiated negative heresay and the handful of student games I'd seen which didn't particularly sell it as a bad-ass indy toolkit in a world which had just received UDK for free.

So I'd heard about this thing called Unity, but to be perfectly honest... UNREALENGINEOMG.

Between then and now, I flip-flopped between XNA and UDK. XNA because it was super easy to code with and I'd been learning C#/XNA for 18 months or so, and UDK because it's so good at making stuff look insanely sexy.

But whenever I tried to learn to code in UDK, I hit a wall of outdated tutorials, limited video resources, and a small community who were too busy to answer my inane questions. I had a lot of trouble advancing in UDK beyond a graphics toolset.

I was much more successful in my "learn to make games" self education in XNA. I actually made quite a few little playable (albeit unpublishable) mini-games. Most didn't have a point, and some didn't even have gameplay. But it was fun, and it was learning, and it was going somewhere. Documented on this blog are a few examples of some games I loosely call 'in progress', because when it came down to it, I had no idea how to do 3D in XNA, and I kept getting bogged down in attempting to make a functional game editor for my 2D ideas. I made an aweful lot of progress, but not a lot of product.

Then I decided to try Unity again, after reading about it in a much more positive light. First delightful surprise was how easy it is to navigate: Within minutes, I was moving through the interface, adding entities, getting things happening without so much as a peek at a tutorial. After the first hour, I had an actual mini-game, playable. Not particularly fun or inspired, but certainly inspiring.

The next thing that surprised me was the asset pipeline. Importing Maya assets directly? Truly, what voodoo magic is this?!

And then, I discovered that Unity is quite happy to let me script in C#. It can't be understated how important this is to me. I'm not a programmer. Learning to program, even to the intermediate-ish level that I'm at, was an arduous and time-consuming task: I'm talking an hour or two every single night for the last two years. And it just so happens that the language I learned to code in was C#.

Unity and I seemed to be made for each other.

So the last few days I've really started to dive in. I have (from scratch, or almost from scratch), a side-scrolling platformer, with a really nice, tight feel to the player controls. I enjoy just jumping around (there's even a double jump!). There's also a smooth tracking camera, portals, screen fades, and I just added a camera-shake effect. It all works so nicely, I'd like to squirt a little lemon in my eye just so I can wipe away a tear of happiness.

The next thing I'd like to try to create is a pickup of some sort. Maybe a power-up that applies a temporary boost to player speed, or something else like that.

It's all just white boxes and white capsules and white spheres at the moment - no art to speak of. But that's okay. For the first time since I began this journey, I have something truly playable, and I can't wait to make it sexy.

I'm wondering how mister-green-short-shorts-pirate-guy might look as a 3D character...

Changing Allegiance

Ouch. It's been too long. So much for daily creativity, amiright?

Though it might not excuse me, I have a reason of sorts: My life is still transitory. I am here-and-there at the best of times, and sometimes who-knows-where? Not that I'm suffering; as a matter of fact, I feel better about (and more connected to) the important things than I have in years. It has been a wonderful shift in gears. I finally have time to see my friends and family. I've been taking time, just to take time.

I've been watching some television, reading some books, playing some games, and doing some nothing at all. And it's fantastic.

Not to say I've been uncreative. Some days I shoot some photographs. Other days I write a bit, or sketch up some ideas in my notebook. And quite a bit of the time I'm still doing the indy-game-thing.

I haven't been posting my endeavors, partly because I haven't really got all that much to post (it's hard to make code look exciting), and partly because I've been lazy about posting. I'll try to fix that. I am also, for the foreseeable future, going to have to renegotiate my contract. I would love to be in a place where I have at hand the time, the space and the equipment to be so optimistically proactive. But the thing is, I'm loving more right now just being able to coast... Meander... Take a breath and hold it...

So I'll talk briefly about the title of the post, else it makes no sense.

A change of sides; allegiances altered; an utter betrayal: XNA, I have something to tell you... There's someone else. It's not me, it's you. Yes, his name is Unity, and we're totally doing it.

And with that confession, I don't have much more to say right now. There's been a lot going on with Unity and I. Some coding, and designing, and objectifying, oh my! Later, when I'm slightly less transitory than I am at this very instant, I'll post some details of the sordid affair. With pictures. Oolala.

Until then, peace xox.

Game Design Document

I put this together this morning. It was based on a number of example documents I found via google. I think a GDD can be overkill for a lot of stuff, especially for those ideas that haven't really gestated beyond a high level concept yet. But I also find that I don't record my ideas as diligently as I should, and a lot of stuff just gets forgotten or mashed up into something else over time.

This document has a fairly comprehensive list of topics, many of which won't be pertinent until an idea actually becomes a product, but still I thought it'd be good to have the template available so that when I do think "I should document this idea", I can fill in the parts I'm clear on and then drop the document into a work in progress folder to come back to later.

I could also just have a notepad and a pen, but where's the fun in that?

Here's a link if anyone thinks they might want to use it.

Game Design Document (Word 97 format)