lukemetz / sapling

An entity system based game engine

Sapling

Sapling is a highly experimental entity-system based game engine written in c++11. It was inspired by the series of blog post by T=Machine.

##Dependencies

Premake4 is used to build the project.

Horde3D is used for graphics. Many of the default assets and graphics pipelines are also from Horde3D. The c++ math helper file, utMath.h, also comes from Horde3D with slight modifications.

GLFW is used for input as well as creating a OpenGL window.

Jansson is used for json parsing.

Python is used to generated json wrappers for components.

##Building Sapling should mostly be cross platform, but it has only been tested on Linux.

To build simply run premake4 gmake. Then make in the main directory.

##License

All source is provided with absolutely no warranty and is under a EPL for now.

sapling's Issues

Make EntitySystem a singleton

Think about helpers for getting instance of camera.

Make utils class

Containing h3dnode->entity map as well as other almost required things.

h3dutLoadResourcesFromDisk segmentation faults in tests.

This could be caused by invalid directory or engine not initialized or something else.

standardize screen cordinates

Horde3d wants bottom left. GLFW gets mouse from top left.

add helpers to input component

These would be like key just pressed or mouse pressed, mouse held, mouse released.

Boilerplate for systems

Is there any sane thing to be done here? How do libraries implement for each?
Maybe something with anonymous functions?

entitySystem->runComponents([](float dt, Entity *entity) {

});

Maybe register components b4 hand and have run(float dt, Entity *entity) run once per entity?

Think about getting entities syntax

Its kinda verbose and long.

Think about how mesh is added

Currently there are two nodes. A possible solution would be recursively search up until hit root node in searches and return top most parent.

Ignore order of systems running.

components should keep track of changing state. One should be able to run them in any order.

Compile to shared library

Will need to also compile example applications.

Add simpler logging

Maybe add description to components. Components are really the only thing that should need to be logged.

Clean up garbage/null pointers.

Getting many Segmentation fault's.
Everywhere that just assumes a component exists should get a check.

Refactor all of the nullptr guards.

They nest way to much and are unreadable.

Convert Systems to namespace

Fix segfault when nothing is selected

Wrap h3dShowOverlays to something easy to use.

Make Entity the same as a int.

Much better for networking. No Entity object would be the best.

Convert components and systems to namespaced names

Allow data to be expressed in external, non compiled file.

Would need to contain something like

Entity {
TransformComponent {
x = 12
y = 3
sx = 1
}
CameraComponent {
}
}

Check for multiple instances of component.

Sometimes produces hard to debug result if there are duplicate.

change to c++11

This would reduce amount of code.
Features most used would be 'foreach' and auto.

Have warning when getAs will return null.

This should be a log or something. preferably with line number... macro needed here then I suppose. Should have flag to turn this off.