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!