Last night's progress
Well, I got the client and server on speaking terms, which is a plus. They’re pickling and compressing to communicate; I just need encryption now, which won’t be difficult and will have to wait until I have actual authentication systems in place (which is a little while out yet).
The client is already tracking the game world (well, a set of maps, anyway), so that’s fine; it needs to be using a child class that adds rendering information and methods to the maps, but that’s pretty trivial, and it means I can use most of what’s there on the server, which will track the basic map, since it doesn’t render anything.
I think I may be to the point of taking a break on the really technical stuff and getting some rendering going. Making the client do something useful, at first anyway, is going to revolve around activating objects and then adding a chat interface; doing that on the console would probably end up making more work for me than it’d be worth, so I think the next thing I do will be getting basic rendering up and running.
From there I can start work with rendering panels for menus, chat boxes, alerts, etc., which I’m hoping to use for anything that displays text to the user — if that works out, and I’m not sure why it wouldn’t, I’ll be able to use them to build the entire menu system very quickly, including the initial startup and login interfaces, which will be the starting point for authentication with the server.
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!
Inter-map movement!
Nice! It took longer to get around to working on this bad boy again, but I put in a few hours today and managed to get adjacent maps associated with each other and teach the engine how to handle movement around and between them.
One thing I’m wrestling with is how to make player object handling generic. At the least, a payer is just an instance of Actor that the client understands it needs to follow; however, as far as the client, I’m kind of stuck sending the player directly to the map on instantiation, otherwise it’ll get lost in the shuffle of inter-process communication.
This may not actually be a problem, since the server should not have to track a special player object, just generic actor objects, which I believe won’t be problem with the existing code; the necessary methods should work fine with actors that aren’t passed as players. I’ve moved most of the necessary instantiation code out of test blocks and put it closer to where it should be, which is encouraging and went pretty well.
A little bonus is that by dumping an actor into the map separately from a player while experimenting with the movement showed that my tracking model seems to be sane — the actors could exist on the same tile (this is intentional), were tracked correctly, and did not interfere with one another.
Oops.
Well, turns out instead of simulating a queue with a manged list… I should have just been using a managed queue. Brilliant, huh? Yeah.
Going to apply this when I get home and hopefully I’ll end up with an execution queue that can accept and process arguments pretty much the way I’ve been attempting to for… oh, weeks now.
Frustrating. But hopefully it works and then I can move on to something new.
Woohoo! Map movement!
Yeah, I know, it doesn’t look like much… ;)
This is just a unit test to ensure that movement between map tiles is being handled correctly. Tiles you can walk on are labeled as []; tiles you can’t are marked as //. The tile the actor (player object) is on is marked with the number. This is a really simple way to make sure the map is only allowing the player to walk on the right tiles (earlier on it successfully keeps the player from walking off the map, which is good, but will be handled slightly differently for multiple maps).
It (purposefully) ignores animation and view (the subset of this map that should be displayed on screen); separating these things is something I needed to accomplish anyway, since my previous ‘tech demos’ had them tied together, which is not acceptable for the actual client.