Jump to content

  • Log In with Google      Sign In   
  • Create Account

Norman Barrows

Member Since 04 Apr 2012
Offline Last Active Nov 26 2015 11:46 AM

#5263653 baseline value of items in a RPG

Posted by Norman Barrows on 25 November 2015 - 06:22 PM

ok, so i settled on the following formulas for a first attempt:


gather-able base value = avg gather time for one unit / resource frequency + skills cost + tools cost


craft-able base value = crafting time + parts cost + skills cost + tools cost


final value = base value * quality * demand


turns out that skills cost for gather-ables, when divided between all units gathered over your lifetime, is pretty much negligible.


looks like tool costs for both gather-ables and craft-ables will be somewhere between 1/20 and 1/100 of the tool cost.


since value of gatherables that require no tools is basically the average time required, i started by making sure the average gather times made sense.  so i assigned an average gather time for all gatherables, and then set the time and chance for each appropriately. so now all gatherables do a success check every game second, minute, or hour, and the chances are adjusted accordingly. 


so now i'm crunching the base values of avgtime / frequency, and i've come up with an interesting case: vines.   they're only found in jungles, so the frequency is very low (0.0625.   compare to 0.5 for wood, or 0.3 for stone or water, or 0.2 for reeds).   reeds, tendon, and vines are only used to make cordage. but the low frequency of vines makes base value higher. so three different resources which can only be used to craft the same one item have three different values.   should i say that vines and tendon are worth no more than reeds?   or should i say that if you can't get reeds, you can always trade for vines or tendon, but it'll cost you more?

#5263650 baseline value of items in a RPG

Posted by Norman Barrows on 25 November 2015 - 06:01 PM

You sweat more under exertion which in a dry climate can be critical supply issue (and certainly requiring more time/capacity  dedicated to water and its containers)


yeah, i have to make sure water goes down faster when its hot.  adding it to the todo list now...   ok, got it.


rarity  - example was flint, that most useful of materials, where it often was low grade many places but good workable grade few, and in places that was found (like chalk banks with flint nodules) people came from hundreds of miles around to mine it for millenia  and some of the Clovis sites had huge piles of stone chipping showing that many people came there regularly for many hundreds of years from long distances to get optimal materials (and did work onsite to minimize what they had to haul back)


B.G. you've been doing your homework! 

#5263492 baseline value of items in a RPG

Posted by Norman Barrows on 24 November 2015 - 07:11 PM



somehow i lost my response to your two recent posts.


everything you mention except favors is in there.already. i like the idea of favors. sharing a kill could only be done with NPCs already in the vicinity, as the meat would usually spoil before you could transport it to the nearest band for trading.


The problem is you are trying to have a accounting metric to something that is vague/irregular


you're right. i think i can get it down to a few hard numbers (time, tools, skills, etc) and one subjective value (demand / usefulness). the more i can just crunch, and the less i have to guesstimate-test-tweak, the better.

#5263490 baseline value of items in a RPG

Posted by Norman Barrows on 24 November 2015 - 05:56 PM

Am I mistaken in my impression that every action has an effect on food, water, and fatigue points?


yes.  sedentary actions do not increase fatigue. weapons training increases it quickly. movement increases it based on movement rate. needless to say, combat also increases it. all other actions increase it as the same low rate.  food goes down at a constant rate, faster when its cold. water goes down at a constant rate. not sure if it goes down faster when its hot yet or not. i'd have to look it up.


If you sat around all day crafting stuff, you still need to eat, right?


B.G.  according to the online body mass and caloric intake calculators, i burn 768 calories a day just laying in bed and breathing. in case you didn't guess, i have a super killer metabolism.


In effect, if whatever you do expends food points then this would be the real cost of taking the time to do something.


actually, i'm thinking time is the real cost of everything.  in the real world, there are really only two basic resources (sort of): time, and money.  take away money, and that leaves time as the true cost of everything. the value of a food point can be expressed in terms of the time required to gather + plus tool and skills costs, which can also be expressed in terms of time required.


I'm thinking that "usefulness" could be the average amount of which a tool decreases the expenditure of these points in a task for the lifetime of the object.


unfortunately, most tools don't decrease the amount of time / food burned. they are prerequisites. no tool, no action - at all.  so a cutting tool means you can gather reeds at the rate of say 1/20th of a food point per unit gathered or 20 reeds per food point burned. . and no cutting tool means you can gather reeds at the rate of infinite food points burned per unit gathered, or zero reeds per food point burned.   so the difference would be infinity-1/20, or 20-0, depending on how you look at it.


It would then be a matter of coming up with some way to measure each item's effectiveness, even if that measurement is outside the game to come up with a baseline. If you don't have a way to measure this, I don't see how you can escape using arbitrary values that just feel right.


i was thinking that the number of actions that required an item might be a good measure of usefulness.  i've already determined that a 3 point scale for usefulness (low, medium, high) is not big enough. once you take out the low and high items, the remaining ones are not all equally useful. so at least a 1-5 scale is required. but in the end, i suspect you're right and i'll have to go through and assign 'best guess" values, then test and tweak. between the  number of actions that require an item, and how often one typically performs those actions, i suspect it won't be too hard to come up with good numbers. thank god i just got done play testing three game years worth of playing, so i know what actions are common vs uncommon.


The one variable that you're looking at that seems the most arbitrary to me is "rarity". I don't think you want to look so much at how commonly found something is but at the investment required to harvest that resource usefully


rarity factors into that, as rarer resources (IE those found in fewer map squares on average) will require more travel time on average to gather. IE if you start in a random map square, and select a random resource, the travel time will on average will be higher for rarer resources.


Setting the "price" which something should be traded for would then be more of a matter of tracking the investment required rather than applying a calculation.


what i'm shooting for is to be able to calculate the average investment required. which requires a good formula.

#5263482 Article on Lockstep Multiplayer

Posted by Norman Barrows on 24 November 2015 - 04:46 PM

Then it is not a deterministic lockstep simulation.


oh definitely not. its a way to maintain sync in a game designed with maximum randomness that does not rely on deterministic behavior. and it makes no allowances for cheating. it was used for multiplayer co-op missions in a single player starship flight sim, so cheating wasn't really a consideration.

#5263450 Article on Lockstep Multiplayer

Posted by Norman Barrows on 24 November 2015 - 01:20 PM

when i did the multiplayer version of SIMTrek / SIMSpace i also went with lockstep and fixed update speed. it was necessary for the high degree of accuracy required by a hard core flight sim.


but i handled things a bit differently...


"if every player shares their input with every other player, the simulation can be run on everyone’s machines with identical input to produce identical output"


its only necessary to share relevant state changes with other players to keep all players in sync. input can be processed locally, and just the pertinent results are sent to other



" lockstep is especially attractive to mobile developers because cellular and bluetooth connections can be extremely poor relative to the broadband connections that PC and console developers can generally rely upon."


i wrote my own transfer protocall. its was so robust you could unplug the phone line and plug it back in and the game would keep right on running without missing a beat. so lost packets was a non-issue.  all said, at the end of the day, you can only ACK so many ACKs, then you just have to take it on faith that the packet got through. if it didn't, that's what auto-re-send and auto-re-sync are for.



"The code that drives your game logic must be fully deterministic across all the machines that will play against each other. That is, the machines must run the exact same set of calculations based on the exact same set of inputs and produce the exact same results."


unnecessary if calculations are performed locally, and just the results are transmitted.


" in common with most lockstep games we share checksums of the game state between machines to detect desynchronisation and treat checksum mismatches similarly to network errors by stopping the game and displaying an appropriate message."


with a robust protocall, lost packets go away. by transmitting results, not input, you always get the same results on all machines. with no lost packets and the same results on all machines, you basically can't lose sync, so checksum is unnecessary.


"One of the simplest but often forgotten steps that we took was to organize our code to make it obvious which systems needed to be fully deterministic for lockstep"


by transmitting results, not input, nothing has to be deterministic.


"Right from the start we made sure that our simulation used an independent random number generator from the rest of the game....    ...Obviously, the random number seed used by the simulator needs to be agreed upon by all machines and we did this by generating a seed from a checksum of the shared launch settings.


by transmitting results, nothing has to be deterministic, so separate random number generators with matching seeds for deterministic code sections are unnecessary.


"Floating point numbers can present something of a problem"


if you perform floating point operations locally, then transmit just the results, floats are not an issue. 


"Having decided not to use floating point math, we naturally decided to use fixed point math in its place."


by transmitting results not input, floats are not an issue, so fixed point is unnecessary.


"The main tool we used was that every time we step our simulation forward, we load the previous state, and step forward again. We then compared the two new states we produced and if there are any differences then it indicates a problem in our determinism.  in order to achieve this we wrote code to serialize and deserialize the entire simulation state. "


sending results not input means nothing has to be deterministic, so all this is totally unnecessary when sending results, not input.


"We found it was incredibly valuable to invest the time on code to let the computer run automated matches overnight...    ...our overnight single-player tests caught lots of rare event desync bugs."


sending results over a robust protocall means no loss of sync, so no automated testing required.


"Despite all our care there were a small handful of desync bugs that slipped through the net."


sending results over a robust protocall basically means this can't happen.


"It is invaluable during development to have extensive debug logging, so that if a rare desync occurs you can pinpoint the cause without necessarily needing to repro. Our multiplayer logging in Rapture involved serialising and writing the entire state to a logfile every frame, along with the launch data structure and any input messages. "


with no loss of sync, no debug logging is required.


"We had an interesting bug caused by ambiguous sequencing that looked something like: MyFunction(myRNG.GetRand(), myRNG.GetRand());"


By sending results, this becomes a non-issue.


its encouraging to see someone building a game with lockstep accuracy, as opposed to the typical sloppy prediction BS of non-lockstep. but you might want to consider sending results, and building a more robust transmission pipeline as a way to vastly simplify your life.


by sending results over a robust protocall, all of the following become unnecessary:

1. sending all input to every player

2. deterministic code

3. checking sync by transmitting game state checksums

4. keeping track of deterministic vs non-deterministic code

5. a separate random number generator for the simulation

6. identical seed values for all random number generators.

7. dealing with floating point issues between compilers and platforms

8. avoiding use of floating point

9. use of fixed point

10. serializing / de-serializing the entire game state

11. running update twice to check for sync errors.

12. automated "burn-in" testing for sync errors

13. debug logging of sync errors

14. dealing with different evaluation orders on different compilers / platforms.

#5263319 Communicating with Modelers

Posted by Norman Barrows on 23 November 2015 - 02:20 PM

One example is a door that will be used throughout many of the games levels, in the prototype I created it as two blocks that slide apart and made sure to make it extremely wide (4 times as wide as it is tall) and the example that I gave the artists was also wider than it was tall; however the model that the artists created was more squarish.


you know the scale used by the game, so you should be able to specify the size of all assets required.  IE it helps if you tell them how big the door should be, if that's a constraint.   fortunately, a door should be easy to scale to the correct size.  




but at the same time I'm not sure how to identify these possible issues before they occur


you must clearly spell out all design constraints before modeling begins. even obvious ones like don't add a weapon on the other arm of the mech. artists will take artistic freedoms whenever possible, sometimes in detrimental ways - especially ones with little gamedev related experience.  i've had to deal with experienced artists with little game related experience running amok myself in the past.    adding another weapon does seems a bit much though. bet a dollar they never worked on games before.



you need to make them understand that they are there to build what you tell them to build, the way you tell them to build it, as specified by the game's design, not what they think looks cool. if they can't handle that, get someone who can.

#5263317 Render GUI elements with projection matrix

Posted by Norman Barrows on 23 November 2015 - 02:04 PM

How I need to render it in that case taking into account that I want to convert 3D Zero(0,0,0) in the middle of coordinates to the 2D Zero (0,0) at the left top corner?


you don't - you make it a real 3d gui.


the menus are drawn just like a player weapon in 1pv, always in front of the camera.


mouse clicks are raycasts into the scene that intersect the menu options.


done deal - get a beer.(assuming you're of age <g>)

#5263313 baseline value of items in a RPG

Posted by Norman Barrows on 23 November 2015 - 01:36 PM

time, risk, distance, crafting materials/tools required, skill to make, rareity, profit of middlemen


just thinking aloud here..


no risk - anything can be gotten without much risk, unless you're stupid and hunt lions instead of lambs for meat.


distance just adds more time required.


no parts, just tools and skills for gather-ables.


and no middlemen.


so that leaves time, tools, skills, and rarity for gatherables. 


but what about usefulness? one and two hand hammer stones are identical in time, tools, skills, and rarity. but one is more useful than the other.


that may be supply and demand. supply is the same for both, but the more useful one is higher demand. and thus greater value.


so time, tools, skills, and rarity for gatherables. and time, tools, skills, and parts for craftables. these give you base value - which reflects the supply. then base value is modified by usefulness (demand). to get final price.

#5262957 baseline value of items in a RPG

Posted by Norman Barrows on 20 November 2015 - 07:39 PM

ok, thinking it over here's what i came up with so far:


there are two types of items in the game, stuff you find, and stuff you make.


for stuff you find, the value would be a function of:

tools required

skills required

resource scarcity - basically what % of the map squares in the world have the resource (on average). a number between 0 and 1.

usefulness - a subjective rating, perhaps on a 1-5 or 1-10 scale.

average gathering time required to gather one unit


i was thinking a "hazard pay" modifier would apply for things like meat, but they are available from easy to hunt prey at low risk - so no hazard pay or risk related costs to speak of for anything.


for stuff you make, the value would be a function of

parts required

tools required

skills required

average crafting time to successfully make one unit

usefulness - a subjective rating, perhaps on a 1-5 or 1-10 scale.

scarcity of parts would already be reflected in the base price of the parts.
i've determined that it takes 12.3 hours on average to learn 50 xp in a given skill. so i can assign a time value to skills required.


so i have something better than just made up numbers for everything except the subjective usefulness rating.


the same way you can start in the game with nothing and make or find anything, i can also start in the code with no prices and determine the prices for basic resources first and then for all the things made from them.


so it looks like there will be two formulas or functions for the value of an item, one for gather-ables, and one for craft-ables.


so gather-able value = f(tools,skills,scarcity,gathertime,usefulness)  and craft-able value = f(parts,tools,skills,craftingtime,usefulness)


setting aside the "subjective usefulness" issue for a moment, assume workable values for usefulness can be determined somehow.


what form might these formulas take? 


gather-able value = gathertime*usefulness/scarcity+toolcost+skillcost ?


craft-able value = craftingtime*usefulness+partscost+toolcost+skillcost ?


and then the second question, is there a way around having to assign subjective usefulness values via trial and error?

#5262953 baseline value of items in a RPG

Posted by Norman Barrows on 20 November 2015 - 07:00 PM

neolithic   - I learned recently that one of the seperating attributes between old and new stone age was the presence of the stone tools being 'polished' (which meant more specialization of crafting and a rise of aesthetics).


i suspect new stone age is still paleolithic, not neolithic, i'd have to look it up.  the game has a strict cutoff at the end of the paleolithic. no neolithic allowed. 


actually, it appears to be mostly about keeping the blade from chipping, cracking, or fracturing.  and yes, i do need to lookup polished stone tools and see if they need to be added, or if they're too new. 


i never did understand what good a polished axe head would do until i saw this video:


from raw stone to polished artwork in a handle, and the thing is WICKED BAD against trees!



and people say cavemen weren't smart....

#5262949 baseline value of items in a RPG

Posted by Norman Barrows on 20 November 2015 - 06:46 PM

Are you using a barter system?


yes.    and a form of "currency" as well: trade-able trinkets.




Just curious how you compare two items. Are you calculating this base value, storing it internally against the item and then comparing base values (e.g. "two plucked chickens with a value of 30 equals one hare with a value of 60"?).


that's the basic idea.  the question is "how much should a plucked chicken be worth?". IE the baseline price before any supply/demand modeling.   there's got to be better way than "we'll make a dagger 10 and a sword 50 and see how it goes". yeah, right, like that's a real good plan.




Will the player be able to see these values?


most likely, yes. otherwise one would not have the innate knowledge of the value of things in the game world that their character would normally have.  but things like quality and relations would affect the baseline price when trading.




I'm no expert and don't know if currency was around in neolithic times (I doubt it though?)


paleolithic, not neolithic. neolithic was after the hunter gatherers, when we started to domesticate crops and animals and therefore settle down in one place.


during paleolithic times, the closest thing to currency was probably "trade-able trinkets" such as beads, feathers, shells, etc.  there's evidence of bead manufacturing on an almost industrial scale at one site. so beads are a likely contender. similar to shell money: https://en.wikipedia.org/wiki/Shell_money

#5262948 baseline value of items in a RPG

Posted by Norman Barrows on 20 November 2015 - 06:28 PM

I would start with the food. If you know how much energy (this is something your characters have have, right?) it takes on average to hunt for enough for one typical meal using a common set of resources, then set an arbitrary value for that to use as a base.




well, there's sleep, water, and food like in the sims, and combat fatigue like in skyrim.


but if your talking about energy spent to collect food, that would be food most likely. 


so lets say you can gather 5 food points worth of nuts in the time it takes you to burn 1 food point of energy - more if the nuts are higher quality. 


how do you get from there to how much a nut is worth?

#5262947 baseline value of items in a RPG

Posted by Norman Barrows on 20 November 2015 - 06:08 PM

No matter what, it's going to require play testing and tweaking.


actually, i just got done balancing the hp. xp, meat, bone, hides, and tendon for all animal types with no play testing or tweaking. all the testing and tweaking was done on paper while i came up with formulas relating animal weight to hp, xp, meat, bone, hides, and tendon. once i had the formulas, all i had to do was crunch the numbers for each animal, enter them into the animal types database, and i was done. its only when you "first pass best guess" stuff that you have to futz with it a lot. that's what i hope to avoid here.




you still have to make something up for the time it takes to  harvest an item


historical simulation.  wanna see a youtube video of how to make a stone knife or a stone cutting tool?   gather times  turn out to pretty easy to determine, partly in thanks to experimental archaeology.


making stone knives for survival:



flint knapping an arrow head:




and the equation may need some tweaking so the supply and demand mechanic can't be ruined.
That said, some kind of base cost*demand/supply makes sense, so that demand/supply acts as a modifier to the base cost. If you don't want it to go under the base cost you might say base cost*(1+demand/supply). And maybe something to smooth it out, like the root of 1+demand/supply so it doesn't get too insanely expensive when there's a low supply. 


yes, but first you need a base price. that's what this thread is about - at least to start.  variable supply/demand modeling comes later. not that resource scarcity and item usefulness (a form of supply and demand) don't apply - it seems they definitely do.  but i do have a feeling that formulas of the form you presented will be part of the solution.

#5262932 dealing with a multiplicity of AI states

Posted by Norman Barrows on 20 November 2015 - 04:06 PM

ok, here's a concrete example.


these are the current "rules of behavior" for predators in Caveman 3.0, stuff like saber-tooths and such: 


1. select target: closest detected PC, NPC, or animal of different species.

2. if cornered (surrounded bya combo of terrain and / or other entities), attack.

3. if in collision recovery, do collision recovery

4. if not in collision avoidance and obstacle ahead, go into collision avoidance mode

5. if in collision avoidance mode, avoid collision 

6. if taking incoming missile fire and have a target, attack.

7. if taking incoming missile fire and don't have a target, go into "flee from missile fire of unknown origin" mode <g>.

8. if in "flee from missile fire" mode, flee from missile fire.

9. if half dead and have a target, flee

10. if have a target, and range to target is <= 20 ft (a nearby threat): if the target is stronger, flee - else attack.

11. if not fleeing from nearby campfire, and near a campfire, go into "flee from campfire" mode.   // this is the new rule i just added

12. if in "flee from campfire" mode, flee from campfire    // this is the new rule i just added

13. if fatigued, rest


the above rules are common for all non-avian AI's except for the "maintain distance" AI used by things like proto-horses. the game has 13 types of AI altogether.


the following rules are the ones specific to predators, they are applied after the common AI rules, if no common AI rule has yet been acted upon:


14. if hunting, and there's a carcass nearby, turn to the carcass. if more than a few feet away, run, else stand. once they're standing at the carcass, after a random amount of time, they will "finish eating", which switches them from "hunting" mode to "graze" mode. 

15. if hunting, but no carcass nearby, and have a target, attack.

16. if hunting, but no carcass, and no target, switch from hunting mode to graze mode.

17. do graze mode.  graze mode transitions at random between the following states: stand, wander, flock, and migrate (in the case of a "leader" of a group). after a random amount of time, the animal will "get hungry" and switch to "hunting" mode.


so i have variables for 

target type (animal or human)

target ID number

range to target

"in collision recovery" fag

collision recovery direction (what direction to move to recover)

collision recovery counter   (how many updates they've been in collision recovery)

"in collision avoidance" flag

collision avoidance moveto x  (where they should move to to avoid the collision)

collision avoidance moveto z

"taking missile fire" flag

taking missile fire direction (what direction to run from missile fire of unknown origin)

taking missile fire counter (how many updates they've been running from missile fire of unknown origin)

hit points  (for "is half dead?")

damage   (for "is half dead?")

"fleeing from campfire" flag   (at the moment i'm using the flee from missile fire variables for flee from campfire). 

"flee from campfire" direction   (at the moment i'm using the flee from missile fire variables for flee from campfire). 

"flee from campfire" counter     (at the moment i'm using the flee from missile fire variables for flee from campfire). 
fatigue (for "if fatigued, rest")
"is hunting" flag
graze AI state variable (stand, wander, flock, or migrate)
wander direction  (what direction to wander off in)
wander counter (how many updates they've been wandering)
its was having to add yet another flag, direction, and counter for "flee from campfire" that prompted my original post.
note that a lot of them are the "flag, direction and counter" pattern (so to speak).  with "flag and target x,z" being another "pattern" used.
i suppose i could determine all the mutually exclusive states that use the "flag, direction, and counter" pattern (so to speak), and just use a single flag, direction and counter for them all. that would simplify things somewhat...
basically i'm using rule based decision trees to create "expert systems" for each of the 13 AI types in the game.
is there another approach that's going to be less complicated?
in the past when i've looked at other methods of implementing a set of behavior rules such as the one above, none has really struck me as being simpler or better.
also, a lot  of folks seem to swear by planners. would a planner be appropriate for implementing the above rule set?
if so, how? for some reason, i;ve never quite gotten the idea of how they work.  maybe i just haven't read up enough on them. but the examples i've seen don't really seem to fit well with implementing rule sets like the one above.
a simple example of how a planner would implement even just a couple of the rules would be greatly appreciated.