Spiral Mania

I know I said I wasn't going to do a third warm up, but I need to get away from the Wyggles for awhile because they are indeed a can of worms.

So instead, I'm going to do another old favorite of mine, the spiral graph. The picture shows the previous incantation done up in Java controlled by JavaScript.

This might give me a better idea about how I can use pyglet in different projects.

Peas and Queus

2 days, 1 hour, 26 minutes until PyWeek 6. There is no time for a third warmup, and I can't really think of anything anyhow. I was going to do some demo using Cocos, but I'll use the remaining time to tidy up the two warmups I have. Hopefully I'll learn some more tricks to go in my Python bag!

I'm Getting Warm Now

Well, that was fun. After about another hour I updated the rest of the sprites and shook the bugs out of the physics code. All that's left is to set a timer to make the apple reappear after it is eaten.

I like my little Sprite Engine. It's all I really need on this project.

I'm tempted to start in on doing some AI, but instead I think I'll switch gears and move on to PyWeek warm up #3!!! (Does this mean another Blog?!)

I'd like to thank Alex Holkner and Richard Jones for their encouragement and advice. I didn't need a lot of help on this one but I might on the next!

Unfortunately I can't use this stuff in the contest, plus it's got a long way to go. I'm either going to use Cocos or the Sprite Class in Pyglet or ... who knows!!!

After PyWeek I'll come back here to do some AI like I promised. (I should probably stick to the sprites!)

Slowly But Surely

I solved the depth problem. The solution is extremely simple.

It's pretty much as I described earlier. Only I decided against a separate Renderer class. The Sprite Engine will do.

Now it's on to updating the other Sprite derivatives and fixing up the physics!

A Can of Spam

This isn't as tasty, but it will get the job done for now. This is suppose to be an experiment in reactive AI techniques, not "Hey! I'll write the world's most killer sprite engine in Python!".

I really only need two classes.

Renderer

This class will sport methods such as create_layer, find_layer, render, etc.

Layer

This class will have methods like add_sprite and render.

The Simulation Process

Sprite Engine steps the sprites and calls render on the Renderer. The Renderer calls render on the root Layer which calls render on the sprites attached to it and all sublayers, etc, etc.

A Can of Worms

Or should the title have been "A Can of Wyggles"?

My main problem here is that a Wyggle is composed of multiple segments, and the head gets created before the tail segments. Not only that, but Wyggles grow, so they need to be inserted into some kind of depth group. I mean, if two Wyggles intersect we don't want some segments of one Wyggle appearing on top of the other Wyggle's segments and others below.

Hrmmm...

Basically, depth alone won't cut it and neither will layers.

Layer is a Depth Group

I think layers with depth sorting is the best approach. Each sprite has a depth or z index that only pertains to that Layer. It's like divs in DHTML.

I thought about just translating a Sprite Engine I had written in Java 6 years ago, but after looking at it I think it would be better to start from scratch. I've learned a lot since then.

Botworx VR in 2D?

Botworx VR is part of an agent framework that I've been developing privately for the past 3 or 4 years. It's written in C++ and uses Ogre for rendering and ODE plus Bullet for physics.

I really, really wanted to avoid doing this. But I don't think I'll be satisfied unless I use the concepts and the component oriented design that I used for it.

Are You Sure?!!!

Okay, I could use the stuff from Pyglet contrib or other projects out there, but this way I can be sure things are exactly the way I want it. And, who knows? It might turn out better!

In Closing

Be sure which can of worms you open.

Pyggles is now Wyggles

Pyggles was a stupid name. Why didn't I choose the obvious in the first place?