Oblivious Sponge

Overview:

So we successfully jammed on Saturday. Most important things first (a priority that cost me on the day), a pretty picture:

Ok, so it’s not that pretty - but as a result of less than 8 hours work, it’s not so bad. The green dudes move around the world. Two of them drop purple slug trails and do a very dumb wall following. The other two do a similar dumb wall following but bleet sounds when they hit a purple trail. The bleets move around the world, propogating and stopping when they hit walls. Odd, but lovely and general.

Setup:

• Hardware - Two PCs (Dave’s shiny laptop, Dom’s tiny PC and ridicoulously heavy CRT. I’m buying a bloody TFT if I’m ever doing this again! Actually, scratch that, I’m getting me an iBook), USB hard disk, pad of paper.
• Software - Python 2.4, Pygame, Subversion, TortoiseSVN, Emacs/IDLE, Paint Shop Pro.

10 til 11: Dave makes coffee. Sketching general plan on bits of paper. Decide on a discrete 2D grid where agents can move in straight lines. Agents can sense properties of other agents and can spawn/destroy agents. Every agent takes it in turns to move, so world mutated in place.

11 til 12: Cake. Arrays in Python. Simple colour filled images in Pygame representing array. Setup subversion local server.

12 til 1: Matthew arrives and looks puzzled. Got single dude (a green square) moving towards a wall (red squares) and running through it.

1 til 2: Quiche. Got dude bouncing off wall into oblivion. Paved over boundary to oblivion. Added slug dudes that left purple trails. All dudes bounce of purple trails.

2 til 3: Chocolate covered coffee beans. Check out repository to Matthew’s disk for Dave to work off. Realise how much better svn is than cvs. Dom/Matthew work on making renderer shinier. Dave works on having more than one thing per cell.

3 til 4: Yum yums. Dom has written bad isometric engine. Matthew realises a Better Way. All whoop as walls suddenly pop into glorious 1983-isometric-style existance. Dave writes level reader.

4 til 5: Dom draws some not so pretty pictures for agents and walls. Talk about general voxel engine. Remember the company we work for.

5 til 6: Matthew goes home for parential responsibilies. Work on adding sounds to world. Supposedly propogate around the world, letting other agents avoid stuff. Demonstrates flexibility of what we’ve done, but doesn’t quite work.

6: Fin.

Bad Things:

• It’s not a game!
• The isometric renderer took 2 hours
• Mechanical refactoring in Python is hard to do in a bug free way. Compilers do this well
• Time pressure makes ditching bad implementations hard

Good Things:

• It’s a lovely general tilebased AI engine!
• Writing something graphical with Pygame is very easy
• Having 3 people in one room with a tight timescale avoids coding inertia
• Subversion is great

What I Learnt Today (or Saturday, in fact):

The stuff that I find hard is also stuff that other people find hard (shocking, heh?). The difference is that brighter folk keep the options in the background and go for the best option given current information. I typically stay in a stuck state.

Small concrete goals are good. ‘What are we going to do in the next hour’ and the like.

Having someone watching me work is great. Matthew pointing out how stupid my rendering logic was helpful. A step back saved us yet more pain.

More XP style estimating and planning would have helped. We could/would have dropped the rendering/sound propogation and moved onto something like user movable objects, or something more game like.

Python works well when types are fluid, but is painful once you’ve decided.

I get distracted too easily. People pestering me to get on with it is a good thing.

Cake is good.

I bought a Nintendo DS when I was over in the States this summer. I’ve become something of a serial importer and my impatience with European release dates (and prices!) has resulted in ridiculously large DS games collection already. I can’t recommend the console hightly enough - it’s unique, robust, plays all my beloved GBA games, is properly lit and the battery lasts for weeks.

Anyway, the DS homebrew scene seems to be trundling along nicely (although nothing like the PSP) and the architecture of the machine really appeals. I tried some GBA coding a while back but the results always felt like simple stuff I could have done on the PC. The DS and its stylus, however, give me lots of scope for interesting ideas.

So, I’ve just ordered a DS PassMe. It took a fair bit of hoops and jumping - I don’t have a PayPal account and that’s the only payment method the site took. After some pursuading a friendly work colleague ordered a couple using his account - now all I have to do is wait. The guy puts the things together himself, so it may be some time.

The (small) game I’m currently working on needs some spit and polish. I’ve always wanted to write a simple particles engine. Looks like an obvious match to me.

My current tech is C#, Managed DirectX and some HLSL. The particles are alpha textured quads using DrawUserPrimitives. A tiny particle class manages some dumb Euler integration (I’ll crank this up if and when…) and everything, well, seems ok.

Currently I’ve got three sets of fixed particles launched up into the air and subjected to the whims of gravity. They start with random angles and magnitudes, so you get a rough fireworks display:

Unfortunately I now need more information in my vertex structure so the particles can die off at different times - I’m already using color, texture and position. There’s a gap in my understanding between fuzzy-away from memory structures-managed-C# and hard-and-cold-HLSL. Time to tread into the unknown…