STEW update

I was preparing a check-in to my private STEW Bazaar repo, and I thought I'd post an update.

Localization work continues. I'm working on a zipgettext to allow me to pull message catalogs out of zipped files. At this point, though, I want to support full localization for individual games, but the requirement really is just that the core library is fully localized. A zipgettext is required to support drop-and-go functionality for games using the library. They'd be self-contained and not installed via a system installer. They could be localized, and shouldn't need to rely upon the user extracting the message catalogs and putting them in some obscure path.

The initial languages supported will be US English and Pig-Latin. All languages should support variants -- including unofficial "silly" variants. Pig-latin is a good test of internationalization, as you can programatically turn English in to Pig-Latin, so it is fast to roll out a pig-latin version of the native development language. Ideally, these "silly" localizations should actually work when specified via an environment variable, this has not been verified, though.

Keymap progress has been started. The idea is to support nearly official keymaps for various roguelikes, in addition to having our own keymap or two. The draft "native" keymap supports a concurrent ROGUE and NUMBER_PAD layout, while containing all the functionality required to allow it to be used as a replacement for any of the other keymaps. (Through the use of more general "use " functions, as well as menus for the less-used commands.) My play-a-like games will also have this flexability.

I've developed an initial concept of keyboard layouts, with the aim to allow game keys to remain in the same key positions, when the physical keys are in different places. This is particularly important in TTY mode when using a keymap with roguelike keybindings.

While introducing a roguelike to a friend, I came upon a realization of a particular need. Now, early on in development there will be a "keytrainer" game designed to assist new players in learning the keys.

We have a concept of stand-alone interactive tools that exist parallel to the game tree. The base logic there is essentially the same as for the game tree. This is in addition to the capacity to have command-line tools specific to a particular game. The idea is that some tools -- such as a map/room/vault editor may exist independant of any particular game.

We're starting to build data models for the various rulesets. The two core rulesets are currently Fudge and D20 (3.5). It appears that all of the table-top RPGs have some implicit terrain knowledge that needs spelled out in something like a rogue-like game. We're setting aside all thought about rulesets to do some exploration in to practical roguelike terrain. For terrain basics, this means terrain that would work for a narrative-based roguelike.

The exploration of practical roguelike terrain should help clear up some of my current questions and concerns. It will also get me thinking about narrative roguelike games, and the narrative roguelike game includes features that broadly span any of the underlying rulesets. At this point, it really seems like the best angle of approach.