Guess if I want to info dump share parts of the engine I’ll keep it here.
Here’s one of the key parts…
Basically the part that keeps track of everything in the game world, the systems are handled elsewhere.
For anyone unfamiliar with this, it’s a method for rapidly searching parts of an entity.
For example, if you want to move objects around, they need a movement component.
Then the movement system only grabs the movement components and performs updates.
This way it doesn’t have to process every single entity, just the ones it needs to.
Definitions > https://github.com/wtfsystems/wtengine/blob/master/include/wtengine/mgr/world.hpp
Implementation > https://github.com/wtfsystems/wtengine/blob/master/src/mgr/world.cpp
-
Thread safe
-
Exceptions thrown by this are just logged and do not stop the engine from running
-
Uses a vector to track entity IDs
-
Entities are referred by ID number or a unique name
-
You can assign the name or let it random generate
-
Unordered multi map to store the components
-
Uses templates for selection
-
Get/sets (const/non-const) for:
-
batch components of a certain type
-
all components for a certain entity
-
one component at a time
-
New components are created by just extending the base interface class
Performed very fast in testing, it’s hard to gauge now in running since it’s all 2d, but can’t wait to see what I hit once I get 3d in.
Pretty much the final version as well, unless much further down the line it’s reviewed for performance optimizations.
Anything under that manager subclass is just a singleton.
Right now you need to hard code everything that will be loaded into the game (spawner is a separate part), but expanding some of the features of the engine to be more dynamic is next on the checklist after I figure out my unnecessary but I just want to do it solution to my input handlers?
I wanted it to be possible to define the game objects using a modeling language, which fits nicely with TMC’s goals. So I’ll be getting my engine’s entity spawner and asset manager to be controllable by the in-engine commands rather than just hard coded in. This alone would open up the ability for the engine to become moddable with little effort. I’ve already looked at a C++ JSON library so will likely add that into the project when the time comes. My only real restriction to the project is I’m targeting Emscripten. I have to stick with more basic libraries, and I believe this one was just standard STL usage.
Here’s the demo game that shows this all in action:
https://github.com/wtfsystems/wte_demo_01/blob/master/src/wte_demo.cpp
Sadly not in a build-able state RIGHT NOW due to the handlers update I’m trying to do. I’m trying not to give up with this, but I had a simple “override the lambdas” approach before.
I got a Windows binary on there that’s the same game, just a much older version of the engine. Pretty much right after I got the ECS up and running.
Part of what I’ve been doing was I wrote the simple game first, then just reversed each part into more dynamic features to work like an engine and not a hard coded game.