Development: new engine: levels, items, player, tutorial, class diagram, more

The work on the next Castle Game Engine version continues :) Looking at the size of the improvements, next version will deserve the new major number 4.0.0 (even though last version was 3.0.0). We have almost finished new engine features planned for the next version, and we have a lot of new documentation.

1. Diagram (as a text file...) of the most important "Castle Game Engine" classes is available.

   I may try to squeeze this into a real image (maybe just the important boxes, and add the text on a normal HTML page). If you have experience with some diagram-drawing tools (like Dia or other open-source tool) I would appreciate contributions here (send them through forum or e-mail to Michalis).

2. "Castle Game Engine" draft tutorial is getting larger and larger (15 chapters now).

3. Short documentation for index.xml files used by "Castle Game Engine" to define levels, creatures and items is also available. Tutorial and classes diagram describe in details how these index.xml files work. People interested in creating MODs for your games will appreciate them, as they allow to add levels, creatures and items by simply adding subdirectories to game data.

New engine units since last news:

1. New CastleLevel unit to find game levels (index.xml files), load them, scanning 3D level file for placeholders defining initial creatures/items, and integrating with player.
2. New CastlePlayer unit to manage a central player object, with an inventory, footsteps sound, swimming and so on. This unit will probably shrink a little in the future, as most of it's functionality should also be available for creatures.
3. New CastleItems unit to define items (things that you can use in a game, like a sword or a life potion or a key). Item is a TItem instance, that refers to a corresponding TItemKind instance, referenced by TItem.Kind. This is similar to how you define creatures (see previous news post about CastleCreatures unit), in that we have a separate class for an item and for item kind. A little complication here is that TItem is not a 3D object (it cannot be directly added to the level), instead you have to use TItem.PutOnLevel to get TItemOnLevel instance.
4. New CastleInputs unit, centralized keymap handling, detecting key conflicts and such.

Other changes, noticeable in view3dscene or next "The Castle" data:

1. In view3dscene "Help -> Selected Object Information", show Blender object/mesh name.
2. Handle beamWidth --> GL_SPOT_EXPONENT translation similar to Xj3D: OpenGL spot exponent is 0.5 / max(beamWidth, epsilon) (unless beamWidth >= cutOffAngle, then spot exponent is always zero). This allows to at least influence drop off rate with beamWidth, and gives precise conversion from VRML 1.0 dropOffRate -> VRML 2/X3D beamWidth. See engine internals doc about OpenGL rendering (sorry, just DocBook source now) for details.
3. CastleScript writeln() can be used in games to make notifications. Also CastleScript shortcut() is now available, to show user the value of some key shortcut. See CastleScript SVN docs for details. This allows "The Castle" levels (and future Castle2) levels to make notifications using more standard X3D mechanisms: they now use ProximitySensor + CastleScript to show hints, instead of our custom <area> invention. See e.g. cages level X3D source to see how it looks like.
4. Our "thunder" effect (blinking light and some sound), used previously in "cages" level of castle1 and lets_take_a_walk, is now remade as pure X3D prototype. This means it's simpler, more configurable, and doesn't use a single line of ObjectPascal code :) See it's implementation here: thunder.x3dv, examples how it's used are at the bottom of base.wrl and cages_final.x3dv.
5. examples/3d_sound_game/lets_take_a_walk uses CastleLevel, as a first demo (besides the castle1 game).
6. New view3dscene menu item "Remove placeholder nodes from "Castle Game Engine" levels", a general way to remove some specially-named nodes (see castle development doc for reference of most of them, see sources for all). Removed previous castle-process-3d-model.lpr, it was uncomfortable and didn't really prove useful.
7. Implement TCastleWindow.RedBits, GreenBits, BlueBits, in addition to making ColorBits cross-platform and sensible (reads/writes RGB properties). glinformation gets --red-bits etc. options.
8. Comfortable TCastleWindow.AntiAliasing property, instead of previous GLAntiAliasing unit. You can now simply use TCastleWindow.AntiAliasing instead of TCastleWindow.MultiSampling for a little higher-level approach for MSAA.

Oh, and since I just don't have any interesting screenshots for this news item (mostly code changes, interesting for developers...), the side of this news post contains just some best movies from the previous news in this year, possible thanks to Jan Adamec (RoomArranger, 3D mouse, SSAO) and Victor Amat (water with caustics). Thanks again!