Just me. I did pretty much everything except for the music (I would have liked to have done that too, but the schedule was tight).

The music comes from Kevin MacLeod's awesome library of Creative Commons songs (incompetech.com). Hopefully the judges don't get sick of them - it looks like a significant number of this year's entrants are using Kevin's work.

I also had the invaluable help of a number of my friends and my family with testing and advice and such.

It's a 2D physics-puzzle-platformer, with shadows.

The game is intentionally abstract and linear. There's no dialog or explicit story or "save the princess" objectives. And there is no player death. The idea is to let the player flow through the game, solving puzzles as they come to them.

From a technical standpoint it is a platformer built around a physics engine, with 2D geometry-based soft-shadows from multiple coloured light sources.

At the start of the competition, the idea of doing something with 2D occlusion just popped into my head. Shadows were the obvious thing to try. I would have liked to try rain as well, but time was limited.

I started to learn to program "properly" in 1999, when I was in high school (I say "properly" because I had messed around with C64 BASIC and QBasic long before then). My family didn't have the Internet yet, and so I was learning C++ from magazines, using compilers from cover-disks.

Once we finally did get the Internet, I stumbled upon NeHe's OpenGL website and started game development. After a couple of years learning the ropes I had the opportunity to take over the Stick Soldiers 3 project (incidentally: also a polygon-based platformer) from the original developer of Stick Soldiers 1 and 2.

That four-year calamity could be kindly described as a "learning exercise". Once I finally killed it off, I went and focused on finishing my degree in Software Engineering, which I hadn't really been paying attention to.

I also started paying attention to new technology - C# and XNA in particular caught my eye as a vast improvement on the way I had been doing things. So I started learning and working with those, which culminated in me entering Dream Build Play this year.

When I started I was "in it to win it". The prize money and being noticed by Microsoft for XBLA would be of enormous value someone like me, just starting out as an indie developer.

Now that it's over, and having seen some of the other jaw-dropping games out there, I'm not nearly as confident about winning. That being said, I'm very pleased with what I accomplished from scratch in just four man-months. I have to keep reminding myself that many of the better-looking games have taken significantly longer.

I would have loved to enter in previous years, but this is the first time that I've had the time to spare.

Absolutely!

I started with the idea of doing 2D shadows. This meant a 2D game - and a platformer is ideal for a gamepad-controlled game. A polygon-based (as opposed to tile-based) game would best show off the shadows. I decided it would be best let somebody else's physics engine handle the required collision detection, and that that would give me physics for free as well.

I dedicated the first month prototyping those two components - shadows and platformer-on-a-physics-engine. This went really well and by the end I had seemingly solid core mechanics.

The next month was supposed to be spent working those prototypes into an engine and an editor. But about half way through I found that the shadow-generating code I had come up with was absolutely riddled with bugs that the prototype wasn't exposing. It took about two weeks to fix - a huge portion of the four month schedule. From that point on I gave up on any kind of structured schedule and just winged it.

In the last month I brought together a group of my online friends to help me with testing. About this time I started working all day, every day - serious crunch. It was also about this time that I started moving ideas from my head (at least the ones that could be done with the time and technology I had available) into prototypes.

It wasn't until the last week and a half that I actually started work on the final levels. At this point I was using the programming equivalent of duct tape to patch up all the bugs (mostly performance issues) that having real levels introduced. The game was finished about six hours before the deadline.

Dark is very short - about 20 minutes of gameplay. I had storyboarded twice as many levels. Most of the light-based puzzles had to be cut because they weren't finished in time.

I had also wanted to have more "critters" in the game. I had designed some interesting interplay between frail, organic, insect-like light-emitting creatures and blocky, solid, shadow-casting creatures. The "triangle man" and the player's avatar are leftovers from the shadow species.

I would be a bit more careful with the math-heavy stuff. I'd write some more flexible visual-testing code (everyone who has moved from OpenGL to XNA misses being able to just spit out GL_LINES). And I'd probably try to work things out on paper more carefully in the first place, too.

For level dynamics I went with an actors-with-properties model, similar to the Unreal Engine. While I'm sure this works for a huge team of level designers who can't program, and a huge team of programmers who maintain the system; for me it was one big mess and a lot of work whenever I needed to add a new level behaviour. In the future I plan to replace it with a code-behind, similar to how WinForms works.

I'd definitely start again by prototyping and experimenting with the core gameplay mechanics, quickly and separately.

After the prototyping I'd continue with the very-YAGNI, build-it-directly-on-XNA, minimal-code, rapid development, code-is-the-design (although that's not to say "badly coded") approach I've found so suitable for game development (except for the "maths-heavy" algorithmic stuff that I mentioned earlier - that, I would be more careful with). It makes my inner software-engineer a little queasy, but the point is that it works well - especially being a one-man shop.

And I'd build a fancy-pants level editor again. It's a lot of work to have a proper Windows GUI, WYSIWYG, undo/redo support, and the ability to play the game in the editor. However all that effort means that those same prototyping and experimenting techniques can be used again at the level design stage. Plus it means that the highly important results of playtesting can be integrated almost immediately.

Speaking of which: playtest, playtest, playtest!

Yes. In the months before Dream Build Play I made a couple of small XNA games. I also used it as a platform for my thesis at university.

Self taught. I checked out the occasional tutorial and community sample, but by-and-large I simply read MSDN whenever I needed to know something.

I used the Farseer Physics Engine. It would have been insane to try to make my own.

But I did have to bring my own platformer movement system. And I had to fix a few of their bugs myself - a demonstration of how important source-code access is for such a critical component.

In the editor I used some more libraries: one for line-drawing, one for triangulation. The triangulation algorithm wasn't entirely robust - I spent a lot of time fiddling with polygons to try to coax them into not being inside-out.

C# and XNA is easily the most productive platform I have ever worked on or heard of (short of a full-blown engine). I was able to work many times faster than I did back in the bad old days of C++ and OpenGL.

Some bits of the XNA documentation assume knowledge of DirectX, and expect you to work out the mapping between the two (in other words - in several places the XNA documentation uselessly restates the variable/enumeration names).

Fortunately I know a number of DirectX users who I could ask for help, and I became fairly well-versed in the workings of DirectX myself, towards the end. Poking around with PIX also helped.

The big problem on the Xbox 360 is keeping your frame rate up. I hit this issue three times during development.

A well-known problem with XNA on the Xbox 360 is that the garbage collector is ridiculously slow, such that you practically cannot allocate memory while the game is running. I knew this ahead of time and so hid all my allocations in the blackout between levels. Unfortunately Farseer Physics (the version I used, at least) was allocating memory in a couple of places during updates. The answer to this is to use the CLR Profiler to track down where they happen. Once I realised memory allocation was the problem, it was surprisingly easy to fix.

The next problem was when I found myself fill-rate limited - partially because I insisted on running at 60FPS at 1080p with 4x MSAA - mostly because drawing all those lights and shadows writes to an astonishing number of pixels. I had been hoping to get away with simply culling light sources that aren't on-screen, but in the end I had to add some pretty aggressive scissoring as well.

Everything worked fine until the DAY BEFORE the deadline, when I found that some of the more complicated levels were making me batch-limited (too many draw calls). I spent the last day furiously adding more culling, as well as tweaking the levels to have fewer polygons in each light's influence.

In the end, one level was just too slow (about 45FPS) - so I hacked in a flag for that particular level, so that it would run at 30FPS instead of 60.

I moved to 3.1 about 2 weeks before the deadline. I don't use any of the new 3.1 features, so the conversion was trivial.

Well - there are lots of hints embedded in my answers. But the bottom line is to not forget that you're making a game. The moment you start thinking of the end product as an engine or an editor or a library or a tech-demo, you've lost focus.

Yes. My only complaint about XNA is that it's not cross-platform enough. I would particularly like to try developing for Silverlight and for the iPhone - at least I can still use C# (I've got my eyes on SilverSprite and MonoTouch).

In the last week or two of the competition, the code turned into a bit of a mess, and I introduced some fairly severe bugs into the editor. So I'm going to pull apart all the "duct tape" additions from that mad scramble to the finish line, and fix up a few niggling things that I never had time for.

Then I plan to expand Dark to the size that I originally designed for and put it up for sale on XBLIG (if not XBLA, if by some miracle I get Microsoft's blessing), and also selling it on Windows.

After that I'm keen on getting something going cross-platform between Windows, Xbox 360, Silverlight and iPhone.

Of course! If I started making game for Windows right now, I'd use XNA. And, seeing as you can port it to the Xbox 360 almost "for free", it's a no-brainer. I don't think I'd target XBLIG on its own - I don't think the market is big enough.

Screenshots and videos, anyone?