PyWeek - Mauvesoft

[ mauve @ 14:27 ] Performance problems identified

I have tracked down the performance problems with my game to Pyglet's use of VBOs. It turns out these are dreadfully slow on my machine - a Radeon HD 4850 on Ubuntu Jaunty - and disabling them globally makes the game run much faster. I have thus added a commandline switch (--novbo) to my game to disable VBOs. If my game is giving performance problems, try this first; if it turns out you are still having performance problems, you may be fill-rate bound, in which case you can try reducing the window size (-d option).

I don't have access to enough machines to know whether VBOs are best to default to on or off. I would be very grateful if you could let me know whether it runs faster with VBOs on or off, and on what OS and hardware (the -r option shows framerate).

This also explains why so many pyglet games run like a slideshow for me. I thought they were just buggy.

show (6 comments) // (login to comment)

[ mauve @ 00:57 ] Well, I'm glad that's over

I don't think I could have carried on. I'm completely exhausted. Tomorrow I shall drink copious amounts of beer and try to forget all about ninjas and vectors and texture coordinates.

Sadly the final game is still running poorly, with wonky framerates that even with hours of profiling I haven't been able to completely track down, though I have made huge strides. Pyglet sprites are slow, for one thing: the quad is rebuilt when you set any property - position, opacity, colour, rotation - so I had to use the internal, underscore-prefixed names, to work around this.

According to sloccount:

Total Physical Source Lines of Code (SLOC)                = 2,369

But also:

Development Effort Estimate, Person-Years (Person-Months) = 0.49 (5.94)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))

I like to think Python lets you do in a week what most developers take 6 months to do (and it's not just that COCOMO is a poor model for small projects).

show (9 comments) // (login to comment)

[ mauve @ 20:20 ] Steam

Running out of it. I feel completely knackered, but there's still much I need to do. The gameplay is far from smooth, and the AI is buggy. And there is only one level. But it's a lot more playable than it was this morning, somewhat faster, and a lot more polished. There's even a multiplayer mode.

show (1 comment) // (login to comment)

[ mauve @ 11:15 ] Last Day...

...and I'm already off to a good start, with a main menu, and play already seems a lot better just for having given the samurai 4x the health of the baddies. Plenty of time left for tweaking the gameplay.

show // (login to comment)

[ mauve @ 23:57 ] Just need some polish

I started today by listing a table of all the animation frames I need, and drawing them, which set me in good stead to actually write the game.

My game is playable as a game now, but the combat needs balance: the AIs acts utterly aggressively - running towards you and swiping as soon as they gets the chance. A hit doesn't freeze up your opponent in pain yet, so you can't hold the upper hand if you strike first.

Also a problem is the framerate - the game doesn't adequately support the amount of objects I would like. Profiling to track down the problem has allowed me to fix a few bugs where things have been called twice, but 8 trees and 5 ninjas is bringing the framerate down to ~25fps. That's enough to have a game at least. My vector class is one bottleneck. Oh, and I've had to remove the sounds due to segfaults.

I'm quite proud of this screenshot. It is remarkably close to the idea I originally had in my head 6 days ago.

show (3 comments) // (login to comment)

[ mauve @ 11:24 ] Internets down, physics refinement

My internets have been down for the past 24 hours, due apparently to a burst water main flooding the exchange. Below is my diary entry for last night.

Today's progress was poor, which is a serious setback when I'm estimating having 2 programming days left. I spent too long today tweaking the character physics. The physics are very good now, and the upside is that the terrain feels great to run and jump on - you get some nice speed kicks when you land on a downward slope.

The fight to get friction working came down to numerical accuracy. Friction acts in the opposite direction to the player's velocity along the slope, if the velocity is not zero. But as you come to a stop, this velocity becomes small, but due to floating point errors, not actually zero. Normalizing this vector gives completely the wrong results - it actually starts the object moving again.

The moral of this story is that in a 2D vector class, __nonzero__ should read

def __nonzero__(self):
        return abs(self.x) > ERROR_TOLERANCE or abs(self.y) > ERROR_TOLERANCE

Now I'm up against it though. I have two days in which to take what is basically a platformer engine - though I am fairly satisfied with it - and make a game with it. I have plenty of innovative ideas to add but I value production and fun much more highly.

In today's screenshot I've added some trails to the player to illustrate the physics in action - notice how the player's velocity changes as a function of the terrain.

show // (login to comment)

[ mauve @ 01:17 ] Level loading, physics

It doesn't look like much from today's screenshot, but I've now added the ability to load terrain and objects positions from SVG, side-scrolling, and a proper physics engine that replaces the ad-hoc x = x + 5 lines throughout my character classes, and will hopefully give fewer problems as the world gets more complicated.

Not to mention I've finished up the bamboo graphics and drawn a few frames more animation for this cheeky chappy:

He's not very visually detailed, but I'll wait and see if he looks OK in-game or needs more work.

show (3 comments) // (login to comment)

[ mauve @ 00:43 ] The Climbing of Wobbly Trees

I'm sort of pleased with today's progress, having taken a tangent faffing around with background trees that I just don't need; my background looks great in my Inkscape mock-up and it would be simpler and run faster just to drop it as a texture into the game.

I also spent quite a bit of time trying to find some koto and shakuhachi music with a public domain or Creative Commons license. Not much luck, unfortunately. I found a few references to albums that are in the public domain, but I can't find the albums. At the moment all I have is a piece of Honkyoku music from Wikimedia Commons, which is in the right ballpark but doesn't convey the right atmosphere.

Anyway I kept plugging away and wobbly trees and the beginnings of some climbing mechanics also landed. The static screenshots look better than the in-game graphics feel - the animations are clunky. I need to generate a few different tweens between my animation frames. If there's time, of course.

show (5 comments) // (login to comment)

[ mauve @ 00:12 ] First day

So I'm close to calling it a day on day 1. I've made a start on a variety of things, first and foremost the artwork. So first day stats are:

• 21 frames of character animation
• 319 lines of code
• 1 scenery object
• A passable terrain renderer with grass in the wind

Hopefully, that's a good start. I'm starting to feel my way around Pyglet, which is new to me, for one thing.

Now I'm just torn between hooking up Box2D for physics or rolling my own, simpler, platformer physics. I'm swaying towards the latter because my requirements are quite simple, except for one or two ideas I probably won't get onto during PyWeek. Hopefully avoiding adventurous physics will save precious time.

show (1 comment) // (login to comment)

[ mauve @ 10:59 ] Wibbly-wobbly theme

Wibbly-wobbly was the theme I thought might win. The other themes were too specific - you either have an idea that works or you don't. Wibbly-wobbly on the other hand, is something that you can tie into any game that has springy animation or dynamics.

Fortunately it was also the idea I spent most of yesterday thinking about.

show // (login to comment)