Post by chriscrawford on Jul 27, 2015 7:09:44 GMT -8
This thread exists to permit a group discussion of the problem we're facing with the front end for Siboot. To put it briefly, we need to replace the old front end without damaging LogLizard.
Some background:
The engine is the software that operates the story. It's big and complicated. It is embodied in file Engine.java.
LogLizard is a powerful, clever, and important feature of the old SWAT design. The author runs a test game, then consults LogLizard, which presents a complete breakdown of every single step taken by the engine. LogLizard enables the author to figure out exactly how the scripts operated. It is an essential tool in designing a storyworld.
The old front end in SWAT was a text-only front end. It is implemented in a number of files in Package Storyteller. The main file here is Storyteller.java.
SWAT was designed to operate as a client-server system, with the front end in the client, and the engine on the server. This design was necessarily very complex.
Here's the central problem: LogLizard is used ONLY with the Engine (and its subordinate file, Interpreter.java), and so all references to LogLizard should take place ONLY inside the Engine and the Interpreter. However, Storyteller.java references LogLizard in a way that I don't understand. If we replace the front end in Storyteller.java, then we damage those references and destroy the operation of LogLizard. Our task is to figure out what those references do and move them all back inside the Engine so that the front end doesn't know about LogLizard.
There are only three places in the Engine that call the front end:
sendTriggerSentence
The engine tells the front end what the NPC just said to the player. It sends complete information on the details of the sentence that the NPC just spoke. This method is called from a single point in the engine.
getPlayerSelection
This is the basic input point; this shows the player his options and waits for him to select one of them.
getPlayerDone
This presents the player with a simple acknowledgement button (as in “OK”) and waits for the player to press the button.
All three of these calls go through class EnginePlayerIO.
These are the lines of code in Storyteller.java that reference LogLizard (which is called "logger" in this code):
2405 janusSessionData.engine.logger.setLogging(logging);
2406 // Don't log scripts. We just want to log a few nodes.
2407 janusSessionData.engine.logger.logOnlyUpperLevels = true;
2549 SessionData.engine.logger.commandCount=0;
2654 for(Compressed<Object[]> cn:sD.engine.logger.popCompressedNodes()) {
2655 loggerNodes.add(cn);
2657 bytesum+=cn.object.length;
2658 }
These are, to the best of my knowledge, the only references to the engine logger in Storyteller.java. The first three appear to initialize the logger. It should be easy to move the initialization to the Engine and make it part of Engine initialization.
The last loop is inside a method (getLogData) that returns the logger data and is called from only one place in the system, a class inside SWAT called LogDownloaderThread. I don't know why the log data should be stored in Storyteller.java. What's really weird is that getLogData() appears to load data from the Engine and then return it. Why the programmers used such a roundabout and unnecessary route escapes me.
Let's hear some ideas about how to proceed.
But
Some background:
The engine is the software that operates the story. It's big and complicated. It is embodied in file Engine.java.
LogLizard is a powerful, clever, and important feature of the old SWAT design. The author runs a test game, then consults LogLizard, which presents a complete breakdown of every single step taken by the engine. LogLizard enables the author to figure out exactly how the scripts operated. It is an essential tool in designing a storyworld.
The old front end in SWAT was a text-only front end. It is implemented in a number of files in Package Storyteller. The main file here is Storyteller.java.
SWAT was designed to operate as a client-server system, with the front end in the client, and the engine on the server. This design was necessarily very complex.
Here's the central problem: LogLizard is used ONLY with the Engine (and its subordinate file, Interpreter.java), and so all references to LogLizard should take place ONLY inside the Engine and the Interpreter. However, Storyteller.java references LogLizard in a way that I don't understand. If we replace the front end in Storyteller.java, then we damage those references and destroy the operation of LogLizard. Our task is to figure out what those references do and move them all back inside the Engine so that the front end doesn't know about LogLizard.
There are only three places in the Engine that call the front end:
sendTriggerSentence
The engine tells the front end what the NPC just said to the player. It sends complete information on the details of the sentence that the NPC just spoke. This method is called from a single point in the engine.
getPlayerSelection
This is the basic input point; this shows the player his options and waits for him to select one of them.
getPlayerDone
This presents the player with a simple acknowledgement button (as in “OK”) and waits for the player to press the button.
All three of these calls go through class EnginePlayerIO.
These are the lines of code in Storyteller.java that reference LogLizard (which is called "logger" in this code):
2405 janusSessionData.engine.logger.setLogging(logging);
2406 // Don't log scripts. We just want to log a few nodes.
2407 janusSessionData.engine.logger.logOnlyUpperLevels = true;
2549 SessionData.engine.logger.commandCount=0;
2654 for(Compressed<Object[]> cn:sD.engine.logger.popCompressedNodes()) {
2655 loggerNodes.add(cn);
2657 bytesum+=cn.object.length;
2658 }
These are, to the best of my knowledge, the only references to the engine logger in Storyteller.java. The first three appear to initialize the logger. It should be easy to move the initialization to the Engine and make it part of Engine initialization.
The last loop is inside a method (getLogData) that returns the logger data and is called from only one place in the system, a class inside SWAT called LogDownloaderThread. I don't know why the log data should be stored in Storyteller.java. What's really weird is that getLogData() appears to load data from the Engine and then return it. Why the programmers used such a roundabout and unnecessary route escapes me.
Let's hear some ideas about how to proceed.
But