I'm implementing a basic skill and attribute system, though I'm having second thoughts about how I should go about it.

For example, I could use a Dictionary/HashMap which uses SkillType enums to represent keys, and integer values representing the values. But should I do this?

public class Skills
    public IDictionary<StatType, Int> skills; //StatType is enum, being the key; the int //is the value.



public class Skills
    public int LongBlade, Armor, Marksman; //...etc

I'd like to know the benefits of type safety here, as opposed to just using basic integers. Any recommendations?

  • \$\begingroup\$ I'd prefer interface Skill { /* ... */ int toInt(); }; public class Skills : IList { private ArrayList<Skill> skills; /* ... */ };, actually ... \$\endgroup\$ – Martin Sojka Aug 11 '11 at 7:37

If there is eventually going to be:

  • a large variety of skill types across your game,
  • or ability-granting items,
  • or ability-granting buffs,
  • or a large ability tree,

then I start to prefer the flexibility of string or integer keys in a dictionary instead of individual instance fields or even a dictionary with an enum key.

My reasoning-- Because you may soon realize...

Boy, it'd be nice if I could tweak my mathcraft and select unit abilities in (my favorite text editor | Excel | a custom tool ).

...at which point a dictionary with string or integer keys become a more natural fit than having to maintain enum values or a long list of instance fields yourself. However, said tool could always be written to generate C# code too, so you may be able to find a happy hybrid.

If your game complexity is going to be fairly simple and your variety of skills small, then managing instance fields by hand (instead of dictionary & enum) seems more convenient and avoids a level of indirection, both at run-time and "keystroke"-time.

| improve this answer | |
  • \$\begingroup\$ What do you mean by unit abilities and mathcraft though? I'm not quite following, at least in that regard. I would like to use an enum, if that's practical though. \$\endgroup\$ – blissfreak Aug 11 '11 at 5:11
  • \$\begingroup\$ I partially agree with you, string are great to higher levels (eg the scripting API) but to move strings around is not a good idea (memory and moving time limit the maximum amount of ops you can do per frame). Be hybrid may be an option: named entities with integer identifiers. The names has to be stored once (in a singleton map perhaps) and entities identifies themselves using integers. Doing so you can put strings in your interfaces if needed and work as if they were enums. \$\endgroup\$ – FxIII Aug 11 '11 at 7:23
  • \$\begingroup\$ @fxiii I agree, and is why I mentioned "string or integer". I didn't go into great detail though, so thank you for raising some why and how with respect to using integers. \$\endgroup\$ – DuckMaestro Aug 24 '11 at 0:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.