1GAM Update 3/15/15

Hey all.

What can I say? Basecode, basecode, basecode… I spent pretty much the first half of the month working on ironing out what I’d taken away from the first two months. Now I’m stuck on what is probably one of the last major core mechanics of my engine, but whatever. I’ll figure it out.

The engine also has a new name: Aurora. I so chose this to be consistent with the “light” theme (a photon is a particle of light, for those who don’t know,) and as an Aurora often is a blend of many different colors, I chose this to represent the intended flexibility of the engine.

So let me explain the basic foundations of the engine. Very consistently with general ECS methodology, there are three main class types that form the backbone of the Aurora engine:

  • Components (which when taken in groups are technically entities)
  • Systems
  • Nodes

Components represent data, systems represent logic, and nodes represent the passing of or associating of data to the system logic.

Now, beyond this basic setup, the door was kind of open for me to do what I wanted. How do I manage nodes? How do entities communicate with each other? How do I dictate the order in which systems run? Docs I’d read on ECS didn’t necessarily cover these things. I wanted to keep the engine simple. Introducing too many new “core” types into the foray could complicate things unnecessarily. I ultimately did add types, but they all revolve around or are based upon the three core types. In short, nothing else should usurp what the core types are meant to do:

  • Components (store entity data)
  • Systems (perform frame-by-frame updates on entity data)
  • Nodes (associate related entity data through components with systems/other entity data)

Once these purposes were established, I then started tackling other areas:

  • Streamlining entity and component generation
  • Entity-to-entity communication/system manipulation
  • System execution ordering
  • “One-shot” immediate executions (is not and should not be deferred in the system pipeline)

For instance, I rigged a special child class of the System called a Connector, extended slightly to handle system logic that worked on multiple entities. This was assimilated into the system architecture so both could co-exist as systems in the execution pipeline. I’m still figuring out some of these, but for now things are progressing all right.

So that’s what I’ve got for right now as a brief overview of the engine. Feel free to ask questions if you’re interested!

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: