No input on the wiki mystery, I just want to gush about how excited I am at finally getting a look at the game. I've been wanting to see the source since your "deck of cards" component system posts in 2004. The architecture is looking very neat.
Have you actually downloaded it and walked the guy around the screen (which, sigh, is all it visibly does now)?
I'm pleased with the "card deck" or "attribute" architecture, although there's not much content that uses it now. The (very straightforward and well-documented) code for that is in the file "htable.c" and the interface in "htable.h" if you're looking for it, and suitable for reuse by MANY projects, both game and non-game, with minimal or no modification.
One of the things that does use it is the "triggerable responses to events" code, which uses "cards" to keep track of trigger attributes. These attributes result in some scriptable event being called (before or after the event) whenever something has a particular role in a particular event type. The game has "ai" and "reschedule-ai" events, and the triggerable response to the "ai" event for the player is where the game paints the screen and gets the player's input.
I'm pleased with the schedule-and-events (and triggerable responses) architecture, but at the moment less pleased with its implementation. It has all the virtues I designed it for (never needs to "feed time" to an actor whose turn it isn't, never needs to iterate through all pending events or all surviving actors looking for a specific one, etc), but I don't think that, in its current form, more than a fraction of it could be reasonably reused by another project. It's nice and general, but I'm very self-conscious that the way I did it (tables of function pointers, autogenerated code, indirect calls that result in other indirect calls, etc) will cause a fair number of "structured code" purists who aren't familiar with Data-Directed techniques (or, indeed, anything except Object-Oriented and simple procedural, which is all they teach these days) to scream that I have sinned mightily against their pious ideals and declare that the code is "an unreadable, unstructured, insane mess." In truth, it's just DD rather than OO. But for folks who don't know anything except OO, it probably looks unstructured and awful.
One particular real problem with the way I implemented the schedule code is that there is crucial meta-code (that is, code which does code generation) in the makefile in the form of sed scripts - which means builds on machines that don't have sed installed may be problematic, that it won't transfer well to IDE's that don't want to play nice with makefiles, and that yet more people will suppose that I must be insane. Legions of programmers out there regard meta-code, of any kind, as prima facie evidence of insanity. But, I'm an old LISP kid and comfortable with meta, and I didn't spend the effort to come up with a better way to do this within the limits of C. Heh, now that I think of it, legions of coders out there, including just about all the other LISP kids who haven't written compilers, probably regard the use of C as strong evidence of insanity, too. But I think it's kinda fun in a retro way. Anyway, while I really like what it does and how it works, it oughta be encapsulated better before I try to advertise it as a reusable library for other projects.
I tried to document it well, but mostly I've poured a lot of effort into testing and debugging it, and for now I'm counting on it to be bug-free code that people who don't understand it will *NEVER* want to mess with.
A bunch of things that appear to be "small conveniences," such as the screen-resize event getting handled intelligently, and the scrolling help-line, were kinda subtle to code and had lots of corner cases, but I came up with general, content-neutral solutions for them, and I'm happy with getting those working nicely too.
Anyway, as the perennial perfectionist who has now abandoned several games-in-progress as having flaws that other people proceeded with but which I found unforgivable, I'm pretty confident that this is the final architecture of the engine. This is the first engine that I'm truly happy with in terms of how it works. I may restructure or rewrite components in the future, but this engine has a peculiar set of virtues and optimizations and generality that I am actually satisfied with, so the way the whole thing works won't change anymore.
So now, finally, I'm starting on actual game content, and fleshing out the rest of the engine functionality as I need it.
Bear
