Submitting a bug is... KIND of like contributing... right?
Since I enjoy writing at myself so much, I figure I’ll go ahead and update this! :)
I finally started getting back into this little by little, and actually made some pretty good progress. I fixed the rendering quirks I was running into by digging into and correcting my usage of the multiprocessing library; I still have some locking to implement, but it’s quite trivial compared to the major revamp I just finished.
There’s just a small problem left with rendering on moving to a new map, but I know where the problem is, and it’s something that just hasn’t been fully thought out yet.
As for the title, as I was going through my multiprocessing implementation, I hit a VERY frustrating issue. Long story short, it turns out you can’t start this particular type of shared memory controller in a file that’s imported by the invoked script — whether it’s created in an import or not, is start() method MUST be called from the script you actually RUN. Yeah, screwy. I filed a bug, though, so rock on!
Things that are now working:
Client
- Input, graphics and networking are handled in separate threads
Server
- Processes are spawned for and take input from any number of clients
General
- Movement around a map and between maps works
- Collision detection with map boundaries and impassible tiles works
I’m noticing that the graphics and networking processes are eating an irresponsible amount of CPU time, so that’s going to be something to look into, but I don’t think it’s going to be a big problem; there shouldn’t be anything too non-standard about the way I’m handling those things.
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!