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!
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.
Freaking brilliant.
No, really, that’s not sarcastic. Freaking BRILLIANT!
Thanks to the Queue class in processing (which I’m now using instead of multiprocessing… for no particular reason, other than it’s in Portage, and I have an aversion to using anything that isn’t in my package manager), my client is now happily passing user input to a queue which will contain the map and an arbitrary number of menus.
It’s terribly embarassing now that I was attempting to simulate a queue with a list and labelling it as an ‘execution stack’ (an ugly misnomer which helped me delude myself) when I really should have been doing this from the beginning.
Anyway, the locking I was using with the ‘stack’ was a bit counterintuitive for that implementation, but works ideally for this one.
Good stuff!