Randomizing tool breakage?

jasonrohrer · 2018-04-25 17:18:40

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.

Turnipseed · 2018-04-25 17:25:17

Mabey a bit of both.. 1/40 chance of cracking then 1/20 chance of breaking. That way theres only two objects to generate for, but brand new tools wont just shatter. I know this wont remove the problem, but it would simplify things a bit.

Plus if a tool cracks on the first use its kinda like the smith did a poor job making it.

Also getting say "small steel scrap" from broken tools plus axe would be very appriciated, or even being able to remove the handle and reforge the head. As maintenance.

Steel axe>cracked steel axe
Two items with different RNG

Last edited by Turnipseed (2018-04-25 19:19:12)

YAHG · 2018-04-25 17:39:52

You can't store an integer value inside of the tool to simulate its internal hp? If you did it
that way you could have variable wear based on different uses i.e. a berry bush is harder
to dig up than a pie of sheep poo.

Potjeh · 2018-04-25 17:44:22

Are so many different objects and transitions really a must? It'd make more sense to me if objects such as bushes were containers like baskets. Except instead of decaying on update they generate berries. Combined items like froe and boards can be virtual containers that are destroyed when you take out all but one item. So yeah, using shovel on bush should involve one transition on the bush regardless of how many of it's slots are filled because that's how basket decay works. And tools should really track a separate use counter instead of using transitions every time, so this side should also be a single item in the whole bush-shovel interaction.

IDK, I guess I could live with randomized tool breaking if it's really killing the content adding pace, but I'm not a fan of it at all. RNGesus hates me, and I know I'll always lose my axe just when I need to chop one more kindling to make a new one.

YAHG · 2018-04-25 17:55:50

Potjeh wrote:

but I'm not a fan of it at all. RNGesus hates me, and I know I'll always lose my axe just when I need to chop one more kindling to make a new one.

Another cool thing with having internal counters on items that wear down is that you
can combine variable wear with variable initial "hp" you can make an axe for example
have 30+r(20) HP from an adobe forge but perhaps some higher tech forge can make
a nicer axe with 40+r(20) or whatever made sense. You can even limit your transitions
if you wanted to show the wear visibly like you are doing already. Have it use different
sprites for different HP ranges or if you wanted repair you could have it transition to a
worn axe at some point with a lower amount of hp. I assume that you will want items
that have hundreds uses (cars for example) and this multiplying problem of interactions
will only get worse.

jasonrohrer · 2018-04-25 17:58:22

I implemented a bunch of things years ago without internal object HP in mind.

So tracking object HP through a bunch of different code systems would require very deep changes that would likely take me at least a week to implement.

The database would need to change, the map would need to change, container tracking would need to change, etc. This code is complicated. Changing it in a deep way is hard and error-prone.

Also, when a tool changes to a different object through use (like the shovel full of dung), the code needs to handle that case specially (oh, this isn't a brand new shovel full of dung).

The container code is general-purpose and doesn't work for the specific purpose of a berry bush. 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. So I think that the current system works great for those things (auto-generating pond_5, pond_4, etc., and drawing different sprites for each).

It makes way less sense to leverage this system for something with 40 uses like an ax.

breezeknight · 2018-04-25 18:05:50

the breakage like with UncleGus' mod sounds ok to me

one could maybe include a minimum breakage number, like after 3 uses first

other than that, since objects with many possible uses are usually used in a settlement not only by one person but by many so if i use it i never know if it was already used that many times to break with my use already

to make all that less breakeable you could also up the number of final breakage for every object by 50%, this would enlarge the pool of possible breakage for any tool & make it this way seem less random

YAHG · 2018-04-25 18:11:43

breezeknight wrote:

to make all that less breakeable you could also up the number of final breakage for every object by 50%, this would enlarge the pool of possible breakage for any tool & make it this way seem less random

Could you explain this more? I don't understand this idea.

breezeknight · 2018-04-25 18:19:51

YAHG wrote:

breezeknight wrote:
to make all that less breakeable you could also up the number of final breakage for every object by 50%, this would enlarge the pool of possible breakage for any tool & make it this way seem less random
Could you explain this more? I don't understand this idea.

a shovel would be used instead of 40 times now 60 tops
it could still break already with the 20th use but the probability to break soon within the initial 40 uses would be diluted because the pool to choose random the breakage would be bigger, namely 60

if 50% sounds too big, one could extend it to a lower number, 25%, in the case of the shovel it would be then a pool of 50 uses to break sometime inbetween

- - -

Last edited by breezeknight (2018-04-25 18:20:13)

YAHG · 2018-04-25 18:25:13

breezeknight wrote:

YAHG wrote:
*snip*

a shovel would be used instead of 40 times now 60 tops
it could still break already with the 20th use but the probability to break soon within the initial 40 uses would be diluted because the pool to choose random the breakage would be bigger, namely 60
if 50% sounds too big, one could extend it to a lower number, 25%, in the case of the shovel it would be then a pool of 50 uses to break sometime inbetween

- - -

Cool yeah Thanks, I think is a good way, like a mix of the two. Pure randomness can sometimes be
just too cruel, knowing you can use it at least a FEW times is nice and getting that lucky long
life tool is also fun. I think that variable wear is nice side feature that this strat makes easy
to implement too which is another bonus.

Lily · 2018-04-25 18:26:51

I would split the difference. Make say 3 versions of a shovel, and give each a 5% chance to move to next step. So shovel 1 has 5% chance to become shovel 2, shovel 2 has 5% chance to become shovel 3, and shovel 3 has 5% chance to become a broken shovel. You can set the percentage to whatever you want but your guaranteed to have at least 3 uses before it breaks. Getting a few extra uses isn't a big deal but having a tool break on the first use would be extremely frustrating. So we rule that out. It adds a bit more to the database, but 3 shovels is way better than 40.

ryanb · 2018-04-25 18:29:03

I like the idea of randomized tool breaking, but perhaps make it possible to repair a broken tool to soften the blow of bad luck. Repairing could be time-sensitive: if a broken tool stays around too long it decays into an unrepairable tool.

Thorware · 2018-04-25 18:29:43

As a fellow programmer, it's clear that your combination explosion problem is merely a symptom of a pretty dirty hack. A shovel with uses is clearly an object with a property, not a long series of different objects. The more logical/consistent/simple your object representations, the easier they will be to update and maintain in the future. For this reason, my recommendation is to bite the bullet and go deep to add object properties to the game engine.

I'm surprised you say this will only take a week. I could imagine it taking a month. Obviously this is a disaster in terms of keeping the game engaging for a young player base. And once you finish all of that work, there will be nothing new for users to play with, and there will likely even be some new bugs to frustrate them. Yuck.

On the other hand, committing to hacks leads to more and more hacks in the future. A tangled web of hacks slows development way down. If you intend to develop the game over years, improving the engine is the clear long term time saver.

Another approach could be to simply declare "Objects will never have properties." Then revert and refuse all features that require them, including the item decay counter. Your suggestion of randomized item breaking is simply your own tech backing you into a design corner. If you want the game to be feature-rich, updated every week, then design decisions need to be as frictionless as possible, and these sort of problems are big red flags.

But imagine the design space opened up if you can assign properties to objects? You will be able to create much more dynamic objects, leading to a richer and more compelling game.

It's your call, obviously, and frankly it's a decision I'm glad I'm not the one to have to make.

KucheKlizma · 2018-04-25 18:34:29

I think the full use count is the way - either way having this type of thing working can come in handy for other features in the future as well. But this looks like a problem.

Unfortunately I haven't really read the source code of the game...
Shouldn't there be much better ways to pass a variable between transitions without creating a million dummies for each possible state or am I missing something?

breezeknight · 2018-04-25 18:44:09

btw about breakage of manufactured things & RL

we live in complex progressive societies, it took quite a long time to protect the consumer from a random quality of production of things
people have for thousands of years to put up with random quality of manufactured things, which could then indeed break already with the first use
first at the end of the 18th century, actually mostly first in the 20th century, have people started to develop what is today known as the NORM & the standard, we have now things of comparable minimum quality not because that's how reality is but because people have introduced institutions of minimal norms protected by law

- - -

Last edited by breezeknight (2018-04-25 18:44:58)

Potjeh · 2018-04-25 18:50:02

Yeah, I don't really see the content getting far if interactions are straitjacked by objects having no variable properties.

protein · 2018-04-25 19:01:08

If you have the timestamp that the object was created at, you could make the probability of breakage a function of the object's age. That would solve the problem of breaking on first use.

jasonrohrer · 2018-04-25 19:05:35

Thoreware, yes it is a hack.

The core abstraction in this game is (a + b = c + d) crafting. That's what makes all the deep interactions possible, makes crafting learnable through observation, and so on. It's the beating heart of the game, and this model can cover almost everything you can think of.

However, it runs aground in several situations. Containers are one, so I added containers. Multi-use objects are another. The pickable berry bush is the most basic example of this.

A "property system" sounds really complicated to me. It sounds like a siren song that promises to simulate everything. It's not really needed for most things, and my YAGNI instinct warns me against it. Like, if a fire extinguisher puts out a fire, I'm tempted to define a "smothering" property, and give the extinguisher that property, and then maybe also add a fire blanket with a smaller quantity of that property (smothering=2 instead of 4), but getting the blanket wet will push smothering up to 3. But YAGNI. Just have the fire extinguisher put out the fire. You don't need to code a whole system for this.

I've seen people go down this path, with over-specialization of the code, and it becomes a mess anyway. It IS a mess, there's no way around that, but you need to decide where to put the mess. I think that the mess should usually be in the data.

Except in some rare situations where the data solution becomes intractable. Containers are one example of this. Object use counters may be another.

jasonrohrer · 2018-04-25 19:06:52

Potjeh, what variable properties to you envision being necessary?

jasonrohrer · 2018-04-25 19:12:31

protein wrote:

If you have the timestamp that the object was created at, you could make the probability of breakage a function of the object's age. That would solve the problem of breaking on first use.

Yes, I thought about this.

That is a relatively simple server-side solution, though it requires tracking of this creation time as the object is moved around (picked up, put down, put in container, etc.) If all that code is changed, might as well be tracking a use counter directly, right?

Also, it's not clear when an object counts as being "created." Some things get modified, and as far as the server is concerned, they are new objects. Like the shovel of dung. It's a different object than the shovel. It works differently than the shovel (it cannot be used to dig up a rock.... it can only be used to dump the dung). So we'd need to know that the dung shovel isn't a "new" object, and we'd need to preserve the old creation timestamp (of the shovel) through this transition.

kubassa · 2018-04-25 19:13:13

Please no RNG.

Potjeh · 2018-04-25 19:42:04

You are not using a shovel of dung, though, you are using just the dung. The shovel is just the container that's required to transfer the dung. You can preserve the same dung object from the moment it's created to the moment it's consumed. Interactions requiring empty shovel simply check if the shovel isn't currently containing anything. Seems simpler for adding future shovel recipes too, for example you might need a shovel to transfer coal into a boiler, or wet concrete from concrete mixer to stakes.

As for which properties are required, that's not the sort of thing that you can fully plan out ahead, just add as needed. That doesn't mean you can't be thrifty with properties, but when one is going to make the game simpler to maintain why not add it? All these cases we're discussing could be covered by a float "Condition", which as a bonus would also let some actions cause more wear on tool than others (chopping a tree vs chopping kindling for example). Is there a significant reason why object size has to stay fixed? Some fancy pointer arithmetic optimizations?

Thorware · 2018-04-25 19:42:34

If (a + b = c + d) is a core abstraction for design reasons, then features ought to stay true to this vision, and features that do not fit it (such as item decay) should be rejected. Even containers and berry bushes seem to assault this fundamental vision.

Which shall be the authority? An idealistic fundamental founding principle of the game, or your own freedom of design creativity? This is a decision you must make, and it seems that you keep pushing toward the later while clinging to the former.

Object properties are so useful and versatile in general that I am surprised you are worried you may find little use for them. I can't tell you how exactly they could be used because I don't know what kinds of features you plan for the future, I only know that object properties tend to be very useful in games I have developed, and you have already run up against one spot where they would be useful: item uses remaining.

Certainly the inclusion of object properties does not promise to "simulate everything." It is only a useful tool. What it simulates or promises is up to design. Don't feel like just because it's available that you have to use it for everything.

Properties would be implemented as name-value pairs. The values could just be integers. This would provide plenty of design freedom. However I understand that the use and propagation of these pairs would add much more complexity to the transition engine. One could imagine something like a scripting system getting involved. I understand why this is daunting and unappealing, especially if you don't see a clear use for it in the future.

You mention over-specialization of code and prefer the "mess" (complexity) to be in data. I agree completely. I am suggesting a generic system that would be taken advantage of only in data. A generic property system is less specialized and more reusable than an "object use counter" which is way more specialized and could instead by nestled inside the generic property feature.

If your instincts reject this approach, you know best. I just wanted to share my thoughts.

KucheKlizma · 2018-04-25 20:00:24

jasonrohrer wrote:

Potjeh, what variable properties to you envision being necessary?

It's quite apparently badly needed for the decay system, or at least I don't understand how spawning potentially infinite dummy objects for the sake of one variable changing over time is a good long-term idea.

Also what if you decide to make the system more complicated in the future for the sake of new crafting mechanics.
You could have decaying object holding a decaying object, interacting with decaying object holding a decaying object (or other variable state). Then what happens?

Let's say basket of soil could interact with basket with soil & that soil also becomes decaying - how will that auto-generate the transitions:

Here's one of many:
(Basket_37+Soil_56) + (Basket_27+Soil_52) =

Last edited by KucheKlizma (2018-04-25 20:06:13)

ryanb · 2018-04-25 20:08:43

jasonrohrer wrote:

The core abstraction in this game is (a + b = c + d) crafting. That's what makes all the deep interactions possible, makes crafting learnable through observation, and so on. It's the beating heart of the game, and this model can cover almost everything you can think of.

A side note: the simplicity of the crafting system is what makes automated tools like onetech possible. The more logic which is added to transitions, the more difficult tools like this will be to create.

This shouldn't be a factor in the game's design, but it goes to show how a simple design can be used in interesting ways.

One Hour One Life Forums

#1 2018-04-25 17:18:40

Randomizing tool breakage?

#2 2018-04-25 17:25:17

Re: Randomizing tool breakage?

#3 2018-04-25 17:39:52

Re: Randomizing tool breakage?

#4 2018-04-25 17:44:22

Re: Randomizing tool breakage?

#5 2018-04-25 17:55:50

Re: Randomizing tool breakage?

#6 2018-04-25 17:58:22

Re: Randomizing tool breakage?

#7 2018-04-25 18:05:50

Re: Randomizing tool breakage?

#8 2018-04-25 18:11:43

Re: Randomizing tool breakage?

#9 2018-04-25 18:19:51

Re: Randomizing tool breakage?

#10 2018-04-25 18:25:13

Re: Randomizing tool breakage?

#11 2018-04-25 18:26:51

Re: Randomizing tool breakage?

#12 2018-04-25 18:29:03

Re: Randomizing tool breakage?

#13 2018-04-25 18:29:43

Re: Randomizing tool breakage?

#14 2018-04-25 18:34:29

Re: Randomizing tool breakage?

#15 2018-04-25 18:44:09

Re: Randomizing tool breakage?

#16 2018-04-25 18:50:02

Re: Randomizing tool breakage?

#17 2018-04-25 19:01:08

Re: Randomizing tool breakage?

#18 2018-04-25 19:05:35

Re: Randomizing tool breakage?

#19 2018-04-25 19:06:52

Re: Randomizing tool breakage?

#20 2018-04-25 19:12:31

Re: Randomizing tool breakage?

#21 2018-04-25 19:13:13

Re: Randomizing tool breakage?

#22 2018-04-25 19:42:04

Re: Randomizing tool breakage?

#23 2018-04-25 19:42:34

Re: Randomizing tool breakage?

#24 2018-04-25 20:00:24

Re: Randomizing tool breakage?

#25 2018-04-25 20:08:43

Re: Randomizing tool breakage?

Board footer