Engine Roadmap

[Immortius]

I wanted to pull together a list of some of the major arcs I have in mind for the engine in the future, to get some feed back on the desire for the different features. I would like to know if what people feel is a priority or if there are any concerns with the direction.

In no particular order

• Module system improvements. This is both around firming up some details of the current module system.
  • Fix components to optionally use uris. At the moment there is an implied rule that component class names are unique, so if MyModule added a HungerComponent and YourModule added a HungerComponent, the two would conflict. The solution is to use uri to refer to components ("MyModule:Hunger" and "YourModule:Hunder"). Additionally, if there is no conflict in the dependency tree of a module, the short name could still be used, as the component resolution mechanism could be clever enough to work out which one you meant.
  • Module versioning - adding versions into module.txt, and version ranges to the dependencies. The implication is modules would only work with the correct versions of their dependencies, and wrong versions or version conflicts could be detected.
  • Prefab extension system - this would allow a module to inject additional components into prefabs from dependencies. This avoids situations where you add item durability system but don't have any way to apply it to existing items.
  • Module sandboxing - securing modules so they cannot use potentially dangerous features (like file system access or network access) without approval from the user. Essentially a custom class loader that restricts the classes they can use to a white list, in addition to installing a java security manager. This will allow automatic downloads of modules when connecting to a server (the risk is too great otherwise)
• Modding. This is building the actual gametype and mod support (modules are the lower level components supporting this)
  • Game types, Mods and World Generator extension mods. There are bits in this direction at the moment, but not fully fleshed out. World Generator in particular has some issues with its configuration not being stored in the saved game.
  • Support for Mod-specific config to be stored in the config file.
• Assets work - Further work improving the asset system
  • Removing the AssetType enumeration and replacing with something more flexible.
  • Adding support for new asset types in modules, including automatically hooking them up.
  • Asset reloading through a console command (so you can edit and reload in place)
  • Setting up Icons as a proper asset.
  • Get asset disposal working better.
• Block improvements
  • Change blocks to a special case of prefab. Blocks would be able to be given components, and most block settings would be moved into those components. These components would be reflected in block entities.
  • Limited support for blocks determining their appearance during chunk generation (must be determined solely though the block's definition and adjacent blocks definitions).
  • Support for blocks using multiple textures in the same mesh part.
• World generation improvements
  • Allow the specification of entities to be created during chunk creation. These would only be created when the chunk is complete.
• Entity System improvements
  • Delay entity destruction to set points, but mark them as pending deletion. This will avoid some issues around event flow
  • Investigate defensive copying and other strategies to improve safety of usage and possible allow future multithreaded use.
• Vertical chunk support
• Multiple world support (think multiple active planets, or alternate dimensions)
• UI improvement
• Time event subscription
• Physics System - cleanup and complete the API
• Specialised shader language
• Optimisations
  • Replace reflection-based class metadata system with code generation based system
  • Further network optimisations
  • Replace JBullet with Bullet
• Documentation

 

[Cervator]

Good stuff!

IMHO-style feedback: I'd put module improvements first, as we need to review and tweak all the modules here around the tail-end of TGC anyway, getting them working with the multiplayer branch. Sorting out exactly how to version them would be great, as we could start building them and tossing built jars into Artifactory or on to GitHub (just about to hit that myself), then build out what's needed to pull them into the game intelligently. Engaging x3ro for good GUI availability for modules as well would be perfect, but I realize that might take a while and have other dependencies

World gen, vertical chunk layering, per-block data - I'd love to get those finished soon, but know they're complex topics. @mbrotz has the per-block stuff in a PR pending some updates, but I haven't heard from him in a while. Nym Traveel was looking at the phased world gen approach in the past (which I figure would impact how we hook world generators into the engine), Brokenshakles has been looking at it recently, but haven't heard much from either lately.

Timed events (subscription systems that can request an arbitrary interval to execute by - or a different system that subscribes directly to time-triggered events?) would be a great win for what hopefully is a small bit of work.

Game mode & assets would also be great secondary targets, building on module improvements

Documentation .... oh the poor red-headed step-child of projects everywhere. We need to sharpen it up before we can honestly say we're close to alpha, but until then I guess it remains a "make best effort when able" item ...

 

[Cervator]

Request from Marcin Sciesinski:

a method to replace multiple blocks in one go, and then recalculate light, or alternatively (even better), delay the recalculation of light for the affected regions till the end of the tick. That way block sets from multiple sources, if they are in the same region will cause only to recalculate the light once.

The specific use-case is the organic tree growth where multiple blocks may be changed per tick, each causing light recalc. I wonder if the Cellular Automata DizzyDragon has been working on would also be able to take advantage

Edit: Older relevant thread by DizzyDragon

 

[Skaldarnar]

Would be a nice thing to have for placing (generated) structures in the world as well

(And yes, I am still alive )

 

[Cervator]

Wanted to put a quick note in here real quick - the batched lighting by Immortius is done! Many thanks

For some of the details see this commit

Marcin Sciesinski (trees) + Skaldarnar (buildings) + DizzyDragon (water/CA) - go!

 

[Immortius]

Yes, batched lighting has been implemented, with some side effects:

• Block changes now have to happen on the main game thread
• Various restrictions on the generation and usage of chunks relating to lighting have been relaxed.
• Lighting information is no longer saved with a chunk, and lighting is now regenerated when the chunk is loaded.
• When a chunk is ready to be added to the world, propagation occurs between it and all loaded chunks it borders on.
• As a result of the above, two phases of chunk generation have been dropped.

To aid with the increasing game thread/off thread dichotomy, I've added a GameThread class that allows Runnables to be submitted to run on the game thread. Usage is:

GameThread.asynch(new Runnable() {...});

To run code at some point in the future on the game thread, and

GameThread.synch(new Runnable() {...});

To run code on the game thread, waiting until it has been completed before continuing.

Submitted Runnables are processed once a frame.