Randomizing tool breakage?

pein · 2018-04-26 06:21:41

i wouldnt like lotto mode on items, a new axe should last a while then become older and then i would be okay with few less or more hits, or critical results which would make great axeheads which can last more

hp sounds much better, and the customization of it
but not most important currently

i really would like more viable routes to play, some people like higher population, more agriculture based, help them in cost of something else, like god statue to pray to. they would give some bonus to carrots, faster grow, more seed, but other gods would give bonus to forging, like fire lasts longer, iron cools down faster, this would give a bonus zone but would not allow other god statue in the biome/radius of 50 tiles?
even more crops implemented would shake up gameplay
or fixing wells, or more art

Christoffer · 2018-04-26 09:44:10

Flintstone wrote:

tldr: using 2 or 3 stages for an item to break or decay gives an element of chance combined with a nice probability curve

Back with graphs here.

The curves show probability for a new item to remain unbroken until its x'th use and then break (x-axis: 1 to 100, y-axis: 0% to 2.5%). The average number of uses before break is around 40 for all the curves.
Blue: Item (1/40)=> broken
Red:. Item (1/20)=> Stage1 (1/20)=> broken
Green: Item (1/13)=> Stage1 (1/13)=> Stage2 (1/13)=> broken
Orange: Item (1/10)=> Stage1 (1/10)=> Stage2 (1/10)=> Stage3 (1/10)=> broken

Personally I think the Green curve looks like a sweet spot. Adding more than 2 extra stages yields diminishing returns.

zed · 2018-04-26 11:00:51

I don't think repurposing the containers system wouldn't have to be a hack
exactly.

What I really mean is: you already have a concept of an object coming with a
list of subobjects. The map storage and protocol already handle this. I see
the protocol only allows nesting of depth 2, but I guess this could be fixed
relatively painlessly.

Containers are one purpose this concept of subobject can be used for.
Properties like agedness could be another.

It would indeed mean complicating the transitions system, so transitions are
able to be conditioned on and to adjust subobjects. It would definitely be
uglier than A+B-->C+D.

The downside of the current system is that you'll have keep the use numbers
low when there are interactions - 20*7 might be manageable, but I guess
1000*1000 would be problematic.

Actually, how about this as a completely different approach which would
linearise that quadratic factor.

Add a new kind of transition outcome, an "action". e.g.
shovel_38 -> shovel_37 + dig_action

Allow actions as inputs of transitions:
dig_action + bush_5 -> dug_bush_5

Then when checking for whether a transition applies, as well as looking for
direct transitions, search also for chains of transitions going via actions.

This could replace many of the categories, and would help with hints -
currently category transitions generate a hint for each instance of a
category, which would be overwhelming if you have many tools all able to
trigger a certain transition. This would replace those hints with a single
hint naming the action.

Potjeh · 2018-04-26 11:48:14

Uhm, all you need is to modify the formula to T(a) + b = T + d. That is, a tool contains a number of virtual items which represent tool uses. When you use an axe on a tree the axe doesn't actually get transmuted, it just delivers an axe use item to the tree, which is consumed in the transmutation and the only output is the chopped tree. True, this only covers cases where you use a tool on an item on the ground and the item gets modified there while the tool remains in the hand. But that is the vast majority of tool use scenarios, and RNG on the subset of tools that combine into the transition (like froe or chisel) wouldn't be as bad as RNG on all tools.

Glassius · 2018-04-26 14:55:09

jasonrohrer wrote:

You don't want people sticking things into the bush (like stones or dead rabbits). Also, there are other things, like the draining pond, which is really nothing like a container

Why not? Why not hide knife in the bush? Why not pollute water with all this beautiful dung we put so much effort to produce?

Artarda · 2018-04-26 22:48:27

jasonrohrer wrote:

Tool breakage is currently implemented with a use counter. An ax has 40 uses, for example. After chopping 40 trees, it breaks.
This works well and makes sense.
However, the implementation is complicated and causing some bugs. First of all, this use count has to "follow" the ax object everywhere it goes. On the ground, into a basket, in you hand, into a basket in a cart, etc. For some objects that get transformed during use (like a shovel, which becomes a shovel full of dung), it gets even more complicated, as the number of uses remaining has to transfer between objects (a dung shovel is a different object with a different name and different sprites).
This is currently implemented by automatically making a bunch of unique dummy objects for each multi-use object. Auto-generation of ax_1, ax_2, ax_3, ax_4, .... ax_40. These actually exist in the game engine as distinct objects with distinct IDs, though they are automatically generated from the ax. Thus, an ax_15 can exist on the map, or get picked up, or put in a cart, etc, and always be an ax_15.
The problem comes in the transition engine, where we have stuff like
ax + tree = ax + firewood
We now have 40 extra ax objects floating around, and that means we need to auto-generate 40 transitions like this:
ax_40 + tree = ax_39 + firewood
ax_39 + tree = ax_38 + firewood
ax_38 + tree = ax_37 + firewood
...
So now we have 40 extra transitions to track and manage. Complicated, but it works.
The bigger problem arises when we want to use a useCount object on another useCount object. For example, a shovel can be used 20 times, and be used to dig up a berry bush, which can be used 7 times as you pick the berries. So we have these generated objects:
shovel_1, shovel_2, shovel_3, ... shovel_20
bush_1, bush_2, ... bush_7
But if each of those shovels needs to be used on each of those berry bushes, we suddenly get a pretty bad explosion of 140 generated transitions:
shovel_ 2 + bush_7 = shovel_1 + dug_bush 
shovel_ 3 + bush_7 = shovel_2 + dug_bush 
shovel_ 4 + bush_7 = shovel_3 + dug_bush
....
shovel_ 2 + bush_6 = shovel_1 + dug_bush 
shovel_ 3 + bush_6 = shovel_2 + dug_bush 
shovel_ 4 + bush_6 = shovel_3 + dug_bush
The game engine currently does NOT generate such double-useCount transitions correctly, because it doesn't run through the generation process twice. The code could be fixed, but the problem of an explosion in complexity still remains. Lots of extra generated objects and transitions, a more crowded object address space, and so on. If a 100-use object (someday) is ever used on a 100-use target, we're looking at 10,000 generated transitions.
The other option is to track the use count separately from the object ID. So, all axes would have the same ID, but there would be this extra counter that would travel along with it. That's a pretty deep change, since this counter would have to be tracked in the map database, in container slots, in the player (for what they are holding), in the protocol, etc.
The client would need to know about the use counter in some cases as well (for example, berry bushes are drawn with fewer and fewer berries as they are used up). Thus, it seems like separate objects make sense in some cases (like a berry bush or a draining pond).

But the question is this: are separate objects the best way to track and represent tools wearing out with use?

Maybe tools wearing out should work differently than berry bushes getting picked and ponds getting drained and pie bites getting eaten.

What if every tool simply had a small chance of breaking with each use? This is UncleGus' method in his mod.

If we want an ax to have 40 uses, on average, we give it a 1/40 chance of breaking with each use. Some axes break sooner, others later, but on average, they break after 40 uses.
We no longer need to track anything along with the ax, nor do we have to have separate states or dummy objects for the ax. An ax is an ax, with some chance of breaking, always. No extra objects to generate.
And for the cases where we NEED to generate extra objects (like the berry bush getting picked), we can still do that.
But when a tool gets used on a berry bush, we don't have an explosion of generated transitions. Just one transition for that tool per generated bush (bush_7, bush_6, bush_5, etc.)

Now, the problem with randomized tool breakage.... is that it's random!
Sometimes, very rarely, a tool will break on its first usage. Sometimes, equally rarely, a tool will last twice as long as the average. But having a "good" tool like this does not mean it will continue being good in the future. It has the same chance of breaking on the next use as any other tool.
This doesn't exactly match how things work in real life, and it creates a weird feeling. None of the rest of the game is random. There's a sort of press-your-luck gambling feel. Chopping one more tree, hoping to get lucky...

But it is oh-so-simple. Simple to implement, test, maintain, and tweak. No bugs due to complexity or unexpected side-effects.

Is there a way to prevent a tool from breaking on its first few uses? Not without some kind of extra tracking per-item. If we're tracking that anyway, might as well track a full use count.

Short answer: Pull a Diablo II.

Long answer:
Assuming all items in the game have a generic Class, could you rewrite the item code to have a generic byte, short, int or uint called "data". I mean even if your server needed to track a million additional 32 bit ints, thats theoretically only 4MB more of data, metadata not included. Lowering this down to a byte would only be 1MB of data for a million items, that would theoretically give every decayable item the ability to have 0-255 uses. This data could also be used for other things, like tracking food rot timing, basket decay, and other stuff.

The generic "data" just stores the number, and the number could be interpreted through a Case Switch or If statements or whatever choice you prefer.

I called it "pulling a diablo II" Because if you look at how they store their data for their weapons, armors, etc., it's all stored on generic data fields which are interpreted in runtime.

So this "data" variable might be how many uses are left on your tools, how many update time periods are left until it decays, or even other sorts of data could be tracked with diligent use... maybe the direction a compass is pointing in the future?

Make it at least have a public Get Accessor that can be reached by your draw code, so that the game can determine from "Ax" whether it wants to draw "Ax","Ax_Damaged", "Ax_Broken" etc...

This is of course assuming that all items are instances of an item themselves and not a pointer to a generic type of item. If your current system doesn't allow individual items to carry data for one reason or another, right now might be the perfect time to rewrite that code, so that the infrastructure is in place in the future.

Some pseudo code might be

// some sort on interaction code, never looked at it...
If(Ax.data >0) // the transition engine needs to check to make sure the item has remaining uses.
{
Ax + tree = Ax + ChoppedTree#FireWood,Log
Ax.data--; // the transition engine tells the item to reduce it's remaining uses by one. This can be changed by other things, e.g. a shovel digging a Big Rock
// might take 3 uses where as shoveling a Sheep dung might only require one use.
}
//...
//...
//Some pseudo Draw Code
graphics = texture we're gonna draw;
if(Ax.data ==  40) /*Pristine condition axe */ graphics=ax.tga
If(Ax.data < 40) /*worn*/ ...
...
...
if(Ax.data == 0) //broken

I feel like this would be better than relying on a bunch of preset copies like Shovel_30 and Axe_20 or whatever the current system is, and It probably wouldn't even become much of a problem until you got into the tens of millions of items per server. Probably. Also, you could build off this structure in the future due to items becoming more complex as the game gets more complex and the tech tree deepens.

I mean, imagine when you hit the industrial era. A steam engine should be able to keep track of how much fuel it has, or when we get titanium steel alloy shovels with 100 uses instead of 20! Sarcasm aside, I'm not sure how your databases would handle it server side, but it shouldn't be too hard for it to keep track of an extra byte or two per item, right?

Adding item decay means that one Ax needs to behave differently from another Ax. Plus, this would allow you to keep your transition code cleaner.

About the transition Engine:

Instead of all those different transitions, could you just have the transition engine pass a new "use" update to any surviving tools involved? So that the tool would be able to do some internal data adjustments to do the

Last edited by Artarda (2018-04-26 23:00:00)

Uncle Gus · 2018-04-27 00:50:06

That's a rewrite of almost the entire engine.

Xuhybrid · 2018-04-27 02:28:01

I am not sure why any engine limitation would limit the ability to store meta data along with an item?

['Axe', 40] - Name, Uses

Obviously i'm using an array object but a class would provide the same function.

new Axe
Axe.uses = 40

Edit: After reading more of the thread and reading about transitions, where A+B=C+D would it not be an easy solution to have A+B=A+D? In fact C just equals A with one of it's properties changed. You should be able to alter the functionality fairly trivially by extending a class for example.

Last edited by Xuhybrid (2018-04-27 02:51:52)

Potjeh · 2018-04-27 15:25:56

Yeah, it'd take expanding to a set of formulas:
A + B = C + D
A + B = A + D
A + B = C + B
That is, you need a transmute flag for both components in a recipe function. IMO the three formulas are still pretty managable on the user end as they're probably more intuitive to your average layman (it's natural to believe that the ax in your hand after chopping a tree is still the same ax from before chopping). But it could be creating complications on the server end, IDK.

earthling · 2018-04-27 16:04:14

I realy do not understand a lot. But i am looking forward to

One Hour One Life Forums

#51 2018-04-26 06:21:41

Re: Randomizing tool breakage?

#52 2018-04-26 09:44:10

Re: Randomizing tool breakage?

#53 2018-04-26 11:00:51

Re: Randomizing tool breakage?

#54 2018-04-26 11:48:14

Re: Randomizing tool breakage?

#55 2018-04-26 14:55:09

Re: Randomizing tool breakage?

#56 2018-04-26 22:48:27

Re: Randomizing tool breakage?

#57 2018-04-27 00:50:06

Re: Randomizing tool breakage?

#58 2018-04-27 02:28:01

Re: Randomizing tool breakage?

#59 2018-04-27 15:25:56

Re: Randomizing tool breakage?

#60 2018-04-27 16:04:14

Re: Randomizing tool breakage?

Board footer