[GSoC 2018] Porting Destination Sol over to ECS

[manas96]

Hi. After vacillating on many different topics, I’ve settled on this one. As mentioned in the list of GSoC topics, I would like to get up to date on the latest about Destination Sol (pinging @Cervator and @vampcat ) . Also, I would like to discuss my understanding of what is expected for this topic. I don’t want to go off on a tangent and write a proposal for something completely different than what you have in mind

So regarding DS’s updates – going through the code, I see that the asset system in the game already using the gestalt asset system. No work has been started to port the game’s Object Oriented entities over to an ECS system. Is this correct? Or is there some fork of the repository underway to port over to ECS?

Current OO system in Destination Sol:
Currently, all entities in DS are an implementation of the SolObjectinterface. All different types of SolObjects have their own properties and implement their own behavior through update() methods.
A list of all SolObjects present in the game is maintained in the ObjectManager class. Each frame, this list is iterated through and each SolObject’s own update() method is called. This system makes it very tedious to create new entities ingame.

With ECS:

With an ECS, the data (speed, position, texture etc.) and logic (update() ) will be decoupled from being inside a single SolObject.
The data will be contained in Components. An Entity will be a collection of components, and each entity will be assigned a unique ID. The logic will be handled by Systems such as renderSystem, collisionSystem etc. Each system will only act on entities which contain a specific set of components. For example, the collisionSystem will only act on entities with a rigidBody component. Systems may also act on events sent by entities.

Is my assessment correct so far?
Also, the GSoC post states:

This will laying the groundwork for gestalt-entity-system, porting over at least some systems to use the new architecture (since porting the entire game over is not realistic in 3 months), and adding support for modules to be able to register their own systems via annotations.

Just to be clear this means that I have to use the generic interfaces provided in the gestalt-entity-system (example), right?

This is a open idea, and with the correct subset of systems and features, it should be feasible.

Which systems and features do you suggest?
I would personally prefer doing the renderSystem, inputSystem, collisionSystem and enemySystem in that order since those will get us a Minimum Viable Product, but you all know better than me

 

[vampcat]

Sorry for the delay.

First off, I would *highly* recommend joining irc/discord, since it's way easier to communicate there (tons of other people there as well).

Now, onto your questions.

> No work has been started to port the game’s Object Oriented entities over to an ECS system.
That is indeed correct. I did have some random test branches, but nothing worth pushing.

> and each entity will be assigned a unique ID
Iirc, gestalt-entity-system v6 removes the concept of "id" from entities. You have an entityRef, and that's it.

> For example, the collisionSystem will only act on entities with a rigidBody component.
That is indeed correct.

> Systems may also act on events sent by entities.
Huh, I'm not sure if an entity can send an event in the first place, since an entity is just a data container. @Cervator might be able to confirm this.

> Just to be clear this means that I have to use the generic interfaces provided in the gestalt-entity-system (example), right?
Not really. The "port some systems over to ECS" does include making entities and adding components to it (components that will extend the basic Component interface you linked to), but it also includes making the systems that act on it. And the "registering systems via annotations" is a slightly more complex example - look at the Terasology @RegisterSystem annotation to better understand what I meant. (It's hard to explain this entire thing on forum, so I'm glossing over it for now.)

> I would personally prefer doing the renderSystem, inputSystem, collisionSystem and enemySystem in that order
Unless I'm missing something, doing a renderSystem will involve converting every single object type (ships, asteroids, mazes, projectiles, particles) to ECS if you want to complete it. I would recommend you start with smaller things first, like just porting asteroids or just porting player ship to ECS, and moving from there.

 

[Cervator]

...
> Systems may also act on events sent by entities.
Huh, I'm not sure if an entity can send an event in the first place, since an entity is just a data container. @Cervator might be able to confirm this.
...

So I guess technically events are sent at entities, so to say. At least typically, if not always, not totally sure if there are any cases where an entity is not involved. Often Systems contain the triggering code, although not always, some of the loading processes for instances also trigger life cycle events and such.

Systems also (always?) contain the actual event handlers where they then act on events originally sent against some entity.

(Also: Yay potential DestSol item!)

 

[Cervator]

Bump - just reviewed the updated proposal and added a bunch of feedback on it.

You seem to have the grasp of ECSes, but then don't seem to apply that knowledge in the timeline, nor post overall goals in the proposal. You actually kinda have more detail in your first post here than in the proposal, as in the list of potential systems to write first. That's what we need! But in the proposal

Forget about convincing us about ECS stuff, that's what we're asking for after all. Pick a series of game logic systems you've looked at and think you can figure out how to write in ECS then list those in the proposal in an order that makes sense with estimates for how long each might take.