What was I thinking? I mean, if there’s on thing the world does not need it’s yet another IF authoring language. Yet still I’m working on one. Why?
- Because it’s fun. (And that should be justification enough.)
- Because of the special challenges of my chosen platform.
I’m writing an IF system that runs on a web server so that the games can be played in any browser. The special challenges have to do with how a php server script works.
You type your command: “put the marble in the wooden box” and hit enter. Unlike a program running on your own computer, there is no interpreter waiting patiently for you to hit enter. Instead, the web server gets your request in the form of a URL and some posted data, maybe something like: somephoneyurl.com/thisgame.php&cmd=put%20the%20marble%20in%20the%20wooden%20box
At that point, the game is not running. Nothing that you’ve done before is saved anywhere on the web server. The game has to be loaded from scratch and your current game state set up. Then your command line is parsed and interpreted; the script does something like change the location of the marble to be in the blue box; builds a new html page showing what it just did; sends that html page back to your browser; and then the script goes away. It stops executing. It’s dumped out of the server box. It’s gone.
Later, (an hour later, or maybe two days later), you type in “go north” and hit enter. The whole process gets repeated. The whole game engine has to be loaded; the whole state of the game re-established, etc. etc. You get the new room description and the server script is dumped out again. Meanwhile the server is busy with other clients on other browsers who are ordering widgets from their favorite widget vender.
But how does it know the state of the world each time it gets summoned? Especially since there’s no reason why 15 different people can’t be playing their own copy of the same game on the same server. Probably from a cookie the script sends to your browser. That way you never have to save or load a game. Turn off your system. Take a vacation to Germany. Come back two months later and turn on your system. Click the bookmark to your game URL and you find yourself exactly where you left off last time you were playing the game. You’re in the same room, with the same inventory, and the same score and same tasks already marked as accomplished. And you still only have two moves left to decide which wire to clip before the bomb goes off.
I took a look at the source code for several good sized games, including some of my own old TADS source files and figured that the average state of the game, including locations of all moveable objects, states of all binary flags (door is open/closed; room has (or has not) been found;) and numeric values (scores, damage counts, fuse and timer countdown values) and found that the complete state description of the average game can be packed into less than 100 bytes. That 100 byte cookie is enough to save/load the game and put you right back where you left off. Even if a really complex game takes twice that much, that’s not bad.
(There could also be provision for a MySQL database to hold player’s game states, but that would require each player have a unique ID which would require registering on the site just like registering on this forum to reserve your ID and protect it with your own password.)
Because of that way of doing things, the organization of the engine needs to be very different for the sake of efficiency. For example, each room of the adventure is probably in a separate file, so when you say “Put the marble in the wooden box” the engine doesn’t load the whole game. In fact, it might only load the object files for the marble and the wooden box, and not even load a room file at all.
Your player character would suspended in the void of empty space, putting a marble into a wooden box. But that doesn’t matter, because to accomplish that one task the engine doesn’t need to know anything about the room, and it doesn’t have to say anything about the room in its reply to you. All it really needs to do is verify that putting the marble in the box is a permissible action, and then update a few bits in your cookie and send it back to you to reflect that the marble has a new parent object.
Another example, with the player command: “Go north”. There’s no need to load up the room data for the room you’re in. Just load up the doors data for that room. Maybe a hundred bytes is all. Check the north door in that file, and if movement is not possible, report back that fact and, as usual, just stop executing. But if movement is possible, load up the room description for the destination room so the engine can describe the new room. Then as usual, stop executing and wait for the new input.
There are loads of other considerations and problems to work out. I’ve got a long list. And I’ve got some preliminary php scripts that sort of work, but it’s likely to be a long project. But it’s been fun so far.
One issue I’m wrestling with right now is whether to create a new game file format from scratch or to try to get the engine to run existing games in some existing format like Z-machine. The obvious problem is that Z-machine code is not organized for piecemeal loading as required by the hypothetical php engine I’m designing. But maybe Z-machine code could be “compiled” into segmented files…? Well, that’s just dreaming. For now I’m using XML files, similar in basic concept to Quest files, but organized differently for piecemeal loading and execution.
Any thoughts and suggestions, or even scathing criticism, would be more than welcome.
–gary
!
in this forum and read the image info. Those smilies run 620 to 750 bytes, depending on whether they are animated or not. My worst case state cookie mentioned above (1270 bytes) is as much internet traffic as two smilies! 
In reality, does the presence of an extra two smilies worth of traffic really matter to the response speed? 