Friday, June 24, 2011

New Blog Location

I've decided to move this creative contract blog over to a self-hosted Wordpress blog.

You can visit it at:

Wednesday, June 15, 2011

80's Cartoons and a Video Game Daydream

I have this recurring waking fantasy that I've completed my indie opus: A video game series in the format of an 80's epic adventure cartoon. Think, Mysterious Cities of Gold, Spartakus and the Sun Beneath the Sea or Ulysses 31.

Think gloriously audacious opening sequence, full of expansive vistas and children doing dangerously exciting things. Think catchy title tune by anonymous vocalist that's so bad it's embarrassing, yet so good you secretly 5-star it on your iPod. Think of yourself singing it out loud only to realise you're in a crowded supermarket and then try to do that thing where you act like you don't care but lapse into an awkward tuneless hum. Think rushing home on Friday afternoon to catch the latest episode, only you're 35 now, not 10.

Nostalgia so bad it makes my eyes water.

Episodic games certainly aren't a new concept. Alan Wake used episodic chapters to create a genre film in a game, excusing its pulp horror storyline by cleverly wrapping it up in format that demanded it. Brilliant!

Team 17 took advantage of Xbox Live Arcade's short-order expectations by releasing the remakesequelthing Alien Breed series as a triplet of rapid fire, easily digestable, arcade blast-at-everything-and-scream-a-lot-emups, and I'd argue that they're more entertaining and more accessible for it.

Valve take advantage of an episodic release schedule to bring us the remaining chapters of the Half-Life series far faster and cheaper than full-release sequels. *Cough*

But I'm thinking bigger. Yes, that's right: Bigger than Valve. I'm thinking, completely disregarding the whole one-man-army thing... I'm thinking a series where you sit through the opening credits just because they're AWESOME. I'm thinking that you're talking about the latest episode with your gamer buddies, and making predictions about the next. I'm thinking that you're rushing home on Friday afternoon for the latest episode even though you're 35 now, not 10.

And I'm thinking that somehow, it's entirely economically viable and appealing to a publisher who will agree to sell it for a gold coin per episode.

That is my daydream. I'm not even remotely ashamed of such naive romanticism. It'll happen one day - I even have the story all figured, and the start of an opening sequence playing in my head, title track and all. If I ever find the kind of financial success that lets professionally immature people like me treat business ventures as giant funparks, I'll do it. And it'll be like being 10 again, watching Cities of Gold when Esteban raises the Golden Condor and thinking for a time that magic - like those crazy people who wear crystals and smell like marijuana only vaguely masked by incense say - happens.

Until then, I get an aweful lot of fun just pretending. Babababa BA BA BA! DO doodoodoo DUM DUM! DumdumdumDAAAAA! Now if you'll excuse me, I'm going to bed to probably dream about Voltron.

Rant: Games are Too Easy to Create


If you're involved in any way with the game industry, I'd bet money you've heard someone say "Games are too easy to make these days". If it wasn't uttered by one of your coder colleagues, perhaps it was during kitchen-meet gossip. You might have stumbled upon a heated thread on a game development website full of programmers wailing and gnashing their teeth in righteous indignation. Or maybe you read it in the subtext when Steve Jobs slammed the banhammer down on Adobe Flash, apparently out of fear of a slew of crappy games flooding the market. As opposed to all of the masterpieces that currently grace the iTunes App store.

If we make it too easy for people to release games, then we'll have too many bad games on the market. Right? Isn't that how it usually goes?

Well, I don't disagree with the symptom. It's why I made the snide remark about iTunes. But I'm going to go right ahead and smack down over the insinuation that these bad games are being made by people who wouldn't know how to make games if toolkits like Unity and UDK didn't exist.

In other words: Bad games, according to the sway of conversation, are the fault of non-programmers.

You know what? Get off your fucking high horse.

I'm getting pretty resentful of this elitist and exclusive attitude. Often when it's not being literally stated, it's there between the lines in the way beginners and *spit* *spit* artists are treated with impatience or sometimes outright disdain on programmer centric forums. So I wildly underestimated the amount of code involved in what I thought was a simple action: on no the end is nigh. Yawn. Let me assume by your latest efforts that you wildly overestimated your artistic talents, and we'll call it even, k?

So it's the internet, and everyone's an asshole. I'm not a princess about it, usually, and it doesn't bother me, usually. But today, I read a post on a community forum that seemed laced with derision, entirely constructed to tear down the naive game maker - a youthful optimist, nonetheless - who woe be him does not come from a programmer background. It rubbed me in a way I do not like to be rubbed, and a ranting, obviously, ensued.

I should temporarily shut off the steam and say in big bold letter that I know a few programmers who I worked with in the past who I do not at all refer to in this post. In fact, I can only think of four people I've actually met in real life who do have this attitude. Sadly, one of them was a CEO.

But if you've read previous posts you'd probably know that a programmer colleague, James Podesta, has been helping me with code and design. I have no intention of biting the hand that feeds. I do suspect that he agrees in essence with the fact that accessibility to game development is resulting in more crappy games, however I would hope that he doesn't jump on that bandwagon of artist/designer/daydreamer hate that shovels the blame onto our underpaid shoulders.

It's made more difficult to argue my case here when one considers that improvements have been made to my game already through James' input. Without him, the movement wouldn't feel quite so nice. I would have eventually solved the collision bug, I'm sure, but it's those anecdotal tips and tricks that make the real difference, such as the 0.2 second fall-jump buffer.

But I'm going to use that example to argue that game development should be even easier. We've heard it a hundred times before: Graphics are not gameplay*. Well, guess what, neither is code. OMG GASP, RIGHT? No one gives a shit about your programming. No one in the real world, anyway. Your designers and artists will love you for it, and appreciate how your skills contributed to the product. You can pat yourself on the back for a job well done. But if you're going to argue that the polygons I push together are nothing more than a necessary component of the construction, far less than the sum of the parts, then explain to me why your lines of script are any different?

We can probably agree that all our consumers care about is the end product: Does it feel good? Does the aesthetic inform the gameplay? Do I have enough challenge and enough motivation to continue playing?

So all it's about is making good games. That's it. Who gives a fuck how you did it? If you take away the barriers to game development, then you open the door to more people who have a story to tell, an idea to sell, a concept to show off, and a real creative talent to make something entertaining and of quality.

Just because you have the rare technical proficiencies necessary to construct a game, does not guarantee that your game is any good. This has always been the case. Even when programmers were the only ones making games.

* I actually believe that graphics are gameplay, but I'll save that shitstorm for another post.

Tuesday, June 14, 2011

New Blog Design

A new look for the blog.

Just a header and some CSS at the moment, but I'll expand it later to a whole voxel theme. I do so love them little voxels.


Don't say I didn't warn anyone!

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.

Monday, June 13, 2011

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.

Sunday, June 12, 2011

Creativity: Influence vs Individuality

From time to time I am involved in conversation about the creative industries. A shocking revelation, no doubt. Nevertheless, I find that there's a topic which frequently arises (particularly among students and newcomers) and that is the question of influence versus individuality. There seems to be a common assumption that to earn creative integrity one must develop a personal style - a unique artistic vocabulary - which is utterly devoid of external influence. None of us are strangers to the desire to make a mark; to sign the world with our own unique signature. But what a huge burden it is to expect to earn that mark without influence. Imagine if all industries imposed the same expectations on their practicioners: Would you want to be operated upon by a surgeon who believed he could figure it all out himself?

Well, this isn't surgery, and I don't meant to speak as though I have a lifetime of experience: I am myself only just beginning my creative journey in most respects, and anyone who knows me could attest to how much I have to learn. But nevertheless, I feel I've mostly overcome the creative self-consciousness of having a noisy inner critic.

And I understand just how brutally uncompromising he can be.

I'm no stranger to the fear of being labelled 'derivative'; branded a plagiariser, fleeing the midnight mob of artistic masters that are my peers, amongst angry shouts of "UNCLEAN! UNCLEAN!" But to grow as a creative individual, you need to move beyond the impossible expectations that an inexperienced inner critic demands.

If you would indulge me (and perhaps pretend I'm a wizened old magister of the creative industries with real wisdom to impart rather than a 30-something neckbearded nerd with pacman tattooes), I'd like to talk a bit about creativity and influence.

And why you should probably just get over yourself.

The real problem with being afraid of influence (or afraid of acknowledging it) is that your influences will have some of the biggest impact on you maturing as an artist. Unless you're the single most talented individual on the planet who was enjoying sell out shows by age 4 and is now a retired billionaire who spends his teenage years endorsing arts academies and politely declining the Archibald prize for your napkin doodles on the grounds that any more avant-garde statuettes in your house would dangerously unbalance the Earth's axis, I'm going to bet that you don't know it all. And yet, for many of us, the struggle to find artistic identity entirely on our own is a kind of brutally masochistic right of passage.

There was a time when I wouldn't be caught dead emulating someone else's style. Discovering that there was an artist out there whose work or ideas were similar to mine was mortifying. I'd be desperately assuring my peers that my work had been produced in isolation from this other creator, to the point of arguing so aggressively that I surely looked guilty as all hell of counterfeit. I even became afraid of exposing myself to new work out of fear that someone would be doing something remotely similar.

Then I was exposed to the writing of Carl Jung and Mihaly Csikszentmihalyi. And someone who kindly translated it all for me.

Jung and Csikszentmihalyi are considered among the most influential forefathers of modern psychology, particularly relating to the reflective, cognitive, and practical processes of creativity. I recommend doing some related reading. I'm a low-brow kind of guy myself (I feel much more at home with Dean Koontz than Nietzsche) and I find reading Jung's and Csikszentmihalyi's work is a lot like how I imagine it'd feel to stuff my skull full of cotton wool and then play an aggressively competitive game of Boggle. In Scandinavian. While drunk. And being beaten around the head with a sock full of wet tissues.

But in essence, what it boils down to (thank you, university notebook) is that the act of creation, in all of its artistic varieties, can be most simply described as a three step process of big words:
  1. Appropriation
  2. Fragmentation
  3. Retextualisation
Appropriation refers to the act of acquiring; collecting; gathering; hoarding. We appropriate everything: Movies, music, books, conversations, emotions, that particular way the sun hit the road as we were driving to work this morning... And this becomes our library of experience from which we draw inspiration and influence. As creative individuals, we should want access to the most comprehensive source of references available, and that means expanding our mental library as much as we can.

Fragmentation, more or less, means that we break down those things we gather into simple elements. The film The Matrix becomes 'broody guy' in a 'leather trench' discovers 'world is virtual' and 'real world is apocalyptic' and learns to 'flip around in slow motion'. More or less. Those fragments become entities in themselves, which we then...

...Retextualise into something new and wonderful.

This is the psychology of creativity, and assuming you aren't a new kind of superhuman whose brain operates in ways we cannot comprehend, this applies to you.

And it isn't rocket science (despite needing a degree, extensive linguistics training, and a second tongue to pronounce 'Csikszentmihalyi'). What it is, is validation. Don't be afraid to be influenced by the people, the things, and the aspects of your art form, which surround you. In fact you should demand it, because these things will only make you better at what you do.

A common attribute amongst all of the most talented and creative individuals I have worked with is that each has dedicated many hours of their time to gathering a mental library of references from which to draw inspiration and guidance. This is without exception.

So, don't be a princess about your work, don't be so desperate to reinvent the creative wheel, and don't waste time struggling to generate your style in a creative vaccuum. Expose yourself to as much artistic influence as you can. Saturate yourself in it. Your own style will just happen.

But why did I decide to rant about this? Well, I was once again thinking about the game I'm working on. It's incredibly derivative: Braid, Fez, Limbo it is not. But do I care? Not at all. Don't get me wrong: Those games are incredible examples of our art, and a brilliant argument for investing in uniqueness and originality in your product. As a matter of fact, I have a few ideas of my own floating around in my cotton-stuffed skull which, to my knowledge, are comparitively unique concepts, containing (or in some cases built upon) new gameplay, new story, and/or new aesthetics.

So why am I then resorting to... plagiarism? (Said as he crosses himself)

Well, I make this homage (see whut I did thar?) for a couple of reasons, both creative and practical. Talking about the creative first: I love the things which influence this project, namely the classic 8-bit platformers of my youth such as the Wonderboy series (in particular, Wonderboy III: The Dragon's Trap on the Sega Mastersystem). Not many people make those kinds of games any more. I'm making it for me, and I sincerely hope that I do a well enough job that others enjoy the experience (when it's released in 2032).

And the practical aspects: I'm new to this, but I'm not new to the creative individual that I am. I know my faults; that I can become bogged down in detail, and that unecessary complication can overwhelm and then innevitably disenchant me to an idea. So practicality demands that for this project, which is about me learning the how rather than exploring the greater question of why, I should simplify where possible. Realistically, I should be making a Pong clone before broaching the subject of a microcosm platform adventure with RPG elements, but then I also know that if it isn't challenging enough, I'll lose interest.

So, put simply: I'm making an homage to Wonderboy because I want to. Fun for the sake of fun, so to speak. For now I'll leave the groundbreaking to people far more technically capable than I.

Now if you'll excuse me, I have an appointment with my inner critic, and I suggest that if you're one of the people who are struggling to find their signature, you do the same. I know he exists to protect me from things such as, oh, I don't know, removing my clothes and running down the street singing Always by Erasure. But nevertheless, he really needs to STFU sometimes.

Wednesday, June 8, 2011

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.

Tuesday, June 7, 2011

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?


Monday, June 6, 2011

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:


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.

Sunday, June 5, 2011

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.

Friday, June 3, 2011

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:

  • 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?
  • 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:

  • 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
  • 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'

That's all! XD

Platformer WIP: Playable Demo

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


LEFT & RIGHT arrows to move.
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.


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

Thursday, June 2, 2011

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!

Ideas in Limbo

I just found this floating around on my hard drive, and thought I'd share it. It's an image I painted for a game I was working on at my last job.

This was to form something of a style guide for the first level in the game, and was rushed onto digital canvas in the early hours of a sleepless night as the realities of global finance marched inexorably towards dire circumstances.

Sound vague? Deliberately so. Business happens.

But to remain positive, it was an amazing team of people, and a really great product (can you believe we were regularly playtesting within a few weeks, and actually fighting for the controller?) Best of all, I had the incredible honour of being art lead/director on this project, and working with some people who truly humbled me. Illustrators like Jeremy Love, Mike Manalac, Richard Lyons, Brendan Deboy, Jared Pullen and Danh Nhan; the best 3D sidekicks ever in Dean Walshe, Kieran O'Sullivan and Stewart Alves; the awesome designers - Paul McInnes, Christian Carriere and Mark Hurst; and the coders - James Podesta and Shane Lontis - making all the cool stuff happen. And of course our producer, John Whiston, who fought the hard fight for us. It sounds like I'm accepting an award... Well, we should have been!

It was one of those periods of creativity where deadlines and schedules and budgets never interrupted the process. We were always on time, always over delivering, and always thrilled with the results of our efforts, despite the usual production difficulties. I've rarely loved what I do more than on this project.

Unfortunately, as I vaguely hinted at above, due to business-type things out of any of our control, the doors were closed and this project, as far as I know, has drifted off into the ether.

[Insert long and wistful sigh here]

This image is obviously unfinished, and it saddens me to think it never will be, especially since I was super happy with the direction it was going in, and had surprised myself a bit with it. But such is the way of the creative industries.

Sometimes bad things happen to good ideas.

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 :)

Wednesday, June 1, 2011

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.