PyWeek - Sleight of Python

[ Marlow @ 20:19 ] Quadtrees

To aid with collision detection and to speed up drawing, I added some quadtree code to my game and uploaded it to the pygame cookbook. It comes with a small example showing how to use it.

show // (login to comment)

[ Marlow @ 18:39 ] readme.txt

I have to hold up my hands and confess that I thought I had uploaded the Readme.txt. I apologise to everyone for making you hunt down euclid.py and figuring out how to play the "game".

Thanks also to everyone who took the trouble to comment, as it was very encouraging. Over the last couple of days I've made a lot of progress with the level geometry and will soon be in a position to upload something a bit more robust. I'm still working on this, at least when time permits. I'm having fun, and hopefully the source code might save people a bit of time.

It certainly makes a refreshing change from hacking XML in Python, which is currently a large part of my day job.

show // (login to comment)

[ Marlow @ 23:10 ] What's done is done - post mortem

Well, what I ended up with isn't much of a game. You can move around the level, and bump into walls, but not much else.

What went right?

• initial concept

  My programmer art is worse than most, so I had to think of something that I could draw. Thankfully all choices of themes involved magic and even I can draw a magic wand in MS Paint.

• path drawing

  The "level turtle" turned out to be a good way of drawing levels. I'm pleased with how it works.

What went wrong?

• time management

  I would have liked to have spent more time being able to focus on this, but real life got in the way. Work was busy so I didn't get much in the way of thinking done during the day. I also became hung up on getting one thing working... see below.

• time spent on collision detection

  If I had to do this again, I would have abandoned the idea for multiple paths in a level and made a playable game with a lot more going on. As it was, I spent too much time and effort trying to stop the wand from colliding with the "invisible" lines where paths overlapped and never did get it working satisfactorily.

Summary
On the whole I'm pleased. I didn't get nearly as far as I would have liked to, but I'm still quite pleased with the results. I love programming under pressure - most of my best code was written that way.

show // (login to comment)

[ Marlow @ 15:34 ] Why the world needs non-experts

Yesterday lunchtime an old, non-programmer friend walked by my desk. I mentioned PyWeek and told him about a specific problem that I was having with collision detection, due to the way that I've been drawing the paths, and how I was writing a fancy algorithm to get around it.

"Call me simplistic," he said, "but why don't you just read the pixels from the screen at the points where you've detected the collisions?"

Check between 4-8 pixels, or write a fancy algorithm which may not work? Hmmm... time is short! I feel a stencil-buffer coming on.

show // (login to comment)

[ Marlow @ 14:45 ] How much time do you take?

I am curious to know how much time people spend on their entries. So far this week I've managed around 30 minutes each morning, plus an average of around 2-3 hours each night and maybe 30 minutes at lunchtime (such as now - very late lunch). Progress has been less than stellar ... but at least it has been progress.

show // (login to comment)

[ Marlow @ 06:42 ] Sparse collision grids: Part I

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.

show // (login to comment)

[ Marlow @ 19:46 ] First screenshot

After a busy day at work yesterday, I couldn't think straight. I was trying to use turtle graphics to draw the paths that made up the level, but couldn't get it to work. Today I made an early (5am) start and broke the back of it before leaving for work.

Now it's a choice between collision detection and going back over my code to make it work "right". Which is going to slow me down more?

Right now I'm leaning towards doing the collision detection. If I need to refactor then I'll find out soon enough, and there's always darcs to fall back on.

show // (login to comment)

[ Marlow @ 11:16 ] Slept on it

The challenge started at 1am for me, so I stayed up until the theme was announced, then promptly slept on it, wondering how it could work with some of the ideas I'd had.

So, here goes.

"A powerful wizard was attempting a disappearing act when he was kidnapped by his arch enemy and imprisoned in a magic world. His nemesis took his wand from him and hurled it deep into the magical world, condemned to spin for all eternity. Luckily, the magican somehow managed to maintain a telepathic link with the wand and is trying to guide it back to him so that he can escape and finish his disappearing act. Unfortunately, the wand just won't stop spinning."

show // (login to comment)

[ Marlow @ 23:01 ] Software

Before I start, I need some libraries, otherwise I won't get too far. Question is, what to use? I'm not familiar with any Python games / graphics libraries, so I'm going to have to play safe. Here's what I've installed so far.

• PyGame
• PyOpenGL
• Euclid

show // (login to comment)

[ Marlow @ 13:45 ] Anything > Nothing

Last PyWeek, I did nothing. Almost anything will be an improvement that.

show // (login to comment)