Engine

Whereas Glest plays on a 2D tile-based map - no tile can be occupied by two objects at once (but an object can occupy more than one tile, so movement is not restricted to crab-like movements) - GlestNG is based a 3D mesh terrain which is both graphical and a navigation mesh.

Therefore, maps in GlestNG are not restricted to flat rectangular things with tile-based obstacles such as cliffs and ramps.

The default GlestNG 'world' is a fractal-generated planet - a micro-planet. Of course Glest tile-base maps can be imported - they'll be converted to meshes on import - but the movement restriction does not apply - units can pack as tightly as their bounds allow. Other detailed 'flat' maps such as reconstructions of historic battles and fantasy maps with real terrain can be envisaged. A nice alternative is to play inside a dyson sphere or in a netherworld of tunnels and caverns (faces facing away from the camera might be drawn very transparently?) Path finding is A* (or triangulation A* perhaps) and is based on a navigation mesh with unit coefficients for height (distance from centre of globe on planet maps) so that a unit might be able to rappel up a cliff whereas others have to go around.

The engine is at its heart the following components:

1. a world (world.hpp) which is a spatial index - an octree - of 'object_t's. It provides standard spatial querying - identifying objects that intersect rays, cylinders, frustums, those that are within a radius of a point and so on. It can also track a viewing frustum, keeping track automatically of which objects are visible as they move.

2. units move in groups (perhaps groups of one). When you move a group, formations - user choice of ranks and files basically - are used, and the path-finding is based on the total size of the formation and such. Units so grouped will move as one.

3. a 'variety engine' so that alternative representations of things, typically humanoids can be provided, so that models are provided and subtle colour choices for meshes with semi-transparent textures so that, say, the trousers of a pikeman differ within defined palette. Units marching together should be in-step generally, but two groups (of 1) that are sent around the same time are not necessarily in-step.

4. helper AI - logic you can issue commands to, that can apply to groups and such. This allows logic for the moving of complex formations - rifleman forming a box, or the building of complex structure - to be executed by scripts on behalf of the player.

5. buildings are not restricted to the grid, but buildings that are placed adjacent to other buildings will be auto-aligned with them on a grid.

6. walks and such to join buildings together at prescribed points. A walling system consisting of various sections in various orientations and towers and such will be supported.

7. procedurally-generated trees and other background. See eisenscript.

8. XML-based units and resources and such, based on the existing Glest structure. Things that are loaded from XML can be parsed and reloaded in-game, and an in-game XML editor and editors for other attributes are provided, so you can tweak things in-game to adjust balance and try things out and such.

9. MD5 and other bone-based formats are supported, enabling turrets, flags and and kinetics solutions.

10. An attack logic that is based on the intersection of cylinders (representing the flight of a projectile from one frame to another) and mesh-to-mesh (for impact weapons) rather than simple subtracting health-points. Units are still modelled by the 'health-points' and other familiar Glestisms, but fighting is modelled such that the engine will eventually support duelling units and mass battles where chance plays a part. Individual meshes in units might be assigned individual armour types and strength such that a chance hit in the eye of a king is lethal even if the king has some really good armour on. Models/units imported from Glest will not have this additional information, so impact is based on the models bounding boxes and this will have a close-enough approximation to the classic Glest attack logic to maintain game-play balance (hopefully). But it is hoped that new models - bone- or armature- based, with appropriate per-section attributes - will be used.

11. Scenarios and AI written in a scripting language, editable in-game. This is likely Lua, although I'm concerned about the exception-propagation issues that might exist. Angelcode likely has the same issues; Python too perhaps. Python is a nice language.

12. The engine is not multi-threaded but is multi-process even for single-player games. The UI thread/process shows the game world live and interprets and issues commands to the players units. These commands are serialised and sent to the game server - another process on the same box perhaps - where it is validated and executed. AI all runs in their own processes without a UI. Processes that could benefit from multi-threading will use a work-stealing thread-pooling tasklet architecture perhaps. This may seem an expensive choice - its possible to have shared read-only memory for the navigation and model meshes perhaps for components running on the same machine, using platform-specific code - but it will ensure that the multi-player sync logic is available from the beginning, and its an observation that scaling sideways - utilising additional cores in this way, rather than putting everything into the same thread and hoping the CPU will run faster in future - is the way of the future. Only the UI processes - one per computer, surely - need any graphics resources.

13. The file system is mounted through a custom virtual file system layer. This is like physFS but is configured quite differently. Mods are stored in ZIP files. The naming convention of these is strictly observed so the engine can determine which mods patch which techtrees by looking at the names. The order that the zip files is mounted is significant - in a unionfs-type way. The ZIP CRC of files is noted and when playing against another opponent the CRCs are compared and any that you don't have get downloaded and cached locally. Your local edits are also stored locally, and there is a tool for packaging up local edits and producing a new version of the mod in a proper ZIP file. The file system is 'versioning' at all times keeping a chronological and CRC-based log so as to determine the exact version of any mod to mount. GIT and other distributed version control systems might be integrated so that people can tweak other people's mods and put in a push request. A simple wizard in the game will make this straightforward but daunting command-line task easy. The game engine includes a downloader, including a patching downloader for moving between versions. Whether mods can be hosted on github or Google Sites or such will need investigation when the code is mature enough to try.