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

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

[Whippet on GitHub][ghWhippet]

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

So I wrote my own tool and attached an even less interesting license to it for the time being.

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é][bubleCode] to simplify it
    • … or maybe Babylon …
  • likely based on [CoffeeScript][coffeeCode] 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][ghGOut] to mirror it to GitHub on occasion.

[Whippet on GitHub][ghWhippet]

---

1.  ↩︎