After a lot of investigation and playing around, I've decided that this is the format of games that future versions of AC will create.
http://www.mediafire.com/download/e57ol ... single.zipThis is a pretty large departure from what AC does now, and it's a large departure from what I had planned on keeping AC doing. Before I go into the changes, let me explain why I'm doing this.
Virtual Date With Keeley was around 200 pages. Redemption for Jessika was over 1300. BEW is over 1800. What made sense at the start of all this doesn't necessarily work anymore. The 1300 pages add up to like a megabyte of space, but they take forever to unzip. Uploading them takes a long time too. Filesystems don't do all that well with thousands of tiny files. Then, to make matters worse, I added localization to RfJ, with each language adding another 1300 pages. At this point, it takes a ridiculous amount of time to unzip it, and that was annoying me.
So I'm switching to storing the pages in two files instead of 2000. I know that I've said that I want to keep things simple for non-coders, and this hurts that. It's considerably harder to figure out what you did wrong in a single file situation than individual HTMs. But, at the same time, there aren't a lot of non-coders using AC anymore. I'm the primary user, Wolf and Kexter do their own thing with it, and I'd walk barefoot through broken glass to help Mortze. So we're pretty well covered. And as always, I'll help anyone here who has difficulty.
So, I set out to make AC read and write the above format. And, damn it, that codebase needs a mercy killing. The best architected code frays over time as you add stuff to it. And AC started as a quick hack that I didn't even architect very well. At this point, making it work at the scale that these games are becoming is just too complicated. I spent a while optimizing it, but it still takes 4-7 seconds to open gameView on RfJ, and opening and closing locView still crashes the app when it runs out of system handles. So I'm going to start over.
And while I'm starting over, I'm thinking boy, wouldn't it be nice to make it tight for one style, not try to cover all the old things? And, I've always been pissed at myself for screwing up the consistency of the functions in _functions.js (readVar and varPlus1? Really? And I didn't even capitalize them right.) So I thought, "Hey, if I'm going to break from tradition, why not make it clean?"
So here we are. Highlights:
1) One htm file (okay, 2, but who's counting?).
2) All non-text for the files in a single pages.js
3) All text for the game in text.en.js
4) Other languages in text.<loc>.js
5) AC will no longer write HTMs, so it doesn't need the HTM template anymore. Game developers are free to lay out the single htm file however they'd like. Or use the default one. Whatever you want to do.
6) _functions.js has been broken into two parts, engine.js and helpers.js. The idea being that the core engine just needs engine.js, but some of the other stuff that I use in my games is available in helpers.js.
7) AC will only be writing pages.js and text.<loc>.js. Most people will use the defaults, but if someone like Kexter wants to rewrite engine.js, it's not really going to get in the way of AC development.
8) Hit targets are percentage based, rather than pixel based. This means that, if you want, you can have the image scale to the browser window and the hit targets will work correctly. I still feel that it's important to have fixed sizes, because everything I've seen that tries to do it automatically does it wrong, but at least you'll have the option to change it now.
9) For people who want to do fixed sizes (like me) I simplified the way its done. You can have as many sizes as you want now, and they're based on numbers not words like "SuperDuperExtraLargeSize"
A few downsides:
1) Like I said, this format makes it much harder to debug issues. I'll be teaching you folks how to use the debugger built into various browsers, where before you could muddle through without it.
2) I've stripped out a number of things, including sound support. Overwhelmingly, people don't really want that in our games. Maybe I'll put it back in the future.
3) Wolf and Kexter, I'm currently not planning to do Page Comment support or subfolder support. Both things are doable, but you're pretty far down the path of using your own stuff. I'm guessing you're going to stick with the current AC and not switch to this. If you decide to move to this, we'll talk about me adding those features back in.
4) I changed readVar to "ReadVar" and "varPlus1" to "AddToVar." It makes me stop cringing when I see the code, but it means you've got to unlearn what you know and switch to the new functions (though I provided a few translation functions to ease the transition). I know that this is actually the part that will cause you pain, but, really it's better this way. (-:
5) I haven't actually started rewriting AC yet. So this is down the road a ways.
A few things I could use from you folks:
1) Since I'm starting over, is there anything about the basic AC game that we should change? I've written more HTML based erotic games than anyone, and I've never needed more than 3 says, for instance, but are you guys thinking, "I wish I had 4"? Etc.
2) While the above format works fine in IE, Chrome, and Firefox, there appears to be a race condition in Edge. If you click the says quickly the buttons stop working. (Easiest way to do it is go to the achievements and click "Next" rapidly.) Hitting F5 fixes the problem, but it kind of sucks. If anyone can think of a workaround for Edge, I'd love to hear it.
3) Is there anything fundamentally off with what I'm doing, such that I should change it now before I rewrite AC? Specifically I'm talking about the format of pages.js and text.en.js, but I'll listen to suggestions if you folks want to make them.
I plan to release a version of AC that can do some of the heavy lifting in translating an existing game into this new format. And I'll keep the last multi-html version of AC on Mediafire indefinitely if people hate the new format and want to stick with the tried and true. But future development will go into the new, not the old.
Tlaero