I am working on a skill system for use in a game project I'm chipping away at. The project is entirely in C# so I'm using .NET to its advantage.

In my preliminary implementation of a Skill Category -> Skill types system I'm using subclasses of ISkill and SkillCategory (base class with some virtuals) and using System.Type based reflection to generate a map of these at runtime (on demand).

The great thing about this implementation is that it entirely decouples specific skill types (such as Engineering / LaserWeapons from the SkillLibrary (the container for the generated skill mapping).

The goal is to remove the need to explicitly add each skill at some point as they are automatically detected by the library throughout the entire AppDomain.

Only game logic which relies on these skills use concrete types.

ISkill

public interface ISkill
{
  string GetName();
  string GetDescription();
  int GetSkillLevels();
  float GetMinutesOfTrainingForLevel(int level);
}

[SkillCategory(typeof(EngineeringSkills))]
public class LaserWeaponSkill : ISkill
{
  public string GetName()
  {
    return "Laser Weapons";
  }

  public string GetDescription()
  {
    return "Allows you to maintain and improve laser based weapons on your ship.";
  }
}

Usage example:

[RequiredUpgradeSkill(typeof(Skills.Engineering.LaserWeapons))]
public class LaserTurretWeapon : IShipWeapon
{
}

There's two slight ugliness's with being very System.Type based, though. One is that my Player._skillLevels dictionary can't serialize as Dictionary<Type, int> because Type isn't supported by DataContractSerializer (what I'm using at the moment).

So what I'm doing in SetSkillLevel<TSkill>(int level) and GetSkillLevel<TSkill>() is translating typeof(TSkill) to and from a string using typeof(TSkill).FullName (i.e. "Game.Skills.Engineering.LaserWeapons").

And the other is potential performance problems, which is something I should profile.

This all works, of course, but it feels like the weak point in an otherwise enum-less, strongly typed skill definition system.

I don't really want to use enums and a "list" of Skill structures, or move it to an external data definition file because then that requires more maintenance of created and deleted enum values and such.

Do you think this is worth it, or do topics such as performance of Type based operations and other considerations make it worth rethinking?

I am working on a skill system for use in a game project I'm chipping away at. The project is entirely in C# so I'm using .NET to its advantage.

In my preliminary implementation of a Skill Category -> Skill types system I'm using subclasses of ISkill and SkillCategory (base class with some virtuals) and using System.Type based reflection to generate a map of these at runtime (on demand).

The great thing about this implementation is that it entirely decouples specific skill types (such as Engineering / LaserWeapons from the SkillLibrary (the container for the generated skill mapping).

The goal is to remove the need to explicitly add each skill at some point as they are automatically detected by the library throughout the entire AppDomain.

Only game logic which relies on these skills use concrete types.

ISkill

public interface ISkill
{
  string GetName();
  string GetDescription();
  int GetSkillLevels();
  float GetMinutesOfTrainingForLevel(int level);
}

[SkillCategory(typeof(EngineeringSkills))]
[PrerequisiteSkill(typeof(ElectronicsSkill))]
public class LaserWeaponSkill : ISkill
{
  public string GetName()
  {
    return "Laser Weapons";
  }

  public string GetDescription()
  {
    return "Allows you to maintain and improve laser based weapons on your ship.";
  }
}

Usage example:

[RequiredUpgradeSkill(typeof(Skills.Engineering.LaserWeapons))]
public class LaserTurretWeapon : IShipWeapon
{
}

There's two slight ugliness's with being very System.Type based, though. One is that my Player._skillLevels dictionary can't serialize as Dictionary<Type, int> because Type isn't supported by DataContractSerializer (what I'm using at the moment).

So what I'm doing in SetSkillLevel<TSkill>(int level) and GetSkillLevel<TSkill>() is translating typeof(TSkill) to and from a string using typeof(TSkill).FullName (i.e. "Game.Skills.Engineering.LaserWeapons").

And the other is potential performance problems, which is something I should profile.

This all works, of course, but it feels like the weak point in an otherwise enum-less, strongly typed skill definition system.

I don't really want to use enums and a "list" of Skill structures, or move it to an external data definition file because then that requires more maintenance of created and deleted enum values and such.

Do you think this is worth it, or do topics such as performance of Type based operations and other considerations make it worth rethinking?

I am working on a skill system for use in a game project I'm chipping away at. The project is entirely in C# so I'm using .NET to its advantage.

In my preliminary implementation of a Skill Category -> Skill types system I'm using subclasses of ISkill and SkillCategory (base class with some virtuals) and using System.Type based reflection to generate a map of these at runtime (on demand).

The great thing about this implementation is that it entirely decouples specific skill types (such as Engineering / LaserWeapons from the SkillLibrary (the container for the generated skill mapping).

The goal is to remove the need to explicitly add each skill at some point as they are automatically detected by the library throughout the entire AppDomain.

Only game logic which relies on these skills use concrete types.

ISkill

public interface ISkill
{
  string GetName();
  string GetDescription();
  int GetSkillLevels();
  float GetMinutesOfTrainingForLevel(int level);
}

[SkillCategory(typeof(EngineeringSkills))]
public class LaserWeaponSkill : ISkill
{
  public string GetName()
  {
    return "Laser Weapons";
  }

  public string GetDescription()
  {
    return "Allows you to maintain and improve laser based weapons on your ship.";
  }
}

Usage example:

[RequiredUpgradeSkill(typeof(Skills.Engineering.LaserWeapons))]
public class LaserTurretWeapon : IShipWeapon
{
}

There's two slight ugliness's with being very System.Type based, though. One is that my Player._skillLevels dictionary can't serialize as Dictionary<Type, int> because Type isn't supported by DataContractSerializer (what I'm using at the moment).

So what I'm doing in SetSkillLevel<TSkill>(int level) and GetSkillLevel<TSkill>() is translating typeof(TSkill) to and from a string using typeof(TSkill).FullName (i.e. "Game.Skills.Engineering.LaserWeapons").

This all works, of course, but it feels like the weak point in an otherwise enum-less, strongly typed skill definition system.

I don't really want to use enums and a "list" of Skill structures, or move it to an external data definition file because then that requires more maintenance of created and deleted enum values and such.

Do you think this is worth it, or do topics such as performance of Type based operations and other considerations make it worth rethinking?

I am working on a skill system for use in a game project I'm chipping away at. The project is entirely in C# so I'm using .NET to its advantage.

In my preliminary implementation of a Skill Category -> Skill types system I'm using subclasses of ISkill and SkillCategory (base class with some virtuals) and using System.Type based reflection to generate a map of these at runtime (on demand).

The great thing about this implementation is that it entirely decouples specific skill types (such as Engineering / LaserWeapons from the SkillLibrary (the container for the generated skill mapping).

The goal is to remove the need to explicitly add each skill at some point as they are automatically detected by the library throughout the entire AppDomain.

Only game logic which relies on these skills use concrete types.

ISkill

public interface ISkill
{
  string GetName();
  string GetDescription();
  int GetSkillLevels();
  float GetMinutesOfTrainingForLevel(int level);
}

[SkillCategory(typeof(EngineeringSkills))]
public class LaserWeaponSkill : ISkill
{
  public string GetName()
  {
    return "Laser Weapons";
  }

  public string GetDescription()
  {
    return "Allows you to maintain and improve laser based weapons on your ship.";
  }
}

Usage example:

[RequiredUpgradeSkill(typeof(Skills.Engineering.LaserWeapons))]
public class LaserTurretWeapon : IShipWeapon
{
}

There's two slight ugliness's with being very System.Type based, though. One is that my Player._skillLevels dictionary can't serialize as Dictionary<Type, int> because Type isn't supported by DataContractSerializer (what I'm using at the moment).

So what I'm doing in SetSkillLevel<TSkill>(int level) and GetSkillLevel<TSkill>() is translating typeof(TSkill) to and from a string using typeof(TSkill).FullName (i.e. "Game.Skills.Engineering.LaserWeapons").

And the other is potential performance problems, which is something I should profile.

This all works, of course, but it feels like the weak point in an otherwise enum-less, strongly typed skill definition system.

I don't really want to use enums and a "list" of Skill structures, or move it to an external data definition file because then that requires more maintenance of created and deleted enum values and such.

Do you think this is worth it, or do topics such as performance of Type based operations and other considerations make it worth rethinking?