And, as I said previously.

PANIC! PANIC!

Why am I not further? I have so much to do!

Yeargh!

Ok, I have made leaps and bounds and half the slow was learning pgu , but still. We need to start creating game resources!

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan

I've been debugging collision response code again today. I've resorted to using a very simple case: Axis-Aligned Boxes (AABoxes) for everything. I was using a sphere for the rabbit and a cylinder for the farmer, but that level of detail was unnecessary and it confused the hell outta the code to boot.

I think I've finally got it working reasonably well. Remind me to write up a CookBook entry on this once PyWeek is over.

I also got the farmer to face the correct direction (ie. the direction of movement) which took much longer than it should have.

I also optimised the farmer's A* routine. It's now highly specific to my game, and takes less than half the time it used to take for my more convoluted map. One problem that came up today was that the farmer's hitbox was larger than the A* grid size. This meant that the A* routine would happily plot a course that the farmer couldn't follow due to running into things :) It was a bit silly, really, since the farmer doesn't need to run collision-detection routines, really.

The day's not over yet so I'm hoping to resist the lure of the telly-vision (did you know Australians download more TV than any other country?).

I'm not going to put up any more snapshots or screenies as that would ruin a couple of surprises :)

day 4 went pretty well. i got the player's inventory and picking up of items working with graphics too. today i am going to work on the procedurally generated elements of the game some more.

I have nothing new to show in terms of screenshots. All the work has been in the back end, trying to reduce the amount of drawing I have to do and trying to make it simpler to do collision detection.

Of course, the reality has been that at least 50% of the time has been spent tracking down a silly bug. The moral of the story: when implementing a sparse collision grid remember that int(x) always rounds towards zero. Why is that a problem? Think negative numbers.

Generated a segmented tiger: using SVG, Inkscape and a lot of patience...

using colorkey magenta (255, 58, 255)

size (200x200) will probably be an issue, possibly resize to 128 or less

with time, a routine to do this to any properly designed SVG should improve the game a lot

Uploading large files and fixing .tgz suffixes

There's an upload script to make uploading of large files easier. See the help page for a link.

If you're uploading gzipped tar files, please name them .tar.gz until further notice. The webserver (which I don't control) will run an additional gzip pass over .tgz files when it serves them (no, I don't know why) and thus the files will appear to be corrupted when downloaded. Naming them .tar.gz will work because I've previously asked my webhost to fix them. I've now asked them to also fix .tgz

Thanks to richard's help, I have a much cleaner organization for the code here. That may seem like a dumb thing to do during a time-pressure contest, but previously everything was in one single massive source file. As the world grew, that got worse and worse to dig through.

I've cut a new release, available here, although it has very little in the way of additional text. The entire 'marsh' scene is implemented, though you don't really learn anything from it (unless you're psychic and can intuit the storyline from the minimal list of actions).

I've also added hooks for running things when you enter and leave rooms, which actually allows for more game-like things (randomly providing exits, having actions change depending on the direction from which you enter, etc.) Not sure how much of this stuff is going to get used, but I think with a little more work this framework could actually be used for a minimalistic 'interactive novel' engine. I am using it to determine whether or not certain actions are available, depending upon what you've done before, so there's actually a game-like quality to this that wasn't there in release 0. That's a plus, even if most people might not notice it.

The only thing that seems to have worked well in this time is the art. We now have a large amount of it finished.

I started yesterday trying to get collision detection working. 10 hours later and it still didnt work.
Today I spent another 3 hours on it before I had a new idea. I converted all player movements to use the A* algorithm so that the player would dodge the rocks and not worry about collision detection. That failed to work too.
For some reason the player still moved through the rocks and a whole host of bugs appeared, and the game speed dropped to about 1 frame a second.
After ditching that idea I finally got the collision detection working a few minutes a go, after spending approximatly 15 hours on it. :/
Now its back to getting the rest of the game working.

Hopefully we'll have enough time to come back from that major set-back.

Coding:
Rewrote and cleaned a large part of the code and added the basic framework for animated objects.
TODO: Nice input, introduce the World object, rewrite and optimize rendering, level generation (don't know if I'm going for computer generated or not yet)

Art:
Did an alien with a gun today. Learnt how to do a basic walk cycle.

Time:
I'm kind of short of time, I might have to skip or take it easy on the party tomorrow night :/ At least I have two models now, in case of extreme shortage of time it should be possible to make a game with only those ;)

Here is a really early beta showing the ninja running around.

Urban Ninja Beta 9/6 at 15:32

The keyboard layout:

• Left - Move left
• Right - Move right
• Up - Activate warp