A Tough Technical Decision

Another nasty issue that I’ve been putting  off for too long concerns the delivery software. Currently I am using the Java version of SWAT, which was built six years ago to meet a complex set of requirements. It’s a huge program, comprising 186 separate java Classes (files). It does everything: editing, running the storyworld, logging activity, debugging — it’s quite a piece of software. And I don’t understand it. I know the storytelling parts intimately; I wrote them all. But the parts that permit the engine to reside on a server and a client-side Java program to communicate with it are completely beyond my comprehension of Java. 

Moreover, Java is no longer a viable language for client-side software. Thus, I have no choice but to replace the client-side stuff with Javascript. Now, it wouldn’t be too difficult to write some display software in Javascript for the client side. But how do I get the server side engine to talk to it? Somehow the client has to be able to send a message that engages the engine, so that the engine can send back the data for the next turn in the game. But I have no idea how that is done. 

Another possibility would be to translate the engine into Javascript. This, in effect, downloads the whole shebang to the client side and they just run it directly in their browser. The problem with that is that the engine is a big hunk of software with a lot of data. Javascript doesn’t seem to be well-suited for large programs with big databases. I could end up with a programming nightmare. 

Moreover, how could I continue to develop the storyworld in SWAT? Wouldn’t there be so much divergence between the SWAT engine and the Javascript engine that development in SWAT would become useless? Tiny discrepancies in library functions and word sizes could make the two systems produce different results. 

Here’s a possibility: keep everything in Java. Modify the Java SWAT code so that it displays everything using Java, so that the whole thing remains a standalone Java application. Don’t deliver the game over the web, deliver it as a Java standalone app. Of course, damn few people would be able to play it, but I could get it done that way. Once I’ve gotten it working, I can then use that as the springboard for the next step, whatever that may be. Perhaps I could get some crowd funding to convert the Java code into a proper browser game, although this violates my rule against putting my future in the hands of others.