I'm adding roads to my engine. I have a form of entity component system in my engine, the only probable difference between mine and most others is that I prefer entity logic to reside in the entity itself, rather than entities being data only and 'system's working on them. I may switch it over at some point, but for the minute this works fine for me and feels more logical.

My question is around widgets and screen helpers and how they/whether they should fit into the entity component system. To create a road, I'm adding a number of control points slightly above the terrain and using a Catmull Rom spline to connect them (I have already developed this functionality). When a new control point is added, road geometry will be created 'underneath' the spline which will fit just over the terrain (z-fighting is something I'll look at later). The user can then choose to bring the terrain up to match the spline (you can move spline control points up and down as well as in the x/z directions), or just leave it as it is (just using x and z and using the terrain's height).

I'm partway through it but I've hit a design issue. At the moment, when a new control point is added, I just create a new Entity with a renderable component and a mesh component and add it to the scene (the mesh component is a simple small box at the moment). Because it's added to the scene like just any other renderable entity, I can select the box and move it around using my normal object selection/moving functionality. In order to keep all the nodes under control, I need some kind of object to own these nodes, like a TerrainRoad entity or something similar. This would also contain the Catmull Rom Spline for drawing the lines between the nodes, etc. and possibly the mesh of the road geometry itself.

It doesn't really feel like this should be handled within the entity component system and it feels like I'd have to change the system to fit this model. I would need something like:

Terrain Road entity

\- Catmull Rom Spline

\- Control node entities

\- Renderable component (for road geometry)

\- Mesh component (for road geometry)

This would mean entities owning other entities which I'm sure I'll have to support at some point but that would be more for sword in hand type stuff. Should I continue trying to fit this model into the entity component system or shall I just leave that for actual game objects (like the resulting actual road geometry) and handle it in specialised classes? Thing is, I would like to be able to select and move the control points around and I don't want to have to write separate selecting/moving code for that although perhaps it's that which is leading me into this design issue.

Any thoughts?

I guess it may of depend on how "interactive" your road is with the rest of game? It's hard to say where the best place for it is without knowing more details about what roads are used for. Like if it's just a static mesh that gets rendered on top of the terrain and that's it, it might be simpler if it were just a separate thing (like terrain presumably is?). But if there are multiple roads, and they can be - I dunno - modified in game, or created/destroyed, then they might make more sense to be entities (are the spline and control nodes used during gameplay?). Ideally, I wouldn't force a game design based on limitations of the editor though.

This would mean entities owning other entities which I'm sure I'll have to support at some point but that would be more for sword in hand type stuff.

A parent-child relationship for transforms is obvious, but there's nothing stopping you from expressing other parent-child relationships in the ecs. Inventory->Items, Team->Players, Road->Control nodes. Don't think of it as an entity "owning" another, but simply there being a relationship between one entity and another. This relationship can be expressed in a component (e.g. a TransformChildren component containing a list of entity ids for its "children", or an Inventory component containing a list of entity ids for the inventory items). Just some food for thought.

Thanks, this helps a lot.

The road isn't interactive at all, it's just decoration really - a static mesh over the terrain, although I'll need to know when the player is on it but that'll be handled later.

I guess I was looking for it to just slot in but obviously that's not going to happen. The component to specify the relationships is a good idea.

Thanks