THE TOPICAL GAME EVERYONE SHOULD PLAY
For reference, here is my 8-part vision. The only difference between the server that is now live and Vision #1 is that the current system is still missing a chatbox. That will not be hard. I'm also hoping to get bright colours up and running soon; have to run some experiments still. Smiley face support is unfortunately absent.
Anyone know a date on when B-Game II starts? I'd like to squeeze a game in before that -- just a few screens long. Here is an early WIP!
(note: the cutscenes and gfx are salvaged from a months-old mock-up)
Good Guys vs Bad Guys is actually the first Klik and Play game I've ever made. It's an RTS.
There's bad guys and you have to beat the bad guys with good guys. You move the good guys by clicking places.
It has four levels and a boss and I think it's pretty sweet.
hax0r is ported, and runs! It even drops the telnet connection when you hit the "NO CARRIER" point. Are you excited? I'm fucking excited.
Bugs I don't understand:
In other news, did you know you can send money to Tim Sweeny's father and have him send you a disk with the registered version of ZZT on it? Or that ZZT is not pronounced, "Zed zed tee" (or "Zee zee tee" for you heretic Americans), but "Zzt", like a sound effect? Now you do!
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.
I'm writing a telnet server for realtime online multiplayer ANSI gaming and game-creation. Realtime collaboration is so much easier when everything happens on the server, and it's so much easier for everything to happen on the server when it only has to worry about spitting out 80x25 character images. I'm almost done with the plumbing (parsing ANSI escape codes from a telnet stream, an internal representation of an ANSI screen, diffing two ANSI screens to minimize the amount of shit sent over the wire), and it should be pretty straightforward to port my Stackless Python game engine to use this new framework. Might this mean a textmode port of Hax0r?
Anyone want to contribute some sweet ANSI?
Ideas for scripting are welcome. I don't really think ZZT-OOP is the way to go (Goto-based programming! Brillant!); a more Klik & Play-style if-this-happens-then-do-this approach is probably better. I can expand on this if anyone is interested.