Mixin or not to mixin.

[aliessmael]

Hi, I am trying to make game and wondering what is best design for my problem.

Let say I want to make
MyPlayer class which can play sound, produce light and fall by physics.

MyTeamPlayer can play sound and move by Ai system.

MyCar moved by Vehicle system play sound and produce light.

So what I am thinking is to implement every feature as seperate clean code then compose my classes with these features. Features are

AudioSource.
LightSource.
Rigidbody.
Agent (AI).
Vehicle.

Will mixin help me or may be use something else (may be code copy for every class 😊)

Please note

-I want each feature to have its own fields.

• My class must be castable to any feature, because for example want to add MyPlayer as Rigidbody to physics system.

-It will be awsome to call feature constructor and destructor automaticlly when my class get created or destoyed( so i add MyPlayer to physics system automaticlly when get created without extra setup inside MyPlayer) .

• Finally those feature can use same field (for example all features and classes have Position which is same for all, field sharing if many feature or class have same name they will share it).

Is it possible to do it currently with clean code or I should wait mixins to get improved,or wait for multi inheritance support ( with field sharing support), or may be you make something called feature.

Thanks.

[TahirAhmadov]

Currently C# doesn't support what you are describing natively, I asked for something like this here: #5897

In the meantime, you can do it manually: add "feature" type fields to your MyPlayer etc. classes, and create implicit conversion operators to those feature types, and then MyPlayer.Dispose can also call Dispose of feature fields, and obviously the MyPlayer ctor can set those feature fields to constructed instances.

[qrli]

You don't need mixin. That pattern was a specific solution for C++.

The same can be achieved by simple normal composition. The only difference is that: instead of entity.x with mixin, you will need to write entity.Position.X with composition. It may be a little verbose at first, but when the code grows the verbosity has an advantage. For the scenario where you want to test feature availability on an entity:

• You can use interfaces like interface IHasAudioSource { AudioSource AudioSource { get; } }
• Or, you can choose to expose enum property on the entity class like class Entity { public Features Features { get; } }
  There could also be special cases you may need the same feature more than once in the same entity, and it is straightforward with composition.

A more advanced design is component-based entities, which an entity has a collection of feature components, and the components can be added or removed dynamically. This is typically used in game engines where customization and extensibility is highly needed.