In my last update, I was rather discouraged about VVO, even suggesting I was putting it on hiatus to work on other things for a while. Although I did indeed work on a writeup for my sci-fi setting (currently debating how much of that I'll post to my capsule), out of a sense of -- I'm not sure, stubbornness? masochism? -- I also continued plugging away at trying to fix the issues with the VVO client.
There was a lot of wrestling with getting asyncio to play nice with tkinter. They seem to use different approaches for event handling, so getting them to cooperate is not the easiest thing. I did eventually come up with a configuration of calls that appears to work. I don't entirely understand why -- I more or less just threw together combinations of solutions I found from researching online, throwing stuff at the wall until something stuck as it were -- and it's not terribly satisfying as a dev getting something to work but not understanding why. Nonetheless, I'm now at the point where the entire framework of client/server communication and the fundamental operations on both the client and server side are functional, and working well enough to serve as an effective proof of concept.
There were many other small problems to fix on this journey. I couldn't get event-driven GUI updates to work together with polling updates, and event-driven updates alone weren't sufficient to update the client window every time it needed updated. Maybe it's possible, but I couldn't figure out a way. I eventually ended up throwing away event-driven updates entirely and just letting the window update in a loop. My first try was updating too fast and ended up spiking the CPU, which is absurd for how simple the client is, so I had to tune the "refresh rate" to a point where the window feels reasonably responsive but it's not consuming a lot of CPU time. I ultimately settled on 10 Hz -- if you're a quick typist you can notice that there's a tiny split-second lag in the text inputs sometimes, but it's perfectly acceptable and it uses hardly any CPU. So I went with that as an acceptable solution.
Another problem is that the connections were closing rather quickly. I *think* this is just because I'd unthinkingly set an excessively aggressive timeout on the server, so I've tried increasing the timeout. I tried experimenting with keepalives but those haven't worked at all. I haven't yet confirmed whether the longer timeout on the server has solved the problem, but I have the client and server running right now, and if I think of it I'll go check on whether the connection is still alive.
Regardless, and setting aside the uncertainty of whether the disconnect problem is solved, enough of VVO is working that there's no technical question of whether I can get the rest of the functionality working, now it's only a matter of building out the "brains" and the content. Users can log in, get a character select screen, choose the character they want to log in with, move around in the game world, with a minimap (though I still need to add the concept of exploration and not show areas that have yet to be explored), and see and chat with each other. I apparently forgot to get a screen grab of the login screen, not that it's particularly exciting anyway, but I do have screenshots of the character select and the main game screen. (I have confirmed that the character select screen populates correctly if the player has multiple characters, though that's not shown here.) The main screen has been edited to call out my intent for areas of the GUI that aren't implemented yet, and the GUI is a work in progress in any case.
Screenshot of VVO MUD character select screen
Screenshot of VVO MUD main screen
It's striking to me how much it increases the complexity by making a game a networked multiplayer, rather than a singleplayer game. My rough, "intuitive and not scientific" sense is that it more than doubles the complexity vs. making a singleplayer equivalent. Heck, maybe it even SQUARES the amount of work required. I say that only half-jokingly. I think about how simple this would be to implement as a singleplayer game, in which case it would essentially just be a text adventure game with a few static graphics thrown in to enhance the experience. There'd be no server, no communication between client and server, no other players to keep track of... I could have easily reached the point I'm at now with a single evening's work, vs. the week of wrestling with multithreading and networking issues I've had to deal with. I don't really have a deeper point here beyond observing how networking and communicating and coordinating between multiple entities makes even simple things drastically more complicated.
I just checked on the instance I have running now and the connection remained open for the duration of the timeout but NOT longer than that even with messages being sent between the client and server, so it appears as though it's treating the timeout as some kind of absolute limit starting from when the connection is first initiated, which totally contradicts my understanding of how timeouts are supposed to work, but that appears to be what's happening. Maybe I'll try accepting the connection with no timeout at all and implement my own manual method for detecting excessively long client idle periods. Regardless, although the behavior is odd, I'm sure this is a solvable problem.
So, VVO as a project is still alive, and from the look of things it might now be at a stable enough state where the difficult problems have been solved and now it's just a matter of adding features until I've got a real game and not just a glorified chat program. Certainly more satisfying than throwing up my hands and giving up in frustration.
I also want to continue working on the writeup for my sci-fi setting, though as I said, it's up in the air how much of that I'll put on my capsule.
Dr.J, signing off for now.
