A better approach is convergence with the other type of game I've been
toying with lately
(Between, Flow of Control) which mix immediate response with periodic
updates. In their
extreme form these blend into fully interactive online games, which aren't
appealing for
players who ever go offline. The useful compromise is a turn-based game with
sensible
deadlines (eg 3 per week) which has interactive control of the results and
orders form.
So, abandon the old technology of mailing turns in and waiting 5 minutes for any response at all, in favour of talking directly to part of the game engine. It does the turnulator trick as a minimum, and goes far beyond in allowing the form to change immediately to fit the orders you're trying to put in. This should address most or all of the UI grizzles so far.
In architectural terms, the game becomes four scripts:
display - shows results and a form based on preferences, writes no data so it can be accessed by many browsers at once, reads player preferences including orders. makeitso - target for the display's form action, only reads the game engine data but writes the player preferences, including orders. Redirects browser back to display script. turn - runs one turn as a cron job, reads and clears orders, reads and writes engine data. init - creates new game, writes all data
There's a slight contention problem when a turn runs and orders are cleared, but generally everything runs as quickly and smoothly as possible.
===========
I think there's a good idea here, but (as you'll be expecting if you've read this far), it's not the idea you think it is.
You're talking about making the active UI enormously flexible in a way that suits a small number of players, perhaps as small as zero if it turns out you don't like it after it's done. The more a UI, or anything else, is tweaked to suit specific requirements, the less likely it is to suit even all the people who want tweaks from the simple original version. So it's insoluble ... in the pre-Between world.
Recapping for people who missed it, Between's results page is a framework
page that includes the output of various net services. This only went as
far as passing game data out to services (such as a mapper Corby wrote) and
getting the results of those services back for inclusion in the big results
page.
In TBG terms this means getting things like your alliance database integrated into results, and configurable access to anything webby, from archived SSTs to results of other games. But it can go further.
Digressing for a moment, combat simulators will be much easier to write for a modern TBG than for TBG-1, since the "real" combat resolving code will be a net service rather than built into the adjudication program. Players can then construct tournaments, analysis, whatever that talks to this service for the actual battle part. Apart from being much easier than everyone re-implementing the combat code, this makes simulators very accurate in undocumented or buggy areas, and instantly updated on changes.
Back to the main thread: it's likely that one external service players will want included in their results is their favourite combat simulator, sent details on their impending battle automatically and displaying the results as they fiddle with their orders.
But it's possible for the game to support more detail of combat orders than its own UI provides, and a third party service can display more and different menus or other form elements to allow finer control than normal players want.
So we get into the "user" user interface, an external service which outputs html form fields for submission to the real game engine. As long as it conforms to the conventions, it'll even be turnulated correctly by the tbg script.
The world is one's lobster.
==============
5) On the usability side, active UI means it's not practical to archive results, either on the server or for the users, as the information displayed varies with the interactive commands given. Storing results in an open-ended game is also unappealing because they grow very large over time.
The solution is to store only the game's own datafile each turn (which still grows without limit, but more slowly than 200 sets of results). The tbg script becomes capable of using the datafile from any turn rather than just the current one, so can be used to examine old results, effectively decompressing them as needed. Whatever player-written data fetchers appear, whether html scrapers or genuine nesh database sharers, they can access old turns as easily as the current one.
In the long run the scripts themselves are likely to become incompatible with old data formats, so the current script/service invokes archived old scripts/services as needed.
There's also a very elegant scheme for keeping the database cached in the display script while use is heavy, yet update it as needed when the turn runs, but it's too geeky for general interest.
