I decided not to go 3D this time, to see exactly how hard/easy it is to create a game using *just* what PyGame itself provides (i.e. no PyOpenGL, no 3rd party graphics engines or GUI libraries, etc), coupled of course with the features of Python's standard libraries. I also decided upon an isometric game.

However, I've never done any "pixel art" before; subsequently, I have spent far, far too long trying to draw a little train facing in eight different directions - not to mention wasting most of the first day struggling to come up with an idea. I'm also beginning to realise that I'll need either a more complex system for calculating offsets of mobile objects, or yet more drawings (fortunately just shifted versions of the existing viewing angles; I'll probably opt for the brute force option). Suffice to say the game won't be particularly heavy on eyecandy.

I'm also realising that isometric graphics engines aren't as simple as I first thought. Creating the landscape tiles wasn't a problem; nor was the algorithm for rendering the ground itself. It also took much longer to draw the train tracks than it did to get them depth-sorted and overlaid on the ground. However, getting the train properly depth-sorted, not to mention actually following the track, is proving challenging.

Currently, the train makes it to the third bend (with various popping artifacts as assorted track pieces are incorrectly drawn over the top of it) before disappearing into oblivion, a result of failing to find the next link in the track; this is the result of drastically underestimating the requirements of a robust track-following algorithm. Rethink in progress.

In all, I probably should have stuck with OpenGL, as used in my entry for the first challenge; I suck at 3D modelling, but overall it probably would have been far less time-consuming - and much more fun - modelling & rendering a 3D steam engine than drawing eight separate sprites by hand with more to come.

I'm not going to tell you what gameplay will be like, but it won't involve actually driving trains - neither directly nor through signals, anyway. :)

After my last diary entry, I completely removed the train code I had created, essentially leaving myself with something that just rendered a fairly lame isometric landscape. I lost a lot of motivation at this point, and it's not been easy getting it back.

However, it has proved worth it in the end. I now have a train that can follow tracks, and is always drawn on top of them (not with bits of track over it, as in my last attempt); I also have a framework in place for having static "tall" objects on the map. The engine now differentiates between ground cubes, flat 'overlays' such as the rails, and static & mobile objects, which sit on the ground but are not flat and hence must be rendered in the correct order.

No new screenshots, as firstly they would still be of just a train on some tracks, and secondly I just deleted my hard-coded test level in favour of starting work on a level editor. The rest of the game should be "easy" from here on out - there are a few parts that will no doubt need debugging, but instead of jumping head-long into things as I did in the beginning, I have all the remaining algorithms already thought out, and am regaining confidence.

I'll hold off on divulging anything about gameplay until I have a screenshot that actually demonstrates it - something I should hopefully have later today. :)

Well, nearly - you can't actually save or load level files, nor define completion goals, but it's getting there. It's also accessible from a working menu, which didn't exist a few hours ago, with working, saved options. :)

I know I said I wouldn't post another screenshot until I had some gameplay, but it's taking longer than I'd anticipated to get this stuff in place - not helped by the documentation for the behaviour of

pygame.event.set_blocked(None)

and

pygame.event.set_allowed(None)

being the wrong way round, leading to seemingly random lockups that took a good half hour to track down. Luckily I already suspected the event queue based on past experience, or it could have taken much longer!

Now with working main menu, saved options, three new static object tiles, and working load/save from the level editor.

Gameplay (tomorrow's job) will be a puzzle game of sorts. Levels will contain terrain and objects, but by default no track or trains. Track pieces will fall from the sky tetris-block style, and you will have to guide them to where they're needed - they can only be placed on empty grass, or on older track pieces. Each time you make a valid loop of track, a train will appear, netting you a bonus :)

Possible level goals could include creating a certain number of trains within a time limit, creating a single track loop to join all the stops in a level, etc. Another possibility is to have a running timer, attempting to create trains every minute (for example); if when the timer next comes round there are no free track loops and you have not completed the level's objectives, you will lose a life.

I've yet to see what will work best, but once I get controllable pieces, I'm sure I'll figure something out.

Uploaded with less than a minute left! I thought I had everything worked out, and today would be mostly polishing, but in true PyWeek style, it turned out that there was a lot more to do than I thought, and the whole thing didn't come together until the last minute - literally.

The game does have sound, music & high scores, but has other rough edges: few levels, no pause facility, very bare appearance (black background, plain menus, etc.), few levels... it is, however, playable. Up to level 3, at least - I've actually played levels 4 or 5 myself yet.

I am slightly annoyed that PyGame doesn't seem to obey loop commands in MOD music - the background music for my game doesn't loop correctly at all, but it's a long enough loop that you don't really notice the join (or lack thereof) when playing. Anyone know if this can be fixed?

I'm fully expecting a bug report or two - for example, I have a feeling that if a train were to do down/right directly in front of a building or tree, the train may become partially obscured by it; however, I never got time to create a test case for this, so I have absolutely no idea if it's true or not. Such is life.

I'd like to thank my job and my girlfriend for taking up so much of my time, and Richard for not taking me up on my suggestion of allocating two full weekends for the challenge - without you, I might have been relaxing a few hours ago ;)