Where once there was an Array there is now a std::Map
Published on December 11, 2009 By ScottTykoski In Elemental Dev Journals
Wow, what a week. A task that I had assumed would take 1.5 days ended up sucking up around 32 hours. While my lack of scheduling foresight sucks, the time was DEFIANTLY worth it to have this vital feature done right...
 
In previous builds, all unit stat handling was done with a basic array of stats.  There was a hard-coded list of what could and could not be stored in it (Strength, Defense, and HP to name a few). It worked, but with several new stats in the pipeline (Magic Attack, Magic Strength, Structural Damage) and the ongoing discussion on other damage types, I figured it was time to rework the system in a data-friendly way.
 
We now store all unit stat data in what are called MAPS, where entries are sorted by a STRING, opposed to a numeric INDEX. Now, instead of using afStats[1] to get hit points, the developers use mapfStats['HitPoints']. We also have a file that defines the given stats for the game...
 
<UnitStatType InternalName="UnitStat_HitPoints">
<DisplayName>Hit Points</DisplayName>
<Icon>Icon_Heart.png</Icon>
<Description>How much damage a unit can endure before kickin' the bucket.</Description>
</UnitStatType>
 
The above would let the game know that 'UnitStat_HitPoints' is a valid unit stat. You could then add a stat type by defining it in XML...
 
<UnitStatType InternalName="UnitStat_BluntAttack">
<DisplayName>Blunt Attack</DisplayName>
<Icon>Icon_Club.png</Icon>
<Description>The blunt damage this unit will deal when attacking.</Description>
</UnitStatType>
 
You then add a stat modifier to a weapon...
 
<GameMod>
<Type>Unit</Type>
<Attribute>UnitStat_BluntAttack</Attribute>
<Value>5<Value>
</GameMod>

And the game will know that any unit with that weapon does 5 points blunt attack.  Hooking this up to the battle system in a data-driven fashion will be another adventure, but at least the raw data is now organized and manageable. A good week...even if I wish I had more to show for it

Comments (Page 1)
on Dec 11, 2009

That looks awesome, Boogie. Very user friendly and moddable too

on Dec 11, 2009

I'll agree, I love that you guys show us the "behind the scenes" stuff  

on Dec 11, 2009

Wow, what a week. A task that I had assumed would take 1.5 days ended up sucking up around 32 hours. While my lack of scheduling foresight sucks

 

Actually it sounds like your scheduling foresight was spot on, what with 1.5 days being 36 hours and all.

on Dec 11, 2009

If only they worked 24 hours a day - then we'd have Elemental by springtime.

on Dec 11, 2009

This is fantastic good news. It'd have been extremely difficult to model exotic units otherwise in mods. Thanks!

on Dec 11, 2009

 

Actually it sounds like your scheduling foresight was spot on, what with 1.5 days being 36 hours and all.
  Hehe  Good point   Damn you sleep and family for screwing up my estimations!!!!

on Dec 11, 2009

Neat, that feature was more or less necessary for mods.

By the way, is all of your XML editted by hand, or is there editors which make allow you to not see the eyesore that is the raw XML?

on Dec 11, 2009

This is very good news for us modders, and it should help quite the endless damage-types debate........ once we get things in our hot little hands, I'll begin taking requests for new damage systems from those of you who care about that sort of thing.....

on Dec 11, 2009

A good week...even if I wish I had more to show for it

It may not seem much, but it probally greatly cuts down on the number of problems later. Those problems... is stuff you never want to show.

on Dec 11, 2009

Nice work Boogie If I may add, it may be interesting to read Steve Yegge post on prototype-based design, which is more or less the formal name of what you have done

http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html

Designing things like that makes them very very extensible (good for modding and for prototyping). He talks a little about how it helped in his own game (Wyvern) and the objectives he had for it (enable the community to generate lot of content for the game).

on Dec 11, 2009

Was DEFIANTLY a clever word choice or a typo?

on Dec 12, 2009

Was DEFIANTLY a clever word choice or a typo?

Almost like he was trying to prove a point to someone, no? You did good Boogie.

on Dec 12, 2009

I am not sure if it is related but,

I have made a little piece of code to test something for a (maybe) future RPG ...

I found it really effective  to be able to define primary stats and secundary stats in XML ( for exemple, let us take vitality as base stats and hit points as a secundary stat ... meaning it calculated by a formula from the base stats) .
To define a comportement fully on xml, it is possible to add even the formulas in XML.Here is an example of what is possible to make ( the engine is in C#)

Code: xml
  1. <StatsMain>
  2.     <Stat Name="int">
  3.       <InitialValue>0</InitialValue>
  4.     </Stat>
  5.     <Stat Name="str">
  6.       <InitialValue>0</InitialValue>
  7.     </Stat>
  8.     <Stat Name="dex">
  9.       <InitialValue>0</InitialValue>
  10.     </Stat>
  11.     <Stat Name="luk">
  12.       <InitialValue>0</InitialValue>
  13.     </Stat>
  14.     <Stat Name="agi">
  15.       <InitialValue>0</InitialValue>
  16.     </Stat>
  17.     <Stat Name="vit">
  18.       <InitialValue>0</InitialValue>
  19.     </Stat>
  20.   </StatsMain>
  21.   <StatsCalculables>
  22.     <ScriptedStat Name="HP">
  23.       <Script>player["HP"]= 100 + player["vit"]*5;</Script>
  24.     </ScriptedStat>
  25.     <ScriptedStat Name="MP">
  26.       <Script>player["MP"]= 10 + player["int"]*3;</Script>
  27.     </ScriptedStat>
  28.   </StatsCalculables>
  29.   <StatsConstants>
  30.     <Stat Name="lvl">
  31.       <InitialValue>1</InitialValue>
  32.     </Stat>
  33.   </StatsConstants>
  34.   <NonNumeric>
  35.     <CustomStat Name="name" Type="String" />
  36.     <CustomStat Name="guild" Type="String" />
  37.     <CustomStat Name="intStat" Type="Int32" />
  38.   </NonNumeric>

Moreover ( that part is very important for a RPG), you can think of a way to add different levels of boost. meaning such boost will affect a stat after or before such other boost... and making the secondary stats always take the last boosted primary stats as base of calculation (exemple of boost/capacity)

Code: xml
  1. <ScriptedStat Name="HP">
  2.     <Script>player["HP"]= 100 + player["vit_last"]*5;</Script>
  3. </ScriptedStat>
  4. <ScriptedBoost="IronSkin">
  5.     <Script>
  6.        player["vit_1"]+= player["vit"]*2;
  7.        player["HP_1"]+= player["vit_last"]*5;
  8.     </Script>
  9. </ScriptedBoost>
  10. <ScriptedCapacity="ForceFiled">
  11.     <Script>player["vit_3"]+=player["vit_1"]*2;</Script>
  12. </ScriptedCapacity>

Using this kind of tools, I think you can manage to put (nearly) everything about player/unit evolution in xml format outside of the engine.
I hope this will give ideas for developpers to make a more modular and more fun game.

 

 

PS: I can give the code (it is not a really mature piece of code, but maybe someone will be interested) managing the stats and the translation from scripts to anyone who want ( C#)

Edit: http://www.megaupload.com/?d=060F2KFD

 

 

on Dec 12, 2009

Was DEFIANTLY a clever word choice or a typo?

I'll give the spell checker credit for that one

on Dec 12, 2009

To define a comportement fully on xml, it is possible to add even the formulas in XML.
Yeah, Cari just for equations reading in through XML, so I have a feeling that's how we'll end up incorporating these stat types into the main game...good call