I’ve been cutting and slashing my way through the code, wiping out all sorts of Swing-related stuff, replacing it all with my new and inferior approach that draws directly to the screen. I’ve gotten some stuff up and showing, but I’ve had some difficulties dealing with the client-server aspect of this software.
This program was carefully designed to separate the server-side software from the client-side software. On the server side would be the engine and the guts of the calculations. The client side would have the interface. This thing was designed to that people could run the entire IDE from the client side. The purpose of all this was to keep the engine away from prying eyes. That, in turn, was important because this was a commercial effort, and we wanted to demonstrate to investors that our critical software was secure against competitors’ eyes.
Of course, none of these things apply any more; the patent will be expiring soon and I no longer care about having a secure system. In fact, I’d really rather NOT have to worry about clients and servers. It would be best if everything was directly accessible to the user.
This would mean cutting out all that middleman software that handles client-server stuff. And I’m not so sure about going this far. I feel rather like Dr. Frankenstein saying “Who needs the cerebrum? Let’s just cut it out and route information directly from the cerebellum to the muscles!” Yeah, sure. And I haven’t finished the earlier work on the new graphics system. The reason I’m contemplating this now is that I’m having difficulties implementing the new graphics system because it needs access to information that isn’t directly accessible at the client level. So my hand is forced.
It seems that a critical element in the process is an Interface called EnginePlayerIO. This interface is implemented in four different Classes and is instantiated in the Engine. Huh? I didn’t know that you could instantiate an Interface! Here’s the Interface:
/**
* Interface for providing player input to the engine.
* <p>
* The engine calls the methods of this interface to communicate with the player.
* <p>
* Its main purpose is to provide a clean way to feed the engine with recorded player
* input when loading a saved story or collecting log data.
* */
public interface EnginePlayerIO {
/**
* Get the player input. Throws a {@link StopEngineException} if
* there is no more input available.
* Can throw InterruptedException because they may block waiting for buffer space to
* place log data or the user my stop the session.
* */
public int getPlayerSelection(LabeledSentence tLabeledSentence, ArrayList<MenuElement> menuElements,
int wordSocket, int playerId) throws InterruptedException;
public int getPlayerDone(LabeledSentence tLabeledSentence,int playerId) throws InterruptedException;
/** Send output to the player. */
public void onCycleStart();
public void sendTriggerSentence(LabeledSentence tLabeledSentence, int tTime, boolean showBottom,int playerId)
throws InterruptedException;
public void theEnd() throws InterruptedException;
void writeStorybook(String tSentence);
}
What particularly frightens me about this is that it refers to the data logger. This is crucial to one of the most useful features in the system. If I rip out this Interface, will I not lose the ability to log the story data?
Here’s the instantiation in the engine:
private EnginePlayerIO playerIO;
Here are the Classes that are involved in managing the client-server relationship:
import com.storytron.enginecommon.BadStoryworldException;
import com.storytron.enginecommon.BgItemData;
import com.storytron.enginecommon.EngineDiedException;
import com.storytron.enginecommon.IncompatibleVersionException;
import com.storytron.enginecommon.LimitException;
import com.storytron.enginecommon.LocalJanus;
import com.storytron.enginecommon.Pair;
import com.storytron.enginecommon.RehearsalResult;
import com.storytron.enginecommon.SessionLogoutException;
import com.storytron.enginecommon.SharedConstants;
import com.storytron.enginecommon.StorytellerRemote;
import com.storytron.enginecommon.StorytellerReturnData;
import com.storytron.enginecommon.SwatRemote;
import com.storytron.enginecommon.Triplet;
import com.storytron.enginecommon.Utils;
import com.storytron.enginecommon.VerbData;
import com.storytron.swat.util.Compressed;
import com.storytron.test.JanusStressTest;
import com.storytron.uber.Actor;
import com.storytron.uber.Deikto;
import com.storytron.uber.FloatTrait;
import com.storytron.uber.Prop;
import com.storytron.uber.Script;
import com.storytron.uber.Sentence;
import com.storytron.uber.Stage;
import com.storytron.uber.Verb;
import com.storytron.uber.Deikto.LogIssue;
import com.storytron.uber.Deikto.TraitType;
import com.storytron.uber.operator.OperatorDictionary;
So you can see that this thing is a real rat’s nest of code. The system has more than a 100 source code files, and most of the complexity is there to manage the client-server relationship. Do I really dare try to mess with this?
No, I don’t think that this would be a good use of my time. It’s just too crazy. Somehow I have to figure out how to work within the existing system.