Back at it! Pydoc, processing and client-server communication.
OK… I’m finally putting a little more time into this project. Man, it’s been way too long.
I’ve been pondering using pydoc to make sure I can keep a handle on what I’ve written, what needs to be done and how it’s working. I’m now doing so, with simple doc strings for my classes and methods, but the tool itself is a bit messy — not that I’m criticizing it, just that doing its job well necessitates putting a whole lot of information in one place, and that’s just difficult to format. It’s still useful, though; it’ll happily run as its own local web service, so all I have to do is nohup it as root and it happily runs while I’m working; plus, it recreates its pages whenever you hit them in the browser, so changes to the code are reflected immediately. Handy!
As for the actual game, I had intended to start doing a bit of graphical work next… after reviewing the client stuff that’s already working, though, I think it’ll be a lot more useful to get communication between the client and server working first.
I quickly ported over the old threading-based server I wrote initially to use processes instead, tested it and it seems to be happy. I do love the fact that processing mirrors the interfaces to threading so closely; despite IPC being a lot more involved than talking between threads, at least it makes the basic functionality almost trivial to swap.
Another related but largely irrelevant (mwahaha, ponder) tidbit: I use git for version tracking (god how I love it). For business stuff I have my repos set up on an Amazon EC2 instance (don’t worry, they’re on an EBS volume); however, for local stuff I usually just used my file server. Unfortunately, I haven’t bothered to hook it up yet, so that doesn’t do me much good. Instead, I managed to set up a bare repo on my EC2 instance and push all the previous refs out to that… and it took all of five minutes to get it set up and sync that fresh repo with my local one. Most of that was spent looking for the right command (git push --all). MAN do I love git!
OK! Back on topic, I’m hoping to get the client sending movement updates to the server tonight. I may not get that far, as the whole IPC with processing thing is a hassle (and despite the server happily accepting connections and spawning handler processes, it needs some infrastructure to manage incoming requests from multiple procs, apply them and respond).
I don’t think this will encompass sending game state updates down to the clients; I still have to figure out exactly how I want to handle that. diffing cpickled game state representations and sending a patch is kind of an interesting idea, but it probably wouldn’t be all that fast and it’d get needlessly complicated, I think; something involving queued records of actions accepted by the server and applied to the game world is probably how it’ll end up being represented, then wrapping up the actions that haven’t been sent to a particular client yet might be efficient. The other thing that’s been in mind is sending the parts of the current game state that differ from the client’s representation, but that involves a lot of duplication in memory to keep track of every client’s current opinion of the game world, and then going through the changed states and guessing how to transition… no, I think sending a series of actions is far better.
And now I’m off to write some code.