I am looking into the organization of the web pages, and have run into a problem created by Doctor Jekyl (HTML) and Mr. Hyde (JavaScript). You see, they both exist on a web page, but neither is aware of the other. They don’t communicate. This causes all sorts of problems.
My starting point is the Encounter Editor, which allows me to create and edit encounters. An encounter consists of a number of different components, and organizing all of these requires the Encounter Editor. The Encounter Editor reads and writes to an XML file containing all the data on the various encounters.
But JavaScript doesn’t read XML; it prefers a different data structure called JSON. Fortunately, there are tools on the web that translate XML to JSON. So I take the output of the Encounter Editor (XML), convert it to JSON, and then have the JavaScript read it—right?
Plan A
My first plan was to store all the encounter data as a large JSON data file and then have one master web page running a lot of JavaScript that would operate the whole encounter engine. It would read data from the JSON file, present the encounter to the player, let the player make his choices, calculate the results of those choices, then proceed to the next encounter. Makes perfect sense, right?
Well, there’s a hitch: JavaScript can’t read JSON files. It can read image files on the website, but it cannot read a JSON file on the website. Well, it probably can, but after spending a day searching the web, I was unable to find anything about how JavaScript can read a separate JSON file. Apparently JSON data has to be included on the same page with the JavaScript. There went Plan A.
Plan B
OK, if JavaScript is going to be pig-headed, then I can be just as pig-headed: I’ll shove the damn JSON data right into the master web page with the JavaScript. It’s already about half a megabyte of text, and it will probably grow to a megabyte, but hey, some of the images on web pages gobble up that much memory, too, so I won’t feel bad about building a monster web page. I built that webpage with all that JSON data and got it all read into the JavaScript. But then I ran into the next problem. The main text of an encounter can be quite long. The player must be able to scroll through a long text. But the way JavaScript organizes the screen output does not appear to be conducive to long scrolling text. That’s handled by HTML—but there’s no way that JavaScript can tell HTML what text to display. Well, again, there probably IS a way, involving all sorts of screwball indirect schemes. “What’s the problem, Chris?” I can hear you say. “All it takes is 10 lines of CSS, a few dozen lines of HTML code, and this special library that you can download from www.obscurejavastuff.com, which you can import into JavaScript with only a few special modifications from the console. Piece o’ cake!” Yeah, right.
Plan C
So now I’m considering Plan C, in which I abandon the notion of a single page that I pour different text into. Instead, I’ll have to build one page for each encounter, and jump from page to page. I can do that. But now there’s a new problem: how do I transfer the state variables of the system from page to page? Sure, I can use cookies, but I’ll need a few kilobytes’ worth of cookies to transfer the state variables.
Plan D
I buy an AK-47 and lots of ammo, then go to the people who designed JavaScript and shoot the place up.