Redundant default position rotation scale properties on entities?

[dvdking]

Entity has the following default properties.

[Browse(Never)] public  ref EntityName      Name        => ref archetype.std.name.    components[compIndex];
[Browse(Never)] public  ref Position        Position    => ref archetype.std.position.components[compIndex];
[Browse(Never)] public  ref Rotation        Rotation    => ref archetype.std.rotation.components[compIndex];
[Browse(Never)] public  ref Scale3          Scale3      => ref archetype.std.scale3.  components[compIndex];

And while Name might be justified and convenient, position, rotation, scale are not.

Reasons are:

• These types use system vector type, but most engines have their own (unity Vector3 or float3, godot has their own thing etc.).
• Not all entities require these properties. I have a variety of entities which are not entities rendered on scene (playerinput, status effects)
• Entities could be 2d or 3d

Alternatively, these could be added as extension methods if needed.

[friflo]

When adding those properties I was aware of multiple pros and cons.
You already listed some cons.

Pros

1. Developers new to game dev would expect properties like this. Otherwise they are unsure what to do.

2. The performance boost of entity.Position in opposite to entity.GetComponent<Position>() is 3x.
   See microbenchmark in Test_SchemaType.cs and below. It comes near to the performance of a class property.

3. When using a debugger these common used properties are very easy to Watch.
   Even with a mouse hover.

4. In case two independent projects (using these components) are used in combination they already have a
   "lowest common denominator".

Cons

1. Experienced developers would like to have their own (extension) properties named: Position, Rotation & Scale3

2. The component types Position, Rotation & Scale3 are "reserved" by the library.
   Experienced developers would like to use these type names by themselves.

Because of the listed pros I decided to add them. Especially the performance argument.
The existence of those properties have no performance impact if not used. So they can be simply ignored / not used.
Removing these properties now will break projects with high probability.

I leave this discussion open. So others could add their opinion.

[friflo]

@dvdking

Comments specific to the reasons in your post above:

These types use system vector type, but most engines have their own (unity Vector3 or float3, godot has their own thing etc.).

The focus of this ECS is .NET - so that's the reason of using System.Numberics.Vector3

Not all entities require these properties. I have a variety of entities which are not entities rendered on scene (playerinput, status effects)

These properties can be simplify ignored / not used.
Accidental access will result in an NRE with a stacktrace showing which property was the culprit.
The existence of these interfaces have no performance impact on CPU or memory.

Entities could be 2d or 3d

This is the reason of using Vector3 as "lowest common denominator".