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.
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.