One Hour One Life Forums
a multiplayer game of parenting and civilization building
You are not logged in.
- Topics: Active | Unanswered
#3426 Main Forum » Randomizing tool breakage? » 2018-04-25 17:18:40
- jasonrohrer
- Replies: 59
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 + firewoodWe 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_7But 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_bushThe 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.
#3427 Re: Main Forum » Why do I need to give out so much information to buy the game? » 2018-04-25 16:41:04
Fastspring's privacy policy is here: https://fastspring.com/privacy/ Paging through it I notice that they sell information for their "Ecommerce Network". So you are right to be concerned.
I don't see anything there about them selling information. The "Ecommerce Engine" is the payment processing system. That is the system that I'm using to process your payments.
In terms of "partners," I'm an example of one of these partners. They process payments for me, and I have access to all of the information that they collect. I can see your name and address, for example.
As far as I'm aware, they are not selling your information or using it for any other purpose other than to prevent fraud.
They are taking 8% of every sale. They are making plenty of money. They don't need to sell your information to make money.
#3428 Re: Main Forum » Shears are currently one use » 2018-04-25 16:29:47
Yes, this is a bug. Will be fixed in the next update.
Same thing for shovel on worm pit, by the way.
#3429 Re: Bug Discussion » Death from "Connection Lost"? » 2018-04-25 16:22:58
As far as I can tell, the servers have not been crashing at all since Sunday.
They are online now and still going strong.
I wonder if there is some other bug causing broken connections, though.
#3430 Re: Fixed Bugs » Possible shovel bug » 2018-04-25 16:20:53
Oh boy, you're right.
The same thing is happening with sheep shears.
The problem comes from a multi-use object (like the shovel, which can be used 20 times before breaking) being used on another multi-use object (like the worm pit, which can have 2 worms pulled from it before becoming wormless).
#3431 Re: News » The Nudity Question » 2018-04-25 16:18:39
Glad to hear that!
#3432 Re: News » New Eve placement algorithm » 2018-04-25 16:16:41
Eve is supposed to be uncommon, but on the other hand, I have not control over how common it is. Players control that by how many babies they allow to die. If too many babies die, then there will be more Eves. Each woman can only have so many babies in a given time period due to the birth cool-down. If you die as a baby repeatedly and keep respawning, eventually you will run out of mothers to spawn to, and you will spawn as an Eve.
#3433 News » New Eve placement algorithm » 2018-04-24 20:14:04
- jasonrohrer
- Replies: 10
The way Eves are placed has a substantial impact on the feeling of the game. Whenever a player joins the server when there is no suitable mother for that player, that player spawns as a full-grown Eve instead of as a baby. Eve serves as the potential root of a new family tree, and her placement determines the opportunities that are available to that family.
Originally, Eves were placed at random inside an arbitrary radius around the world location (0,0).
This worked fine for a while, until that area began to fill up with civilization. Eve is supposed to feel like a fresh start, with maybe a small chance of stumbling into the ruins of a past civilization, or eventually bumping up against a living, neighboring civilization. As the center of the map got full, Eve was always just a stone's throw away from a village. Furthermore, with everyone so close together, there was no danger of losing a village if it died out. Thus, keeping a village alive meant nothing. We could always find our way back to revive the ghost town tomorrow. Even worse, as these areas got ravaged by human activities, the resources that a new Eve needs to bootstrap became more and more scarce. Eve does need a somewhat green pasture to found a new civilization.
The next Eve placement algorithm involved a random walk across the map, looking at the last Eve location and making a random jump 2000 tiles away to place the next Eve. There can be some randomly-occurring back-tracking with this method, which means that Eve can sometimes end up near the ruins of old civilizations, but we expect such a random walk to eventually explore the entire map, so we will also get farther and farther from center over time. And with many Eves dying without founding new civilizations, and also perhaps due to biases in the random coordinate generator, we quickly walked our way from (0,0) out into the 50,000's. This meant that villages were generally too far apart to interact with each other. Still, Eve was usually in an untouched area full of natural resources.
The next Eve placement algorithm was radial, placing Eves randomly at a radius of 1000 from a fixed center point. This put all villages within trading distance of each other, and offered plenty of untouched space for Eve---for a while. But soon, the "rim" of the wheel filled up with civilization, and we were back to where we started---Eves placed in a crowded area that was stripped bare of natural resources.
The latest Eve placement algorithm was suggested a long ago by Joriom and maybe a few other people, and involves an ever-growing spiral around a fixed center point. This guarantees that Eve is always in an untouched area, but also that she is never too far from some recent civilizations, so trade can happen.
While a server is running, the placements look like this:
You can see the three initial Eve placements at the center, which the server permits at startup to ensure that the first few Eves can have a chance to bootstrap a village in that spot. After that, the spiral ensues, and would keep going as long as the server was running.
What happens when a server shuts down though, as it does every week during updates?
First, the death location of the longest-lineage person during shutdown is remembered. This is used as the "center" of the spiral at the next startup, and after startup, the first three Eves are placed near there. After that, a new spiral grows around that new center point, like this:
As this new spiral grows, it will cross through the previous spiral like so:
That is okay, because any of the other civilizations that were active at shutdown will potentially be rediscovered by Eves, which makes for an interesting Eve variation. Still, future Eves will not be trapped in these already-developed areas, as the spiral will continue further out into untouched areas again.
Also, some of the older, long forgotten villages in the old spiral will be wiped when the server restarts due to the 24-hour abandonment cut-off. Thus, the new spiral will cross through many now-wild areas, even as it overlaps the old spiral.
As the new spiral grows bigger, it will eventually engulf the old spiral and move beyond it, but the overlapping area will always be substantially less than half of the new spiral. Thus, even if 100% of the old spiral contained active villages that were not wiped, more than half of the Eves in the new spiral will be placed in untouched wilderness.
#3434 Re: Main Forum » The decay update is perfectly fine, it's players that are wrong » 2018-04-23 22:52:54
Needs for a successful village:
1. Farmers - For Carrots
2. Rabbit trappers - For pie and clothes
3. Bakers - For baking pies.
4. Smith's- For creating tools.
5. Tailors - For making clothes.
6. Fire Attendents/Nurse Maids - To monitor population
7. Milkweed Harvesters - So milkweed isn't picked early
8. Trash collectors/Grave collectors - For organization
9. A Guard - For bears and the occasional troll.
10. Resourse Collector - For clay and soil (mostly soil)
11. Town Crier/Scout - To keep everyone 'In the know.'
12: A Mayor - To designate jobs
You should see my hand-written notes from the design meeting where I was discussing this stuff with my designer friends. It had a list just like this. Here was my rough list of roles that a village would need:
--Farmer
--Composter
--Smith
--Prospector
--Herder
--Knitter
--Wagoneer
--Woodworker
--Worm Gathererer
My friends, as a joke, added these to the end of the list:
--Griefer
--Chain Smoker
The point of this update was that before, NONE of these roles needed to exist except for Farmer. There were smiths in the past, to get a village off the ground, but after that, their forges lay dormant for generations.
I want the current generation of smiths tranining the next generation of smiths.
#3435 Re: News » The Nudity Question » 2018-04-23 22:45:12
Thanks, everyone.
This is a thread that is more than a year old at this point.
Nudity has been in the game for a while now!
#3436 Re: News » Update: From Riches to Rags » 2018-04-23 21:13:02
Not sure what part of the trailer or marketing gave any of you the impression that you would build something in the game and it would last forever.
That doesn't even make sense.
There have been 1,000,000+ lives lived in the game so far, and if each one made a lasting, immortal contribution to the world, the world would be so full of stuff that it would all be meaningless. A million walls? A million baskets? A million axes?
Making anything new in that context would be pointless.
The fact that the game originally had things lasting forever was essentially a bug. You got used to it, and grew to like it. But it never was the long-term intent.
This post was on the front page for quite a long time, for example:
http://onehouronelife.com/newsPage.php?postID=63
And right on the home page, the game has always been described as a "multiplayer SURVIVIAL game."
#3437 Re: News » Update: From Riches to Rags » 2018-04-21 16:40:43
The walls take 5 generations to start cracking. And they can be fixed after that. That's a long time.
I fixed the hoe. An update is going live with that change.
Also, servers were crashing. That has been fixed. The change is going live right now.
#3438 News » Update: From Riches to Rags » 2018-04-21 06:00:32
- jasonrohrer
- Replies: 61
75 new things. Mostly broken things. Rotting things. Fragile things.
And stone walls, which are the opposite of all of that. And locking doors.
A whole new web of interdependence for farming.
A new mother selection method (temperature, not food).
#3439 Re: Main Forum » Weird meta-idea: stuck in a life for an hour » 2018-04-18 16:50:31
Maybe you can respawn on the same server over and over, in the same hour, but your later spawns are as lone hermit men?
All of this makes "quit playing for an hour" seem like the best option for the player. That's a very risky incentive for me to build into the game...
#3440 Re: Main Forum » Weird meta-idea: stuck in a life for an hour » 2018-04-18 16:48:36
Well, the question still remains: how does the server know to send you to the phantom zone or whatever? What happens during your last life that triggers it?
SSDarkMoon a karma system solves the problem automatically with no player involvement. I want to give the players tools to solve the problem instead. Killing isn't always bad. Digging up stuff isn't always bad. Only players can decide that.
Kinrany: that's an interesting idea. The server remembers you for an hour after you join, and no matter what happens (you die of starvation, you are killed, you suicide), you are not allowed to respawn on that server for an hour. The only way to keep playing on that server is to keep living (which make "stop or we'll shoot" mean something).
BUT: what happens to a brand new player who dies 15 times in one hour? They are "on cooldown" on all 15 servers then, unable to play...
#3441 Re: Main Forum » Weird meta-idea: stuck in a life for an hour » 2018-04-18 15:38:37
No, I don't mean suspended animation.
You still consume food and you still age when you are disconnected. You will die of hunger or old age, eventually.
BUT, if people keep feeding you, you will live until old age (a full hour).
Not really sure how to implement banishment, especially since it would happen in the next life.... I mean, obviously, being born as a lone male hermit repeatedly for the next hour would do it. But how to trigger it?
That would mean the servers would have to "listen" to other people's decisions in the current life to decide what happens to the person in the next life. Essentially a "dance on their grave" mechanic, or the curse that was discussed in the other thread.
#3442 Re: Main Forum » Jason's Murder Problem Thread » 2018-04-18 15:31:46
Some towns have had guards on patrol. This has actually occurred in game, and that they wore blue clothes and everything. Not every town, and not everyone has seen it, but it has happened.
Guarding is actually one of the most complicated jobs in the game, because it involves judgment and decisions about people's behavior. Right in this thread, you've already told me how hard it is (limited view distance, no witnesses, etc.), in the same breath as saying that it's boring. When a murder victim staggers up to your screaming their last words, but there were no other witnesses, and the murderer is hiding somewhere, that's not a boring moment. When you get reports that some tools have gone missing, and you're given the name of a suspect to question, that is not a boring moment. You also have to train the next generation of guards, figure out rules of conduct for the guard caste, etc.
An NPC simply couldn't do it. And guard dogs? How would they know who to attack? Is the guy who just picked up the shovel stealing it or legitimately using it? A human guard can ask, "Hey, where are you taking that shovel?"
The other thing that a successful long-term village needs is leadership to make high-level decisions. Monitoring food supplies vs. fertility rate vs. seed supply. Should we make compost or carrots right now, etc. As a leader, you're not actually "doing" anything. You're kinda like an accountant or bureaucrat. But you're also kinda like a king. You're wearing the crown. Everyone is listening to you. What a boring job, though!
#3443 Main Forum » Weird meta-idea: stuck in a life for an hour » 2018-04-18 15:04:59
- jasonrohrer
- Replies: 56
This idea came up last night at a game design meeting in response to the problem of griefers respawning.
But it has many far-reaching implications.
What if you cannot disconnect to kill yourself?
What if, as long as you don't starve to death, your life continues. If you disconnect, your character is a zombie for a while. If you ever reconnect, you're stuck back in that same life again.
The main thing this would allow for would be some kind of true imprisonment. A griefer can no longer respawn every ten minutes to do more grief. If they get caught, trapped in a prison, and fed carefully by their captors, they can be kept alive---and stuck in that life---for a full hour each time.
You can try disconnecting over and over, but each time you reconnect to the official servers, you find yourself right back in that same prison term again, until the hour is over (or until your captors release you or let you die of hunger, or someone rescues you or euthanizes you).
This is of course---like everything else---a double-edged sword. A griefer could imprison people too. Kidnapping, slavery, and baby-farming would become possible.
I would also be tempted to NOT let babies jump out of arms voluntarily, so your mother could keep you alive, and stuck in your life, as long as she kept catching you. If you disconnect to escape this, reconnecting will find yourself right back in that same baby's life.
The mechanics of imprisonment would have to be worked out (saying, "Get in that jail cell or we'll shoot you" won't work, because you'll just let yourself be shot), but some form of being incapacitated and carried could be implemented, along with the forthcoming locks for a prison cell, or maybe some simple "tied to a post" mechanic.
The danger here is that it "ruins the game" for an hour for the victim. And of course, not only griefers would be the victims. A tyrant could imprison a whole group of people, and essentially lock them out of the rest of the game for a whole hour. Well, they could still "play" the game by living out the life of a prisoner, singing songs with the other prisoners, and begging to be released, moaning, etc. The tyrant could get guards to help them by threatening the guards with similar imprisonment if they disobey. And a hero could come along and kill the tyrant to free all the prisoners.
I've always wanted these things to emerge anyway, but "just disconnect" was always a way around them. I want people to develop prisons, but the idea was that the prisoners would be attached enough to their current story that they'd want to see it through rather than risk death. I think that's probably the case for most people. "I ended up in jail, what a hilarious story."
Though how many people, if threatened with, "Get in that prison cell or I'll shoot you," would actually listen, in-game?
#3444 Re: Main Forum » Jason's Murder Problem Thread » 2018-04-18 14:45:34
Do you really think that being a police officer and investigating murders would be less exciting than farming carrots?
#3445 Re: Main Forum » Deciding who has a baby » 2018-04-18 14:34:27
Thanks for all this!
I don't think it needs to be too complicated.
Temperature seems like the most sensible simple metric that captures a lot of other factors.
The other thing that was mentioned briefly was length of family line so far.
I will think about "distance from a male." Every village keeping at least one male around....
Though this doesn't help with Eve so much, and also flies in the face of a decision that I made years ago for good reasons. This should NOT be a game about mating and consent and all that nonsense---if you don't want to have a baby and some griefer male keeps following you around anyway, and then you have a baby against your will, what just happened? All that emotional baggage from the real world. That is not the point of this game, and it would distract from the 10,000-ft view of the human situation that I'm trying to construct here. I don't want to spawn Even and Adam together and then have Adam chasing Eve around while spam-chatting, "Come closer, honey."
#3446 Re: Bug Discussion » "Programme stopped working" issue » 2018-04-18 14:15:34
If the game is doing this, it's a bug that I need to fix.
Please follow these instructions to generate debugging information:
#3447 Re: Fixed Bugs » Mushrooms not having any effect » 2018-04-18 14:12:14
Not sure what's going on here. Maybe your client didn't update properly for some reason. Sounds like you have the graphics for the mushroom but not the effect code.
#3448 Re: Main Forum » Jason's Murder Problem Thread » 2018-04-18 01:24:09
Yes, that is also true.
Obviously, this game is not real life.
However, I have to be careful not to build the solution into the game and "solve it for you." Like a karma system would do that automatically. People would no longer have to think about it or come up with their own solutions or have guards.
I want you to solve it, in various ways, because that is interesting. The game is full of problems for you to solve. That is all it is. Problems, and their various solutions, make for interesting stories. Problems are at the heart of drama.
On the other hand, if it's actually impossible for you to solve, that is a huge problem.
Respawning is non-trivial in this game, so we're already way better off than pretty much any game operating in this space.
Hard server assignments would also help. Suppose you are assigned to a server for an hour. If you die before that, you get assigned to a different one. If you live the full hour, you stay on that server.
#3449 Main Forum » Deciding who has a baby » 2018-04-17 22:51:15
- jasonrohrer
- Replies: 56
Currently, babies are distributed randomly to women who are of fertile age and NOT currently on birth cooldown, and their chance of having a baby is weighted by how well-fed they are compared to other eligible mothers on the server.
Empty stomach at the moment the baby joins means you're less likely to be the mother. Full stomach means you're more likely.
This is an okay first heuristic, and it mirrors human biology nicely, but it's probably not that great in practice. Most people keep pretty full if they can, and it also doesn't differentiate between civilized and non-civilized people well, or really differentiate who is best-suited to raise the baby.
I do want "better villages" to have higher birth rates, though.
Maybe their motherhood chance should be weighted by temperature instead? Stand by the fire to have a baby? Desert dwellers have more babies? What about too hot making you have even more babies? Or should it by only if you're just right?
What about a mother running an errand, away from the fire....
Let me hear some ideas about how this should work.
#3450 Re: Main Forum » Jason's Murder Problem Thread » 2018-04-17 22:41:15
Real life combat rewards action over reaction.
Walk up behind someone and shoot them in the back of the head with a gun. Walk away. Sounds gruesome when it's put in those terms, but that's how easy it is in real life.
I was intentionally trying to get away from "normal game PVP mechanics" in this game. That's why there's no health bars, armor, healing potions, etc. Those kind of mechanics turn any game into a combat game.
Combat is NOT the focus of this game, and it will never be. The networking implementation isn't low-enough latency to support that anyway. If I wanted to make an online combat game, I would want it to be as tight and responsive as Overwatch. It wouldn't be an infinite map game. I would have coded it totally differently.
If you're claiming that murder should be made impossible entirely, you haven't thought it through. The only way to stop someone from doing something, in the end, is to kill them. So killing is necessary if people are going to be able to develop their own legal systems in the game.
Other people have pointed out that murder is the least of our worries, compared to other forms of griefing.
Unfortunately, there is absolutely no way to solve that problem mechanically (there will always be ways to mess things up, even if I make every action non-permanent, and the game would become ridiculous if I did that, where you'd have to be able to un-slaughter a sheep).
And if I take murder away, it will also be impossible for YOU to do anything about griefing.
You do have walls for a reason, to control access. If you're worried about a griefer planting the wrong crop, put walls around the farm fields. Only let the farmer in and out. Post a guard by the door. Tools getting stolen? Do you leave your tools in real life laying on the ground? No. If you did, they would get stolen too! So you put them in a tool shed.
The king always has a wall around his garden in real life.
But walls won't work if you can't threaten someone at the gate with violence to make them go away.
Gates in real life usually have two guards for a reason...
After thinking this over more, I think that most of the tools to solve these problems are in your hands, and a few more (like locks) will come in the future.
And these ARE the problems that civilization needs to solve.
Even modern civilizations are still trying to solve these problems. Lots of murders in real life go unsolved.
I will work on the "can't stab a moving person" issue. Running around shouldn't be a form of defense.