I made a semi-cache coherent container which provides an Entity-Component-System. These are the bones of contemporary game-engines.

This post is a bit crude; I keep thinking about it then adding features to Whippet instead of writing this up.

Whippet on GitHub

Google built CORGI which isn’t (yet?) trying to act cache coherent. It also is more than trivial to build, and suffers from NIH for me. Actually; that last bit isn’t likely to be a problem for most, but I didn’t like their license.¹

Goals

• Entity-Component-System
  • Entities and Components share a common pool of GUID values
  • Systems utilise a lazy creation mechanism with LIFO clean-up
  • Components and Systems are accessed through templates
  • use of std::type_index avoids binding anything to names
• “Pure, Hard, C++ Source”
  • the core of the system is built as a collection of C/++ files with no dependencies
  • the test/ contents will need GoogleTest but they’re not expected to be part of usage
  • there’s one way to do it; the way I meant to
  • constructors are used when objects are created
    • a pre-new trick is used to set state on the object before construction
  • destructors are used when objects are destroyed
  • I use a template strong<> to try and enforce strong typing
  • harsh, but, helps with the next goal
• minimal compiled footprint / “hard crashing” for errors that shouldn’t be possible without misuse
  • ex; cyclical dependencies in components (A needs B, B needs A) will cause infinite loops
    • this is (kind of) a vanity goal; I want something that fits onto a 1.47MB floppy
• light speed / wherever possible; I’ll try to avoid work that’s unneeded
  • ex; userdata+callback is used in favor of std::function to avoid the copies
  • ex; queries can “bail out” if they find an acceptable answer early

Status

• modest suite of unit tests should cover all code paths (I ran down all stubs)
• it’s usable (I think) and has no known (shippable or otherwise) bugs
• all state is contained in an isolated whippet::universe
• entities and components have unique 32bit IDs
• components are attached instead of new‘ed
  • constructed with a variadic template
  • some dark sorcery is used to run the baseclass constructor before the derrived class; no globals!
  • key’ed by class which is resolved to a std::type_index
  • install<>() must be called before this can be done
• system objects can be created at any time
  • they don’t do vardric
  • they also use pre-main so they can initialise references to requirements
• just headers and source
  • no funky confgiure buidl steps
  • no generated code
  • no external dependencies (for the main sources the tests use GoogleTest)
• create entities/components within a world
• 11 unit tests written with GoogleTest 1.8.0
  • no non-trivial code was added unless it was “hit” by a unit-test
  • it passes them all

Future

• scripted component(s)
  • using DukTape as an ECMAScript engine
  • it basically “works” now, but, lacks any tools to make bringing the scripts into the project practical
    • probably will use Bublé to simplify it
    • … or maybe Babylon …
  • likely based on CoffeeScript conventions
  • … maybe use https://www.minifier.org/ or something to compress scripts?
• message queueing system
  • allow asynchronous events and communication
  • when I know how; I need a use before I can design re-use
• fused source; combine all (used) source code into a single header
  • will involve rewriting the utility things to be modular
• a “standard” transform-type component
• stripped down Bullet3D
  • maybe based on a current version

Source

While I intend to continue development in a/my private (Mercurial) repository, I’m using some black magic to mirror it to GitHub on occasion.

Whippet on GitHub