Integrating my stackless python game engine is progressing smoothly, though it's turned out to be a little bit more work than I had initially bargained for.
Big change #1 is that the game loop no longer runs as fast as possible; rather it only runs in response to external events (keypresses + timers). Obviously, since I'm going to be running this thing on a server that I share with a couple hundred other people, using 100% CPU all of the time is not the best way to go. It's actually kind of bugged me for a long while that the engine did that, so it's nice to have a fix.
Big change #2 is that a bunch of global variables containing the current high-level "game state" (ie, which board we're on, which board we're heading to next, etc) got split into a new kind of object called a Client. This was kind of bad design in the first place, but I really needed this new entity once I introduced multiplayer.
The good news is that these two big changes are done, and a proof-of-concept port of hax0r over telnet to work the bugs out should be coming soon!
I'm kind of leaning towards only supporting SyncTERM over flashterm. Advantages to SyncTERM: ANSI music support, the smiley face character works. Disadvantages: Seperate app that you'll have to download, rather than clicking a button on a webpage. The ANSI music "language" looks sort of like ZZT's music language, so you can imagine that I'm pretty hyped about supporting THAT.
Comments
(No subject)
that second one warms the
that second one warms the cockles of my heart.
Gorgeous! I'm afraid the
Gorgeous!
I'm afraid the bullet dot you're using for eyes in the second one are unlikely to work, as characters 7-13 are reserved by the telnet spec. (Seen here as characters 07-0D.) I was trying to recreate the picture in an ANSI editor and couldn't find the dots at all in any editor I tried -- I imagine that they weren't generally usable by BBSes either. I'll do a little empirical testing for you in SyncTerm to make sure.
try dashes then --
try dashes then --