Print

[jamespro]

Our game is more of a skill based game rather then class based... Character's will get a Class Title based on their top skills at any one time.

I've got, both on the Server and Client, a SkillSpec and SkillSpecOracle so we are now able to add skills through the utility menu.

First of all through the spec system will we be able to raise the max level of a skill after launch or will we have to keep the skill levels the same through out the life of the game?

Also since with skills there are some mutable and immutable data needed I am guessing I will need to give each player a new instance of the skill so their instance can change with out affecting any one else... I am still figuring this out but I would add a new class Skill for instance and then that class would be instantiated when the player gained the skill. So do step number 3 in this guide - http://hewiki.heroengine.com/wiki/Creating_a_New_Spec_Oracle_%28Step_by_Step%29 am I correct?

[jamespro]

I was wondering... I now have chat commands which will be connected to a gui for using skills and I have a method that allows characters to learn skills but I was wondering if this is a good way of doing it or if there is some other way I should be doing it?

method LearnSkill(skill as String, skillID as ID)
  var oracle = $SPECORACLEUTILS._GetOracleFromType("SkillSpecOracle")
  mySkillSpec as NodeRef of Class SkillSpec = oracle.GetSpecByKey(skillID)
 
  _skill as String = toLower(skill)
  me.mySkills[_skill] = mySkillSpec.CreateFromSpec()
 
  $CHAT.ChatArea("game", "You Learned a New Skill: " + _skill)
.

[HE-JAY]

Updating Immutable-ish Data
You are correct to be wary of modifying the DOM in a production environment (as this is very much not recommended).

There are two ways you might handle this situation:

• Update the DOM during a planned maintenance outage and keep the max skill level immutable
• Make the max skill level mutable and store it either in the skill spec or a separate oracle which you could reference from your skills

If you choose the first option, you can safely ignore the ambiguous nature of the max skill level and - if it changes - just perform a scheduled maintenance outage (making sure you take into account any consequent effects of raising the skill level).

If you choose the second option, this becomes slightly more dynamic and could handle changes to the maximum skill level while the world is running.

Instantiating Spec-derived Objects
If indeed there is a significant amount of mutable data involved in your skills, I do agree that instantiating spec-derived objects is the way to go. If, on the other hand, all you need to keep track of are skill levels - it may be more appropriate simply to keep a data structure mapping skill id to skill level (as an example). This is kinder on the programmer to code and less of a resource hog than creating objects for each skill simply to track its level.

Skill Notifications
Two comments on this point:

• Using ChatArea is almost certainly wrong, as that will message every player in the area. If you must use the chat system to deliver messages, use ChatPlayer.
• Better yet would be a specific call in your (theoretical) $SKILLS system node, perhaps $SKILLS.notifyPlayerOfSkillEvent(...), which would then call the client-side $SKILLS node, which would then notify any listening GUIs, etc. Far better to use your system nodes as public interfaces than to rely on the chat system or something similar.

Let me know if there are any other questions you have regarding specs, spec oracles, etc.

Thanks,
-Jay

[JoshHalls]

We used collections when we implemented our basic skill needs.  I would actually recommend not doing that as it sends over a ton of information initially.  I believe I ended up breaking out some of the updated information since it wasn't needed in the initial push to the client.  We have gone more with what Jay has mentioned or replicated nodes.  We have 150 skills or so that everyone gets and they can then progress those skills through certain abilities or other functions and that 150 causes a bit of a spike in initial login.  Probably will rewrite it sometime here soon, but an FYI from my experiences there at least.