I don't know if anyone follows this blog...
…unfortunately, I’ve taken a very long break from this project (hence the lack of updates).
I’m not happy with the way the rendering engine was unfolding, so I think a pretty major revamp is going to be in order; it’s hard to say how involved that will be, since it shouldn’t necessitate much or any reworking from the networking standpoint.
I’m actually hoping to simplify it so that it should no longer really know much at all about what the objects are it’s rendering — just where they are and where they should be moving.
We’ll see how it works out; the real problem is that I don’t know when I’m actually going to start working on this again.
Rendering woes
Yeesh.
Since I’m running the client itself in a single process, anything that has to go from one to the other has to be serializable, since it’s being run through pipes… well, that means I can’t really use some of the pygame types in my basic game objects.
So I’ve started a rendering ‘engine’ that’s pretty much just a set of wrapper classes; each one takes a certain game object (maps and panels right now, I think they’re generic enough that it won’t grow much beyond that), updates its internals with sprites as necessary, and provides update/draw methods (they’re extending pygame.sprite.Group for this purpose).
The problem is that these rendering objects aren’t persistent… they’re regenerated every frame. This might cause performance issues, but the thing I’m more concerned with is animation… I might have to track the position of an actor within the actor model itself rather than within a rendering object, which I didn’t particularly want to do, but if that’s what I can depend on being persistent, I might just have to settle for that little breach of my arbitrary protocol.
I’m not too sure I like the way this whole client method is going anyway… I guess we’ll see. Damn you, Unladen Swallow, hurry up and kill the GIL so I can just use threads!
Pondering multi-tile actors.
Well, I haven’t put any time into this lately, partially because I just quit my job and have been in limbo (have I posted about that? I guess I should read my own blog).
Anyway, one of the things I always wanted to support in the game was characters of different sizes — so instead of fixed-size playable characters and NPC’s, I could define a set of dimensions and a larger sprite that the engine would handle correctly.
I’m pretty sure I’m going to update the motion processing to handle it… I just don’t know how I’m going to handle it in the rendering engine. The real problem is how to handle things like doorways. If I allow two-tile-wide characters, I either have to make sure all movement happens in one-tile increments or (if movement increments are equal to the size of the character, which is what I intended to do), that all doorways are wide enough to accomodate all character sizes.
Now, that seems simple until you consider that I wanted to build map rendering in such a way that where you start determines where your map view is… it just feels more dynamic. The implication here is that a 2×2 character won’t always fit onto a 2×2 grid, but a 1×1 grid — so the door would have to account for that character’s offset if he could move by any increment other than 1 tile at a time.
I’m not sure if that clearly illustrates the problem, but I think after typing this I may just go with limiting the movement distance to a single basic tile. It’ll feel slower for large characters, but that kind of makes sense, and it’ll keep doorway width predictable.
Um… thanks for listening!