2
\$\begingroup\$

I was looking at a question about the usage of Unity ECS and it was tagged with entity-component-system but was specifically about how to achieve a desired effect in Unity's entity-component-system.

Obviously this is valid but not necessarily useful for people just looking for generic questions about how entity-component-systems work. So should questions about specific implementations of a technology be given their own tag to differentiate between them? I see this becoming a bigger thing as more questions will be about this in the future (with Unity pushing this specific feature), so implementation specific posts will quickly outnumber generic posts about the technology itself.

Is this a valid concern?

\$\endgroup\$
4
\$\begingroup\$

I think I'll answer 'no' to this one. (Just to make it clear what the up-votes and down-votes are for.)

My main concern is that if we do it for Unity, we'll most likely need to do it for other engines and their technology implementation; and where will the line be? Will we end-up with godot-ecs, sfml-networking, ogre-audio?

I tend to want to reduce the number of tags rather than increase it because it blurs the pool tag and end-up creating confusion.

And with unity-ecs around, I really see questions tagged as such coming around:

.... Oh crap.. no room for !

There has also been discussions in the past about removing/merging specific tags related to a technology:

\$\endgroup\$
2
\$\begingroup\$

I'd also lean toward "no, we don't need an implementation-specific version of [all general technology tags / the tag in particular]" for the reasons Alexandre Vaillancourt described in this answer, as well as another specific to the ECS case:

I think the tag is good for unifying questions about ECS approaches or strategies, which can include applications to Unity without being limited to Unity specifics.

For instance, a user could ask "How can I adapt my AI search behaviour to work in a data-oriented ECS fashion?" with tags , , etc. That question is high-level enough that anyone with experience thinking in an ECS way could help - suggesting what data to break out into components and what passes of systems/data transformations will achieve the same end. They don't necessarily need to know the ins and outs of Unity's job system to discuss the architecture at this level.

If we have questions that are very specific about Unity's implementation, say because they're about solving a problem in the HPC# language or making the Burst compiler behave a particular way, then I think those questions are better-served by identifying that focus more precisely - say having an HPC#-Burst tag alongside to emphasize the distinction of this dialect. This calls out the specific skill set at hand rather than a general topic of interest.

I think a narrowly-focused tag like this is less likely to be misused as a catch-all for any and all questions relating to ECS approaches in Unity (served sufficiently by the existing tags), and better focuses on a specific area of expertise (ie. familiarity with a specific language/compiler), making it useful for searching/filtering.

Whether we need such an HPC#-Burst tag at all remains to be seen. I haven't yet observed a large number of questions specific to the ins and outs of burst jobs in Unity, so for now I'd be inclined to watch & wait to see whether the topic develops into one that demands more filtering tools to navigate.

\$\endgroup\$
0
\$\begingroup\$

That being said, it would not be completely honest on my part to not mention the other discussions that occurred to keep those tags:

So this would be matter for 'yes, let's add unity-ecs because we've done it in the past', but that's only that. Someone with more knowledge about Unity and its ECS implementation will most likely come up with more valid arguments.


We'll most likely need a kind of policy to keep the questions tagged cleanly.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .