In ECS it seems like the production and processing of the data will become the program flow, what used to be a stack trace or function call list is now data being produced and consumed by systems.
So we are going to end up with games with many systems interacting and sometimes we will see bugs which is fine if the bug is in the system where it is caught but what if we have multiple systems passing data and we have to hunt down which system generated the buggy data
e.g. A non-normalised vector appears in the movement code…
Suspect systems: Animation, Control, AI, Particle, Physics, Navigation, Atmospheric, Collision, Explosion, Networking, Sound…
So will there be ECS debug tools that allow us to easily trace aberrant data bugs from where they are triggering an error or found to where they were created?
Maybe debug entity data could have a unique id that gets passed through the games ECS system, along with logging or recording of when data enters and exits a system to provide a stack trace/data flow debugging feature?
if a specific component always needs to be normalized, you should put that constraint into the component:
struct NormalizedVelocity : IComponentData {
public readonly float3 value;
public NormalizedVelocity(float3 value) {
// in editor, log error / throw if value is not normalized
this.value = normalized(value);
}
}
Besides better trace/reporting, I think debugging in ECS can be made better with some kind of node-based visual tool. The Overwatch team made their own ECS and visual scripting tool to greatly improve their iteration time. Looked pretty dope during one of their GDC talks.
“Generates performant C# at runtime”. It would be really neat if this is being developed with ECS in-mind. “Generate Systems at runtime” will be a dream-come-true.
Of that’s the design they’re going with, I like it more than the kismessy-ness of blueprintlikes that most people think of, reminds me more of scratch/gamemaker with stronger focus on vertical logic flow and keeping related instructions in one readable column.
Ramble / nostalgia alert:
I tinkered with the idea of rolling my own visual editor back around 2014, but I ran into (what I considered) unacceptable issues with reflection and looked at using Cecil to build dll silos for user scripts. This was back when the only way to have fast project loading was manually setting up library dlls (no assemblydefs) so I thought it was the right way to go at the time. Had I finished it, the editor would manipulate a version of the dll in memory and then would write it back to disk, using the dll as both the graph source file (with strippable attributes for editor info) and conveniently not requiring any other generated sources. I ran into issues with that approach for platform specific code since there wasn’t a way of setting which platforms could load a dll at the time, and the complexity of the whole thing was looking enormous even on paper. I got busy with contract work and never got past the ui design / il dll load manipulation prototypes, and the rise of more asset store solutions kinda muted any business enthusiasm I had left.
But my UI sketches from back then look eerily similar to the mockup/screenshot in the roadmap images, and that sent me into memory lane.
That would help developers work out where their data can go but it’s a long way from a list of where the data has been that could be used like a stack trace to find a bug in your code.
You could probably add debug trace to ECS data in a few bytes, a byte for the system ID it was created in then a few bytes for the systems it has traversed. If the number of bytes is configurable finding deeper bugs or attaching better debugging to some data could be an option.
Meta analysis should allow the tracking of smaller data chunks between systems where data is passed onto new systems in new archetypes.
