- Transform as a matrix/rotation as a quaternion.
- For effective saving/loading scenes, binding components to editor panels etc etc
- UI markup? Have a "ImGUILang" parser on the editor side that reads an ImGUILang file for each module that has UI elements, maybe autogenerated by CMake.
- Can be used for custom editor gizmos
- Rethink module structure. Plugins vs modules? Try cr for hot reloading?
- EnTT 3.6 makes breaking changes. Module and a central
type_context
in the engine is important before I bump the version. - EnTT 3.6 (3.7 now) will make diffing and serialization simpler I think. Need more research.
- EnTT 3.6 makes breaking changes. Module and a central
- Engine modules for rendering, resources, physics etc. These would each be separate DLLs. The game itself would be a module (see Godot)
- Split simulation and rendering threads
- Single tick or independent ticks? I would prefer to go for single tick, but then we'll have to synchronize each frame.
- FixedUpdate vs Update for physics and rendering
- Low-level render library to interface with various graphics APIs like Vulkan, OpenGL etc. (or just use Vulkan everywhere?)
- Deferred rendering
- Shadows and reflections
- Importer tool to import an asset into the engine and store it with all required metadata in an optimized format
- Registry diffs. Need to maintain a diff between current scene and scene on disk, and also between simulating scene vs current scene.
- Will be beneficial when I pass modified values across threads.
- Component diffs are also required to pass changes across physics systems
- Undo/Redo system for UI
- Entity add/destroy events or just for components? Implementing components for now, defer entity ones till they're actually required.
- Clear the scene, reload the scene from file
- Reload the changed entities from file
- Undo the changed entities
To get a notification on changed entities: need a SaveComponent() type API otherwise notifications would not be triggered. To reload changed entities, from file is not that good of an option. Keep them compressed in memory?
Have a PatchComponent() API- Use entt::observer and other hooks to register changes to entities or components
- Have EntityDiffUtil and ComponentDiffUtil classes that register these changes, keeping only initial and final values
- Have hooks into these util classes for the Undo/Redo system, which uses these classes to maintain its own undo/redo stacks
Engine play button for testing the game in editor- Build tool to create no-editor builds of the game. Have a couple of stub files that implement the runtime and use CMake scripts to build and link it with the engine and the game DLL
- More unit tests
- Precompiled headers