Why I make games

So someone I know in gaming has been having a rough year and is getting to the point where he's asking "Why?, Why do we do this?"

A little background. Working in video games is hard. Not grave digging hard or saving lives hard, but it is hard. I don't know many people in games who work a normal day. Invariably the day leaks an hour, and when things are going bad it's common to be at work for 12 hours a day, and on the weekends. And none of it is ever a cakewalk.

Why? Well, making games is currently a difficult proposition. The industry is young enough that despite the fact that there are some absolute gems, we really don't know how to do this yet. Every day we're inventing something new, and usually still something rather primitive. For all the power in the newest toys, we're still scraping the performance barrel just to move things around.

But beyond that, and just like any other creative industry, gaming is a gamble. We take people's money, somehow, somewhere, and bet that we can make something entertaining. The large pile of filer dross on the shelves should tell you that the odds on that are pretty long.

So it's hard, and we're more than likely not going to make it. Why do we keep on keeping on then?

When people ask "we" questions, they're really trying to find "me" answers. By looking at people with common ground, you're really hoping to find a mirror you can relate to, something you might have lost the ability to summon up. So I'll answer why I do this, and make no claims about anyone else's motivations.

I do this because I have to. I do this because doing anything else would require me not to be me. Religious people call this belief, and I supposes there's something to that. Being less of a mystic myself I'm inclined to dig deeper, and what I find is that the belief that I must make games comes from from the belief that I can make a good game. So where does that belief come from?

As it happens, I think it's always been there. As a child, I loved video games. Along with reading and music, that there is pretty much my childhood in a nutshell. In my mind, I formed over time an image of what gaming would be like some day, what the ultimate game would be. This has gotten re-contextualised and experiences along the way have pushed and pulled the image in all manner of ways, but principally I'm still trying to get to play the games I dreamed of.

Somewhere along the way I realised that I might be an artist, and still later yet I picked up programming. Now I'm pretty certain that I have something to offer and co-workers seem to agree, but the core belief, irrational though it may be, must still belong to that child staring at Combat on the Atari 2600.

A word on XNA performance from the horse's mouth

Curious to know which bits of information on managed code performance on the 360 are FUD versus truth? The .Net Compact Framework Team's blog has a 2 parter on performance considerations on the beast.

There are some interesting tidbits on where the XNA and the standard Compact Framework diverge. Shame that it doesn't yet take advantage of the Altivec stuff, but oh well.

They mention memory management, of course. I'm still of the opinion that the best way to minimise the effect of memory allocation/deallocation on your game's frame rate is the same way to minimise the effect of anything on your frame rate: don't do it. Allocate what you need at the start of the most convenient logical block you have (game start, level start, etc) and recycle. No sense in deallocating a bad guy when it dies if you'll just need another in a few seconds!

As a bonus, the nice chaps at the .Net CF blog also link off to what they consider to be good advise on managed code performance in general.

All very much worth taking note of.

What I thought Zune might have been

So the holidays are over and the Zune hasn't really made much of a dent. Having had a play with the device, I can see why this is. It's not actually bad, it's just not great. It doesn't do much that any other player doesn't already do, and what it does new immediately feels like it misses the mark.

Here's what I assumed they were going for and, in contrast, why I'm not interested yet.

Wifi access to the store from the device. No brainer really. Can't for the life of me see why they didn't wait until this was a go.

Intuitive media sharing. The current sharing interface on the Zune is awful. Never mind the policy, the actual act of sharing its self is limp. I envisioned something that worked like a very local radio station, with Zunes able to tune into each other and see/hear what the master is doing. To the lay person it would make more sense to tune into things like this, and then initiate a local copy request that can jump through the DRM hoops or just bookmark a purchase for later.

Not to mention that the act of being able to broadcast to a small audience like that would be a killer app, and much more in tune with the viral marketing function that music sharing has. Plus, it's actually even more rights friendly: you can only listen freely while the other Zune is nearby, and you have no control over the playback. Adding their 3 or 3 sharing on top of that would be golden. I could see a future in which such sharing was so ubiquitous that indie bands would practically have to be able to "zunecast" to get anywhere.

With that logic in place, I wanted to see intelligent systems that you could preconfigure to tune into your particular Zune automatically. When I get home from the morning run, I'd like my PC to pick up on the device and pump the music I'm listening to out its speakers. Fancy hifi wireless headphones would do the same when I get to work, heck so would my car and the phone headset, if asked to. Little standalone speaker setups I could dump around the house would be neato as well.

It'd also be a more natural way to share photos. Scrolling through your slide show, narrating while other people look at their Zunes seems logical to me, with your audience able to pick and choose what they might like to archive for later viewing.

Tagging these shares with additional metadata would be icing on the cake. Indie bands would have links to their webpages and latest blog excerpts travel with their songs, which media player would happily load for its now playing screen. Notes for pictures would explain them, and carry a link to a flikr collection for the full set. Viral funny video marketing efforts on the net would carry coupons that you could redeem by having the video present on your Zune when you walked into a store.

But no. What we actually got was a big fat media player with a so so battery life and what amounts to little more than gimped local ftp. Bizarrely, despite its features, this leaves it ill suited to displace the current Creative Zen V I carry around: it's small, robust, completely non intrusive and plays everything under the sun. Sorry Microsoft, maybe at version 2?

A bit of online coverage as background for the above post.

Pet names for projects

I really like giving any personal project I'm working on a title. No matter how large or small the project, I feel compelled to.

It doesn't have to be a permanent name, but it does need to say something about the project. Often times that thing gets dropped or evolved out of recognition, but I just gotta have a name. There's something important about names, even if I can't quite articulate what.

Occasionally this'll carry over to work as well. I just get so turned off when faced with "Mesh Converter 2.5g.01" as an app, that when I'm working on a really problem specific small tool I'll revert to character with some naming silliness.

Does anyone else feel the same way?

Mooncasting, the design

In order to explore the XNA and get a real feel for trying to write a game with it, I've spent the last few days trying to work up a little prototype. The working title for it is Mooncast.

The gameplay is battleship meets a cut down RTS affair. You start on one continent, with a castle and a pair of plebs. Your goal is to take out the opponent's castle on the other continent. At the start of the game, you cannot see the opponent's units.

You can build a number of additional buildings, command them to take actions, and move them around. All of this requires the efforts of plebs, which you can assign to support duty at the building level. The more plebs, the more efficiently the action is performed, e.g. the faster a building moves, or a cannon fires.

Available buildings so far are:

• The Castle, births new plebs
  
• The Cannon, fires meteors
• The Aviary, despatches scout birds flying monkeys
• The Watchtower, shoots down scout birds flying monkeys
  
• The Hut, births new plebs at a better rate than the castle
  

Up for consideration are:

• The Shield Generator, takes damage instead of a single other building
• The Black Widow, despatches burrowing spiders to attack opponent plebs
• The Wasp Nest, despatches wasps in response to spiders
• Armageddon, a super cannon with much longer recharge time
• The Eye of Ra, a satellite that allows the player to see enemy cannon launches (would demote normal visibility to line of sight from towers and castle)
• Hathor's Gouge, a rocket that takes out the Eye of Ra.
  

The player may construct any number of each building, except for the castle.
Each building can be attended to by as many workers as the player wishes.
Each building can only do one thing at a time, including moving.
Each building has a health attribute. It cannot be replenished. When a building's health is depleted, it is destroyed.

Game flow goes as such:

1. Preamble: player must select starting triangle for his castle to occupy.
2. Play starts
3. Player may select any available building and command it to move
4. Or player may select any available building and command it to perform its action. This may involve selecting a target location/s on the map.
5. Or player may drag and drop worker icons from their current post to any other available building.
6. Or player may select to build a new building.
7. Meanwhile, buildings continue to simulate either being built, idling, moving, performing their action, or receiving damage.
8. Repeat from 3 until either player's castle is destroyed.

Progress to date:

• The Map. Imported as a triangle mesh and parsed for efficiency into an easily traversable graph structure, then unwound into vertex buffers for rendering the solid display and wire frame overlay. The map is aware of terrain type and player ownership.
  
• Base unit class, with knowledge of the Map and how to traverse it.
• Placeholder art in for the map, background, buildings and little workers.
  
• Projectile class, with rudimentary collision.
• UI system class, and a building widget.
• Oh, and a cursor!

So far so good with the XNA really. No nasty gotchas, and C# is being a darling. No suprise at all, but robust collection classes are definitely where its at.

The Legend of Zelda: Twilight Princess (Wii)

Ahh, Zelda.

Disclaimer: Some of my fondest gaming memories involve the Zeldas all the way back to the NES. (I'm conveniently forgetting Zelda II here)

So Zelda: TP then. Loved it, loved it, and loved it some more. I think I now rate this as the best Zelda to date. Take it for granted that if you love Zelda, the things you love are here: clever lateral thinking, a big world with long foreshadowed interleaved goals and some hardcore moreishness.

So what's different?

To start off with, the Wii is a bloody fantastic bit of kit. Surprisingly the wiimote + nunchuck configuration is more comfortable than a gamepad for prolonged gaming. The tether between them means that you don't have to have both hands locked permanently together.

Swinging the wiimote (not directly mapped to motion here) to attack is also supremely satisfying. As childishly gleeful as mowing down grass was previously, it's all the more so as you run along swishing the wiimote from side to side. Aiming was very satisfying as well. Snapping an arrow into an archer with the flick of a hand before they get you first is terribly rewarding.

The graphics are a little blurry, but forgiveable when you consider that most of this is probably still a gamecube game. They are very well designed though, with each location sporting a strong recognisable character. This aesthetic sense shines through the technical limitations on several occassions, places where you find yourself just thinking "beautiful".

The characters are also fantastically designed, bold and colourful, each an excellent reflection of their traits. Animation too is fluid and full of expression.

No skimping on effects either. The screen is always alive, and boss fights do not disappoint at all.

Taken all together, you're likely to find yourself drawing favorable comparisons to a Miyazaki movie while playing Zelda:TP.

Speaking of Miyazaki, possibly the most welcome change this time around is the darker plot. Angling at a more sinister children's fairytale, Zelda:TP manages to make more of its grand plot than any Zelda to date. After the twee sugary delivery of Windwaker, more Grimm and less Disney is a good thing.

The only let down then, is the music. Audio in general is quite passable, but the music really lacks some punch. It's pleasant enough, and I didn't tire of it over the course of playing the entire game, but it really didn't have any crescendos to it. Considering the rich heritage in Zelda music, they also missed a boatload of tricks. Other than a little tease at Hyrule castle, they didn't even have a clear rendition of the Zelda theme! I was very much hoping for a big orchestral reworking in the Square style here.

But that didn't stop Zelda:TP from being the most entertaining game I've played this year, and the best justification I've found for owning a Wii at this point. Great game, great system, if you love games you absolutely owe it to yourself to pick it up.

Hello, XNA

So I've been writing tools in C# for building games for almost two years now, but I've not really attempted to write a game there yet. I had a brief flirt with MDX for the novelty of it, but without being able to use it at work I just haven't been able to find the time. A bit of time to myself and the launch of XNA though, has prompted me to finally investigate.

Turns out, XNA is wonderful.

To start with what I know: C# is ace. It's a reasonably clean language that in the MS implementation comes with a great set of libraries (.Net). It's easy to learn, easy to read and easy to debug. Not to mention the built in honest to goodness reflection. Man, does that come in handy.

What a joy to find that a good chunk of that stuff shows up in the XNA Framework as well. For the uninitiated, the XNA Framework (based, as I understand it, on the Compact Framework) is the cut down version of the full .Net libraries designed to run on both Windows and the XBox 360. The plan is that if you stick to these bits, you should be able to run your game on the 360 with just a recompile. If you're resolutely windows bound though, you're free to additionally use any other libraries that strike your fancy.

Getting into the actual game libs, XNA provides runtime managed wrappers for DirectX graphics, input handling, audio playback, and some other miscellaneous bits and bobs. My experience so far with the graphics portion has been sublime. Not only is it laid out in a wonderfully clean and concise manner, but the performance hasn't been shabby at all. Given the overall advantages of working in managed code, I can happily see developing a game this way.

Offline, XNA also provides a content pipeline for organising your data builds. Constructed as a Visual Studio plugin, the content pipeline does the usual dependency checked source to binary platform target conversions. The system is designed to take plugins for each conversion type, and comes with standard converters for .x, .fbx, model files .fx effect files and a brace of standard image files. These default plugins worked well enough, and I had practically plug and play data out of 3D Studio Max in no time.

There's plenty still missing, but if this is version 1 then I'm happy to invest the belief that it'll come eventually. Following is my initial laundry list of missing XNA bits and bobs:

• Animation. Preferably built in such a way that makes animation compatible with but not limited to models. Reasoning for this is that data over time can be rather useful for any number of things besides moving an articulated skeleton of bones. A channel based architecture, I'd wager, would be appropriate. Bonus points for supporting some generic form of triggering data as well, e.g. sound triggers.
  
• Game Structure. The current Game class takes away a lot of the tedium associated with starting up a robust directX window (actually, amazingly so. Hello XNA World is an astonishingly small amount of code), but it doesn't really point much in the way of game structure. It would be nice to see, if only as good practice examples, modules from Microsoft for graphics scenes/contexts, state machines, etc.
• UI. There are only so many ways to build the back end code for a UI system. I know, I've written a few myself. I've yet to see any really compelling reasons to pick one over the other, and frankly if any of them were available off the shelf I'd jump at using it. Microsoft have already built the great Forms system for Windows programming, I'd love to see them apply some magic to game UIs.
  
• Online Support. Nothing in the XNA about playing online yet.

So week one of the XNA and I'm quite happy that I've spent the time on it. To be honest, I don't think that this'll take the dev world by storm just yet. Many of the advantages XNA offers we already have, the content pipeline in particular. What dev house doesn't have one? Writing in C# at the moment is also a no go for anything but the Windows platform. Even for the 360, we have to wait until the middle of next year for the professional version of XNA to surface.

No, I think where XNA really lives, for us devs anyway, is in promises for the future. If Microsoft can demonstrate that they're in it for the long haul, then they might win over the more staid among us when it's time to upgrade from our current setups.

Then perhaps I'll finally get to write some runtime managed code!

Post, the first.

Hello there, interweb.

I've been working in video games since the turn of the millennium now. While there have been plenty of ups and downs (oh boy have there), the one thing that I have enjoyed without fail is gibbering at work colleagues about games, how to make games and games.

This holiday season, it was brought to my attention by a good friend that I might as well be doing this online. Not only might I find other people who enjoy the same, I might even spare those work colleagues the bother of it all!

My interests are spread pretty evenly in art, programming and design, with a particular eye towards the bits where they overlap so completely as to be unclear which parts belong to whom. Shader writing, for example, or AI schema.

So here I am, series of tubes. Yoroshiku onegaishimasu.