Randomizing tool breakage?

jasonrohrer · 2018-04-25 20:21:43

KucheKlizma, object properties doesn't solve this problem.

You would still need to figure out which property is preserved during the transition and which one is discarded.

ThoreWare, just adding name-value pairs to objects does nothing unless the underlying engine does something with those names and values. Even use counters requires specialized code. It's not just gotten "for free" by adding an object property system.

So, yes, as you say, it would need to be added to the transition engine. But how does the transition engine make use of these properties? If A + B = C + D, but A has some property (salt_content=20), how does that change A + B = C + D? The simplest thing would be to add a threshold specification for the transition to apply. A + B = C + D only applies if salt_content of A is > 15. Oh, but wouldn't we also want the salt_content property to transfer into C or D as well? There'd need to be some interface for specifying how the input properties are routed to the outputs.

Uncle Gus · 2018-04-25 20:40:14

Having already implemented this solution in my mod, I can tell you it is very simple and it works. As for the main concern around things breaking on first use, when things break in my mod, if they break outright, then they are easily replaced and there are more durable tools that can perform the same task, or they don't break completely but instead become unusable until they are restored. An example of the first category: sharp stone, has a 1 in 10 chance to break completely, but all of its uses can be performed with a kinfe or chisel, so once you have those, you don't need sharp stones any more, and until you do, there are plenty of them around. An example of the second category is the cast copper ax, which has a more than 50% chance to "break", but when it does, it goes blunt and can be sharpened with a whetstone or file. This is the same for all of the tools, but better quality tools blunt less frequently. When you sharpen the tool, then there is a chance for it to break completely, and there is also a chance for the sharpening tool to break as well, so things do eventually run out, but it's not so sudden. And when metal tools do break completely, you can salvage some of the metal and re-use it.

Summary of that paragraph is that RNG doesn't have to be completely brutal. There are ways to soften the blow, so don't consider the current tool life cycle and just chuck RNG in the mix.

On to the deeper issues: having any kind of randomness in transitions is a HUGE paradigm shift. I did it because it was simple and I can do what I want when I'm not the guy with the thousands of players to keep happy. Personally I think it works, but it is a very different play style. I'm not sure it is the best approach for the base game. Before implementing it, you should actually assess the impact of just using the current system. Is it really so bad to have an extra thousand transitions in memory? How does it affect performance? Is the cost just a little extra RAM? If so, isn't that acceptable?

Maybe you could spin up a branch implementing the second transition generation cycle with some high-use objects and transitions and deploy it to a new server and get some playtesting going on to see what the figures are. I think that would help make an informed decions before doing anything rash.

jasonrohrer · 2018-04-25 20:45:51

Something else I just thought about:

In terms of the core representation, which is currently a unique integer ID for each "unique" object state...

Like maybe the ax is ID 503, and it has 40 uses, which are auto-added at start-up above all existing IDs, so maybe we get 1021, 1022, 1023, ... 1061 for the various use stages of the ax.

If the ax was instead a single ID with an extra property (or a whole raft of properties) that went along with it, we'd essentially have
503,1
503,2
503,3
...
503,40

I don't see how this is fundamentally different from, or really any way better than, 1021, 1022, etc. We're essentially just shifting the bits into a different field, but the bits are still there. We need them.

The same logic is needed too... transitions must pay attention to the value that goes along with 503 and decrement it. Or a transition can know that a 1022 becomes a 1021. It's the same logic, just in a different place.

The only thing that's "wasted" in the hack approach is memory space, because extra transitions are generated, and also extra dummy objects. We're essentially trading RAM for code complexity.

Each transition occupies 45 bytes or so. We can store 2 million of them in 100 MiB of RAM.

Objects use quite a bit more space, 320 static bytes, and then some dynamic bytes depending on the nature of the objects (an array of sprites, the object description, etc).

Still, extra objects are not subject to the same combinatoric explosion as transitions, so there won't be as many of them. 40 axes, etc.

Also, given that these "dummy" objects are identical copies of their parent, there may some space savings by simply keeping a pointer to the parent instead of a fully copy.

But none of this changes what's happening on the map or in the protocol. In fact, assuming that we don't exhaust the 32-bit integer space with dummy objects, the current implementation is the most efficient in that regard.

Instead of passing around or storing pairs of integers for each object, we are passing around a single integer that fully represents that object.

Atticus · 2018-04-25 20:51:47

Could we have two separate outcomes?

a) There is a 3% chance that steel ax become steel ax with broken handle. Once we pick it up we can remove the handle and replace it.

b) There is a 0.5% chance steel ax is broken for good and can't be repaired.

AND/OR

The item the tool is used on determines the chance of getting broken.

a) Steel ax that is used on branches has 1% chance to break. (While it is 2.5% for stone hatched)
b) Steel ax that is used to cut down a tree has 3% chance to break.

This can also be a universal function of hardness (or any other property) of the item vs the material the tool is made. (Yay more complexity!)

Last edited by Atticus (2018-04-25 20:53:31)

ryanb · 2018-04-25 20:51:59

I think hidden properties take away from the game since they are not graphically visible. When you have perfect information you can accurately make decisions based on what is around you. This is generally the case throughout the game and I love it.

However there is some hidden information: wells, tools breaking, and even decay time. These are all variable states which are not visible to the player and therefore pollute one's ability to make a decision. Please don't move further in that direction.

jasonrohrer · 2018-04-25 20:52:09

Also, I tested running the transition-generation loops twice, and it does seem to fix the problems with the shovel and the shears.

This is probably one of those things that I can deal with if it ever becomes a serious performance problem. Right now, the server is using something like 16 MB of RAM to host 100 players...

Uncle Gus · 2018-04-25 20:54:37

jasonrohrer wrote:

Also, given that these "dummy" objects are identical copies of their parent, there may some space savings by simply keeping a pointer to the parent instead of a fully copy.

This.

Problem: "transition explosion! more memory used!"
Solution: "so what?"

jasonrohrer · 2018-04-25 20:56:49

ryanb wrote:

However there is some hidden information: wells, tools breaking, and even decay time. These are all variable states which are not visible to the player and therefore pollute one's ability to make a decision. Please don't move further in that direction.

All the breaking tools show wear marks half-way through their lives.

I'm still experimenting with this, and I may add more wear marks to make it even more clear. Kinda like picking carrots. Hidden information made visible through sprite changes.

The well is a special case where there is no visible change at all. But well.... it's a well, folks! A deep hole in the ground.

As for decay times, I'm not sure how that could be fixed in a sensible way. It does make sense that a baby sheep takes some time to grow up, right? Or that a plant takes time to grow?

I suppose there could be a UI that gives you an ETA when you mouse over something.

Uncle Gus · 2018-04-25 21:04:44

One advantage (in my opinion it's an advantage) about the RNG is that you can't predict exactly when things will break. You can plan based on averages, but there will always be variation. I say this is an advantage because there are players like myself who always math things out. I mean, look at the very early days. Remember "three to feed, one to seed"? All mathed out. You end up working out a perfect formula that you redo every time. At first this is quite satisfying, because you feel like you've "cracked it", but it gets very boring after a while. One way to combat this is to constantly change everything (which seems to work just fine for you, Jason ^_^ ) or to have some things unpredictable, like RNG. For me, it liberates me from the mental burden of "how many times have I used this? I need three axes to keep my forge going for seventeen minutes, bla bla bla". When I play my mod, I just do things.

I think it's okay to have some hidden information.

Potjeh · 2018-04-25 21:22:42

a + b = c + d is an elegant design, but there is no place for object permanency in this paradigm. So the very concept of limited number of uses doesn't fit in, and should be scrapped if you're going to be faithful to the original vision.

jasonrohrer · 2018-04-25 21:30:42

Yeah, randomization also makes for drama and more interesting stories. Known quantities do not.

"I used my ax 19 times and then made a new one before the old one broke. Then I used the new ax 19 times and made a new one right before it broke." That's not a very interesting story.

"I had three backup axes, and this one time, they all broke after one chop each, by chance, and then I was stuck making a stone hatchet again to bootstrap my forge with kindling." That is a much more interesting story.

Poker is a way better spectation event than chess.

I do, in general, like randomness in the games that I play.

I do not, in general, put randomness in the games that I make.

These systems could be combined somehow....

I mean, I still need fixed, non-random usages for things like berry bushes and carrot rows. A bush that looks like it contains 7 berries should give you 7 berries (though it could be argued that the bushes should have a random number of berries to begin with).

But 40 uses for the ax seems like a lot of dummy objects, and is beyond the scope of what that system was intended to support.

Maybe there can be 4 uses for the ax, and then a random chance of advancing to the next usage. For the berry bush, this random chance would be 1 (picking a berry always picks a berry). For an ax, this could be 1/10, meaning that you could use the ax 10 times, on average, before it would advance to the next usage state. And, with the worst luck in the world, you could still use the ax 4 times.

jasonrohrer · 2018-04-25 21:38:50

Potjeh wrote:

a + b = c + d is an elegant design, but there is no place for object permanency in this paradigm. So the very concept of limited number of uses doesn't fit in, and should be scrapped if you're going to be faithful to the original vision.

How would a berry bush work in this context?

There are four options:

1. Berry bush is infinite and always gives a berry

2. Berry bush gives one berry and then becomes empty forever.

3. Berry bush gives one berry, but then leverages the decay system (a reasonable modification to A + B = C + D where A is a timespan instead of an object---that has been in my model since the very beginning) to grow another berry after 30 seconds or whatever.

4. Berry bush is actually 7 hand-made objects, and taking a berry is a transition that takes you to the next more-empty bush, eventually getting you to the empty bush.

I originally envisioned that all "multi-use" things would be simulated using 4. I got kinda sick of duplicating objects by hand, though, so I wrote a piece of code to do this for me. Thus, the underlying model of A + B = C + D is still preserved by the way that "useCounts" are currently implemented. There are 7 berry bushes in the game, in fact.

akoopatroop · 2018-04-25 21:47:37

stump_fertile, ax_40, shovel_cracked are all pretty usefully thought of as properties. Sure, you can worry about the YAGNI of property explosion, but just . . . don't explode the properties until you're sure you need them.

You already are using properties, just in a painful way.

[ETA] It introduces another crafting function, yes. But still pretty elegant.

a + b = c + lambda x: x.use-1

Last edited by akoopatroop (2018-04-25 21:49:07)

Uncle Gus · 2018-04-25 21:52:12

No he's not. Each use number is a separate object. The server has no concept of uses. The server gets a message from a client "I used object 846 on 36", it looks up the recipe "846 on 36 produces 847 and 49" and makes the changes. That's it. A + B = C + D.

protein · 2018-04-25 21:55:32

What about a simple modification where A + B = C + D with probability p OR C + E with probability (1-p)? Hopefully it's not too difficult a modification to your existing system. Then you can do all sorts of interesting branching based on chance. Also if you make the probability p an increasing function of the age of the object, then that would solve your original problem (explosion of properties) by sidestepping the need for additional properties, while also addressing a frustration (objects breaking on first usage) by making it very unlikely to break when it's first made, but more likely to break as it ages. As a plus, that's more like how breakage works in real life- they get more fragile with age.

Last edited by protein (2018-04-25 22:08:23)

Potjeh · 2018-04-25 21:58:46

Berry bush is a container that doesn't accept input and only generates contents through time-based "decay". Nice sideffect is that interactions wouldn't have to reset the regeneration timer. Not that big of a deal for berry bushes, but a huge buff to wells.

It makes sense to exclude picking berries from the crafting paradigm, because you're not really crafting anything. Not any more than you do when you pull a carrot from a basket.

Last edited by Potjeh (2018-04-25 22:06:03)

akoopatroop · 2018-04-25 22:04:53

Right, the server has no concept of properties. But the game does, and thus hacky methods have to be introduced in order to have properties maintained by the server/code, which has no explicit concept of them.

But the game relies heavily on properties, conceptually.

zed · 2018-04-25 22:23:54

Most likely you've thought of this and it doesn't work, but just in case:
could you use the containers system for properties?
e.g. have a tool "contain" some cracks, and have these be passed on after a
transition. Since (iirc) boxes can be turned into carts without losing their
contents, presumably there's already some mechanism for carrying container
contents through a transition.

jasonrohrer · 2018-04-25 22:31:27

Zed, this has been suggested...

But it would be another hack, and also not particularly simple to implement.

Zwilnik · 2018-04-25 22:50:35

Assuming your ID system is at least a short, just multiply all your Item ID values by 100 and stash their ‘health’ In the lower digits. Just divide by 100 for the actual ID and mod 100 for the health.
That way you’re not adding any extra data fields to the server just a slightly different Accessor for the ID. You would have to do a quick zap of the server data to multiply the current IDs by 100 though
*100 rather than *256 btw to make it easier to read the IDs bs their old values.

Potjeh · 2018-04-25 22:52:11

IDK, I think there's lots to gain from expanding the container system. Consider water, for example. If you want to add another object for carrying it, you have to define all the possible water interactions for the new container, so the number of crafting recipes will grow exponentially as you add more objects, rendering the crafting tips useless. I can understand preferring mess in data over mess in code, but not when the mess in data would be orders of magnitude bigger than the one in code. Alternatively we could still be using rabbit skin pouches to fill our cars' radiators, but that's kinda ugly to me.

Last edited by Potjeh (2018-04-25 22:53:01)

jasonrohrer · 2018-04-25 23:59:27

Potjeh wrote:

Alternatively we could still be using rabbit skin pouches to fill our cars' radiators, but that's kinda ugly to me.

Well, I imagine that the final game will have quite a bit of this....

I mean, will you really want to build an injection-molding machine for plastic just to have a water jug to use with your car for aesthetic reasons? You would probably just use the rabbit pouch if it worked the same...

There is a category system in the transition engine that auto-generates transitions for similar objects.

For example, there's a "small wood chopper" category that contains both the ax and the hatchet. Both can make kindling out of a bunch of things. By using the "small wood chopper" meta-object to define transitions, then we only need to define them each once, not twice.

BUT, under the hood, the engine is auto-generating the actual transitions for us. So the server doesn't know about categories when it checks if hatchet + branch does something, since that transition actually exists.

The idea here is to build as much as possible ON TOP of (A + B = C + D) as a core abstraction.

That is this game's equivalent of the 1x1 meter block (Minecraft's core abstraction).

You can do everything imaginable with just atoms, but some things (like building a bridge) would be tedious to do atom-by-atom.

Can A + B = C + D represent everything? It sure can.

But we can also build some tools on top of it to ease the content-creation process.

This entire forum is built on HTML, after all, but very little of it was generated by hand.

That said, there are some things, like containment, which could be handled by the core abstraction, but which are clearly, provably, intractable.

If we have just 10 small containable object types and a container with 12 slots (like the cart), then we have 1,000,000,000,000 objects that we'd need to represent, along with 20x as many transitions for adding and removing objects. Clearly, we can't do that.

But 140 auto-generated transitions to handle all the different states of shears on all the different states of a moving sheep? Why not?

The core server logic, the thing that's churning away day and night, then becomes super simple. Literally checking for A + B when you try to use A on B.

The complexity lies in the helper-code that auto-generates various transitions for various reasons. But that code only runs once, at startup, and its results are easy to examine and test in isolation (you can actually examine the generated transitions visually in the editor if you really want to).

Potjeh · 2018-04-26 00:41:19

I think the game's concept of being forced to climb the tech tree kinda requires moving onto higher tier materials for water containers. If everything runs out, so should pouches and bowls. Giving them decay when they're constantly transforming into different objects is tricky, but if they were containers they could simply decay just like baskets. Additionally, providing many alternative ways to carry water for example can lead to a more varied gameplay at the same tech level. The choice of which alternative to use would depend on local biomes. You could have more variety in viable start locations, so the Eve experience would be less repetitive.

As for automating recipe generation, it's perfectly reasonable for things like small wood chopper. But I think it's kinda getting stretched when you're defining a category of full water carriers, because you're just defining a water object without actually defining it (forcing it to be a property instead), which leads to all sorts of hacks down the line.

Last edited by Potjeh (2018-04-26 00:43:12)

Turnipseed · 2018-04-26 00:56:27

jasonrohrer wrote:

I mean, will you really want to build an injection-molding machine for plastic just to have a water jug to use with your car for aesthetic reasons? You would probably just use the rabbit pouch if it worked the same...

Yes i would love to build an injection moulding machine for aesthetic reasons, just like i love to dye my shoes blue.

Come on end game on anything is fashion bro. I got that goofy lookin onion armor on darksouls. A kickass checked beige suit on gta. Griffin armor on witcher. Enchanted noblemans cloths on skyrim. And a cookie monster suit on ark.

Of course i would build an oil well, use byproducts to make plastic, and make a bottle of antifreeze from the blood of a penguin.

Content is all anyone wants if updates were just 100 different plants i could grow i would be thrilled! Even if they all functioned exactly like carrots i would grow them just for kicks.

I think most of us understand your still balancing the game, and thats why i still hold onto hope that this game will be great some day. But honestly i think alot of people just want content.

I get home from a 12 hour shift at work and i wanna do something other than make baskets and smith. I love these parts of the game, but its all im doing. A struggling town says we need a hoe im on it youll have one in a minute, but then someone says...
i need an axe...
the baskets are breaking...
The axe just broke...
Need carts...
F!!!....
FFFFFFF....

and i cant help but to try. I want to help them all be successful. Because i am just a small part of this town. My job is to help pick carrots, smith when needed, raise the right number of kids not too few not too many, make sure seed row is preserved, ward off murderers, make baskets, carts, wheels grab water when im near.

I can't do it all but it seems like in most of my lives i have too. Things used to happen at a much chiller pace. I miss those days...

I hope you figure out how you wanna balance this game soon... i really love playing, but its getting harder and harder to want to spend my evenings hearing..
Kill all boys...
Make me an axe....
Fu..ck...yo...u
We need soil...
We need baskets...
This game is ruined...
Cl...ot...hs?...

Just wanted to end this bit of rant by saying thank you jason for working hard and listening to us. Good luck in development.

Christoffer · 2018-04-26 01:09:59

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

Lily wrote:

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.

This concept was described in more detail in https://www.reddit.com/r/OneLifeSuggest … _easy_way/ as a way to model decay. It's also good for modelling tools breaking from actions, because it has the non-apparent mathematical property of bunching together probabilities in the middle and shortening the tail.

Let me explain by example:

1. An axe is given 1/40 chance to break at each use.
Probability for an axe to be used exactly n times before breaking:
1:2.5%, 2:2.4%, 3:2.4%, 10:2%, 20:1.5%, 30:1.2% 40:0.93%, 50:0.72%, 60:0.56%, 80:0.34%, 100:0.20%, 200:0.02%
(an axe is likelier to break on the first use than on use number n, for any n != 1)

2. An axe is given 1/20 chance to turn into battered axe, while a battered axe is given 1/20 to break
Probability for an axe to be used exactly n times before breaking:
1:0%, 2:0.25%, 3:0.48%, 10:1.5%, 20:1.9%, 30:1.7%, 40:1.4%, 50:1.0%, 60:0.75%, 80:0.36%, 100:0.16%, 200:0.002%
(an axe is likelier to break on use number 20 than on use number n, for any n != 20, n != 21)

(a graph would have been nicer, I confess )

Adding a third stage would increases the probability effect further. If you want a probability for tools to break from age as well as from use, you could add a 1/20 chance for transition every 60 minutes as well...

One Hour One Life Forums

#26 2018-04-25 20:21:43

Re: Randomizing tool breakage?

#27 2018-04-25 20:40:14

Re: Randomizing tool breakage?

#28 2018-04-25 20:45:51

Re: Randomizing tool breakage?

#29 2018-04-25 20:51:47

Re: Randomizing tool breakage?

#30 2018-04-25 20:51:59

Re: Randomizing tool breakage?

#31 2018-04-25 20:52:09

Re: Randomizing tool breakage?

#32 2018-04-25 20:54:37

Re: Randomizing tool breakage?

#33 2018-04-25 20:56:49

Re: Randomizing tool breakage?

#34 2018-04-25 21:04:44

Re: Randomizing tool breakage?

#35 2018-04-25 21:22:42

Re: Randomizing tool breakage?

#36 2018-04-25 21:30:42

Re: Randomizing tool breakage?

#37 2018-04-25 21:38:50

Re: Randomizing tool breakage?

#38 2018-04-25 21:47:37

Re: Randomizing tool breakage?

#39 2018-04-25 21:52:12

Re: Randomizing tool breakage?

#40 2018-04-25 21:55:32

Re: Randomizing tool breakage?

#41 2018-04-25 21:58:46

Re: Randomizing tool breakage?

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

Re: Randomizing tool breakage?

#43 2018-04-25 22:23:54

Re: Randomizing tool breakage?

#44 2018-04-25 22:31:27

Re: Randomizing tool breakage?

#45 2018-04-25 22:50:35

Re: Randomizing tool breakage?

#46 2018-04-25 22:52:11

Re: Randomizing tool breakage?

#47 2018-04-25 23:59:27

Re: Randomizing tool breakage?

#48 2018-04-26 00:41:19

Re: Randomizing tool breakage?

#49 2018-04-26 00:56:27

Re: Randomizing tool breakage?

#50 2018-04-26 01:09:59

Re: Randomizing tool breakage?

Board footer