Visions

Open ideas and thoughts about Stencil will take place here. If you're willing to provide your own opinions an any subject hereon, feel free to do so.

Clanlib?

I'm not entirely sure whether ClanLib was a good chice. I think that full 3D openGL would be really great, and CL is mainly concentrated on sprites etc. Plus, CL isn't really portable. It runs on windows and linux, and maybe MacOSX port is underway... that's not really much... But what else? Graphics, sounds and GUI might be done with Coin3D library (don't know how suitable it is for game programming purposes), but Clanlib does so much more... collision detection, network access, resource handling, input handling...

Another thing is problematic XML. Hand-rolled XML structure checking is a pain, there has to be some way to automate it. This way uses DTD definition or XML schemas. None of those is supported by CL. Introducing xml-related library would also make it possible to use XML:include, now inclusions have to be encoded into xml application. However, it would be another huge library to depend on, and xml libraries tend to be really huge. Consider: libxml almost 4 megs, xerces-c over 9 megs... maybe that hand rolled code isn't that bad :(.

Internationalization

How to do internationalization? Localisation of a game also means localisation of its datafiles. Since Stencil counts on with community-substituted packages with custom data, like levels and equipment, these packages have to bring their localisation with them.

Other that that, GUI has to be localised. And localisation has to be clever into some extent, and use fallback defaults, if localised string is unavailable (dynamic changes make it difficult to keep localisation files up to date).

The problem is, that localised strings may use chinese or other uncommon language. But once there is no chinese translation, we want to use at least fallback english - but including font! So you are in situation where there are most parts of UI localised, in chinese, with apropriate font, but several texts are left in original english, also with apropriate font.

Introducing problems with cross platform system font selection, and requirements for 'coolness' of user interface fonts (you can't just use Times for menu entries... it's a game, not word processor). This forces us to distribute required fonts as TTFs or bitmaps, and render them in runtime.

So - there is a situation. Core application carries its fallback english, and provides framework for i18n. It's possible, maybe required, to download language pack as an addition to core application. This introduces possibility to use l10n to that language. Apart from that, data packages (levels etc.) have their own core, and their own l10n packages. And user interface has to gracefully pick apropriate language pack, or fall back to safe english. Now you tell me, does all this i18n mumbo jumbo pay off??

Using gettext isn't really possible. Texts in such an application will inevitably change rather wildly (you can't prevent people from fine-tuning weapon descriptions). I think that much better approach is to substitute texts with markup symbols, and localise *always*. You want the game to run in english? Well, then go and download english pack (which could actually be a part of common distribution). Engine then translates all, say, &loc_wingman_1200x_hmg; references to apropritate string from your language pack, and renders it with apropriate font, again from your langugage pack.

PhysicsFS

For access to various user-provided, core and language packages, we'll probably use PhysicsFS. Packages would be then provided as ZIP archives. It's the only option, if we don't want to hand roll another filesystem abstraction library, with that little help that ClanLib can provide.