Day 3: smarter baddies :)

richard on 2009/09/01 10:55 of Easy

I spent most of today at the science museum with my family; my daughter absolutely loved the planetarium show and thought some of the Star Wars exhibit and regular exhibits were cool too. Science!

On the game front though, I managed to get some new code in:
  1. proper sprites for effects
  2. using Inkscape's rasterisation for some smaller in-game graphics now
  3. first tree & house
  4. added ledges - can move through sides & bottom but not fall through top
  5. baddies follow complex paths including loops and open paths
  6. fleshed out the structure of level 1 more
The ledges were added as a direct result of game testing by Abbey - she kept wanting to jump up to tree branches from the ground only to bump her head into the branch. Obligatory screenshot from the very start of level 1:


The baddies follow paths properly now (yesterday they just when from point A to point B and back again). The really neat bit is that the code to handle the pathing is:

def cycle_path(path):
    path = itertools.cycle(path)
    last = euclid.Point2(*path.next())
    while 1:
        next = euclid.Point2(*path.next())
        last = yield euclid.LineSegment2(last, next)

Given a path consisting of (x, y) points. If the path is a loop (path[0] == path[-1]) then I create the path cycler with cycle_path(path[:-1]). If the path is open then I create the cycler with cycle_path(path[:-1] + list(reversed(path))[:-1]) (so bounce from end to end).

I pass in the current position when I ask for the next line segment so that there's no unsightly jump to move the baddie from its current position to the "proper" start position for the next segment. The baddies wobble along their path, you see :)

So not a huge amount of progress today but I'm very happy with how it's progressing regardless.

(log in to comment)

Comments

alex on 2009/09/01 11:46:

Looks like you're progressing in all kinds of ways that I'm not :-)

You should be using vectypes instead of euclid though now.  It's less weird.

tartley on 2009/09/01 11:55:

Hey alex. I don't understand why vectypes are typed (int, float, etc). Are they stored in ctypes under the covers for easy passing to opengl or something?

richard on 2009/09/01 22:41:

Yeah, I'm a little confused about that too. Also I'm not sure what vectypes offers over euclid given that euclid has types I'm using that vectypes doesn't :) (ok, they're pretty simple types, but still...)

The vector library from the Super Effective folk is actually probably closer to what I want and I'll probably switch to using it. It has a whole swathe of game-useful vector operations built in (rather than being a more general-purpose library).

I'm using their squirtle and porygon so I might as well us their vector too :)

Chard on 2009/09/02 00:27:

The key thing with vectors I've found is that the most common operation on them is making them. Most vectors are used once and discarded. So from a speed point of view inheriting from tuple is a strong option.

But for my money the most important thing for a vector library to do is vector geometry. It should be easy to rotate and reflect and scale vectors as well as manipulates lines and other geometric objects. Our entry this PyWeek has generated decent 3d vector geometry (Vector3, Triangle/Plane, etc.) so expect something with that in the same vein as our current 2d vector library following the challenge.