[Home] [Buy] [News] [Family Trees] [Leaderboard] [Photos] [Update Log] [Polls] [Forums] [Tech Tree]
Update: Pile Up
May 15, 2020


Rail carts are now much more robust, flexible, and useful, mainly because they crash and derail in far fewer situations than before, but also because they can be manually sent in the opposite direction mid-run.

Before, if a moving cart didn't have an empty section of rail out in front of it, it would derail. This made some sense, because the cart was crashing. Players learned to work around this by having only one cart on a given section of track, to make crashes impossible. Other players were trying to put multiple carts on the same loop of track. If the carts kept going round and round, they'd never hit each other. However, subtleties in the timing code server-side sometimes made one cart move before the others (depending on who was looking at what part of the map), and these advances would accumulate over time until the carts eventually crashed. But even if loops weren't a problem, the limitation of only one cart on a linear track was huge, mostly because long tracks are very expensive to build, and a single cart carries so little.

Now, if a cart would otherwise hit another cart ahead of it, it just stops and waits, and continues moving if that other cart ever gets out of the way. If two carts have a head-on collision, this means they get stuck pushing against each other. And this is where the second new feature comes in: click a cart with your bare hand to cause it to reverse direction. Two stuck head-on carts can be freed in this way. Furthermore, a bunch of carts can pile up on one end of the track, allowing new carts to launch from the other end. Thus, a single linear section of track can now have an unlimited number of carts (of course, if you fill the entire track with carts, it's not going to be very useful).

In a pile up situation at the end of a track, clicking the carts one by one will send them back in the other direction.

A bunch of improvements and new features have been added to the leadership and inheritance system. First, you now have /LEADER, /FOLLOWER, and /ALLY chat commands, which put markers above the heads of the target people, and also give you your current follower and ally count.

To reduce the chance of bad leaders being chosen by default, inheritance now picks the most genetically fit follower instead of the oldest. The idea is that griefers don't do a very good job of keeping their family members alive, so they won't be chosen as default leaders very often. A similar change has been made for property inheritance, where your most fit offspring or relative is chosen.

You get a DING message now when you are exiled or redeemed by a leader that you follow, and are also informed of your current ally count when this happens. This gives you fair warning that things are going south for you in the area, and that people may be planning to kill you.

The bug causing stale bell tower locations to be passed down through many generations has been fixed.
[Link][6 Comments]

Update: In Perpetuity
May 8, 2020


Several systems that required repeated manual intervention for trans-generational propagation have now been made automatic by default. In the past, these systems were rarely used, in part because of maintaining them long-term was almost impossible (one weak link in the chain, in some future generation, caused the whole thing to fall apart).

First, property.

If you die as the last owner of a property gate, instead of the gate collapsing, ownership now passes to your oldest family heir. This is your oldest child, grandchild, or great grandchild, if you have any, or your oldest, closest relative otherwise. To prevent gates from hanging around forever, even if they're no longer wanted, owners now have the power to remove them at will. When you inherit property, you get a DING message explaining the situation, and an arrow pointing back to it.

Second, leadership.

If a leader dies with no chosen heir (they can chose one by following someone before death), their oldest follower takes over for them as leader. All their other followers automatically switch to following this new leader, and get arrows pointing toward them. The new leader gets a DING message informing them of the situation.

Combined with the fact that babies follow their mother's leader by default, and babies of leaderless mothers follow their own mother by default, leadership will be the default condition throughout the game. People can still opt out by following someone else or intentionally following no one, so truly bad leaders that inherit their power can be easily removed from office. Furthermore, since most people in a family will follow the same leader by default, there's now a reliable way to mark bad actors through exile (when the top leader exiles someone, everyone will see it). And that leads us to the next tie-in.

Third, killing.

In the arms race against murder sprees committed by coordinated teams of griefers, killing has become harder and harder. The posse system worked to prevent unilateral, unjustified killing. However, it also demanded organization on the part of the players to carry out consensus-based, justified killing. This organization, for a group of strangers working together through in-game chat, is tough. But a griefer team, working through voice chat, can easily meet the required level of organization.

The required posse size has been climbing to combat this, and the griefer teams have been growing in size along with it. Meanwhile, necessary killing in the game (to stop non-killing griefing) has become almost impossible. If 8 people are required to form a posse, you have to get 8 random strangers on the same page, at the same time, about what they are trying to do.

What is the actual goal here? We're trying to prevent the minority from pestering the majority with nuisance killing. We can assume, hopefully, that any team of griefers will be smaller than the group of non-griefer players in a village. How do we give the larger group the power to both avoid getting killed by the smaller group, and also the power to kill easily when necessary? A large enough posse requirement protects the majority from being killed, but it makes it way too hard for them to kill.

And just a quick aside: if you haven't been following this game's growth closely, you might be thinking, "Why is there killing in this game at all? Just remove it!" But then what happens when someone keeps moving your tools right when you go to use them? What happens when someone steals your horse and won't give it back? There are endless ways for one player to irritate other players. Killing is supposed to be the way the group says, "enough is enough."

But how do we know who the majority is, so that we can give them that power?

This week, I'm testing a new idea: your group is defined by the leadership tree that you are part of. If you are part of a big group, you can't be killed easily. If you are not part of a big group, you are fair game for anyone to kill. You inherit (or choose) which group you are part of based on which leader you are following. But leaders have the power to remove you from their group, and relegate you to your own defenses, through exile.

In detail, we count up your allies (those that see you as part of their group) and your enemies (those that see you as exiled). If you have at least as many nearby allies as enemies, you can't be solo killed, and a large posse is required to get you. However, if you have more nearby enemies than allies, anyone is free to solo kill you.

A small team of griefers might be able to form their own leadership tree and thus have a few allies each, and they might be able to exile you, giving you a few enemies. But as long as you are part of a larger group of allies, you will be immune to their attacks. Furthermore, if your group exiles them, they will have a lot of enemies, and be easily dispatched.

Also, if trouble crops up within your own ranks, all the top leader needs to do is exile that bad seed, and then anyone in the village can take care of the problem.

(Feels strange to be talking in euphemisms like a mob boss....)

Combined with the fact that everyone will be part of a leadership tree by default, and we can see that everyone will be protected by default. The ally pool will be manually shifted around as needed, through exiling and changing leadership, to deal with problems as they arise.

Finally, if you try to kill someone who is protected by allies, thus requiring a large posse, you get an arrow back to their top leader, so you know who to petition to exile them.

Yes, there will be times when talking the leader into exiling a legitimate troublemaker doesn't work out, but it will be much simpler to accomplish than trying to get 5 strangers to act in unison to form a posse.
[Link][67 Comments]

Update: Tunnel Light
May 2, 2020


Only 7 more reported issues remain.

At this point, I've closed nearly 1200 issues.

Big changes this week to the posse system to make it less confusing and harder to evade. Posse members don't get sick in bad biomes, and posse targets are too scared to carry anything, so they can't hop on a horse to escape. You know your posse is big enough to land a kill when the target starts whimpering in terror.

Information overload has been reduced by limiting your NEW BABY notifications to one per minute max, and only showing you VISITOR notifications for your gate when you're far from home (and also at most one per minute, max).

Donkeytown players can no longer manipulate end towers or ring the bell tower, so no more hidden d-town apocalypses.

Non-property fence gates now auto-open and close when you pass through, and never let animals wander out.

You can hook your bow on the outside of your quiver or backpack, similar to how a sword can be carried.

Potatoes harvest has been overhauled to waste less iron in digging. Property fences cure more quickly and are less fiddly to build. And a bunch of other little fixes, which you can see here: https://github.com/jasonrohrer/OneLifeData7/commits/
[Link][11 Comments]

Update: Prep Table
April 23, 2020


New stuff: Tables for rolling tortillas in batches. Buckets for hauling quantities of palm kernels, corn kernels, and threshed wheat. A bunch of new stacks. Efficient scrapping of various metal parts.

And more fixes based on reported issues. Only 30 open issues remain.
[Link][10 Comments]

Update: Food Fixes
April 17, 2020


Thanks to input from forum members Twisted, Miskas, and Fug, all food values have been re-examined and rebalanced based on how hard they are to make and what input resources are required. We might see a perfectly balanced food system as being flat and boring, because all foods would be equal in terms of efficiency, so this update does not aim for that kind perfect balance.

The YUM system is meant to make the less-efficient foods still worth eating from time to time, and YUM has been changed so that your chain never breaks. Your bonus grows every time you eat a new food, and you get that bonus each time you eat a new food, but eating a MEH food simply skips applying the current bonus, instead of setting your bonus back to zero. This means you can no longer cycle a small set of foods to farm a small bonus over and over, but it also means that during tense times, you won't destroy your YUM progress when you have to eat a MEH food out of desperation. This will make growing a large YUM bonus quite a bit easier, and we'll have to see if it swamps the rest of the food system. If so, there's a cap setting (limiting the bonus from growing to high) that I can apply as needed.

But up until now, YUM hasn't been needed for survival anyway. I'm in the process of changing that.

Last week, I cut all food values in half as an experiment, based on observations of massive food surpluses in most late-stage villages. People had also been depending almost exclusively on low-efficiency foods for survival, since massive surpluses made efficiency unnecessary. By the end of this week, food behavior in the game has indeed changed a bit in reaction to these reduced food values, with players making more high-efficiency foods---there was quite a bit of panic and starvation earlier in the week, of course.

The most interesting thing about scaling food values was how it reduced the value of low-tier foods. The problem with a uniform scale factor is that it effects high-tier foods too (a berry went from 3 to 1.5, and a feast plate went from 40 to 20). This made the game universally harder, regardless of which foods were eaten, which wasn't exactly the goal. The goal was to make the high-tier foods more necessary for late-stage villages.

This week, a new gradual scaling system is in place: as the generations wear on for a given family, a growing value is subtracted from all food values. This value reaches a maximum of 5 after about 30 generations, and if subtracting the value would make a food 0 or negative, the food is pegged at 1. So a berry would eventually be worth 1, while a feast plate would eventually be worth 35. A cooked rabbit would drop from 10 down to 5. You can see how this kind of adjustment affects low-value foods much more than high-value foods, in relative terms. It is a bit like the opposite of the eating bonus, which buffs low-value foods much more than high-value foods, relatively speaking.

Beyond food changes, there are a bunch of new stacks, and an arrow pointing toward visitors that knock at your gate. You also get better labels above the heads of the people that you are navigating toward, helping you find them in a crowd.

A few exploits have also been fixed.

If you're die-cycling to find your friends (living less than 20 minutes in your last life), you don't count toward the posse size of a posse that you join. This limitation already applied to twins, but the goal is to prevent a group of friends from ganging up on people.

Abandoned outposts (non-primary homelands) untap springs and iron deposits when they expire, allowing new Eves to settle there later, and preventing one player from making loads of spurious outpost homelands to block iron and water opportunities in a large area.
[Link][16 Comments]

[Home] [Buy] [Wiki] [Food Stats] [Fail Stats] [Artwork] [Credits]