|Update: No Solo|
February 14, 2020
I've got murder on my mind. I was taking a look at the life logs recently, and saw a somewhat normal murder rate of around 6%. Then I ran the analysis a different way, and computed the murder victimization rate. This is the percentage of active players on a given day that are the victims of at least one murder. I ran this analysis on Thursday, February 5, and I was shocked by what I found: a whopping 25% of active players were murdered at least once on that day. Turns out that this was an anomalous peak, but other recent days weren't that much lower, as seen in this graph:
This analysis motivated some of the changes last week to kill waiting times and curse visibility, and you can see the minor effect of those changes toward the end of this graph. But still, I wasn't entirely sure what was going on.
Mid-week, I added a new kill log to the server, letting me see who was landing the kill hits, whether they were solo or part of a posse, and who was being saved via healing. This log did not paint a pretty picture. Since the log was set up on Wednesday, there have been 174 kills, 153 of which were solo killers, acting alone. There were only 21 group kills, and 34 instances of players being saved by healing. Yes, that's 87% solo kills.
And what's the problem with solo kills? Well, a more detailed analysis of one day's log showed that 62% of the solo kills were done in cold blood, unprovoked by previous murder, while only 20% of the group kills were done in cold blood.
That brings us back to why killing is in the game in the first place. Why not just remove it entirely? Because you need to have a way to "vote someone off the island" who is violating village rules. Otherwise, laws become impossible. Killing isn't the only kind of possible griefing, and removing killing entirely makes everyone powerless to stop those other kinds of griefing.
But if you really are voting someone out of your village by killing, and that's the point of killing, solo killing really has no role to play. If everyone agrees that this person should go, you don't need to kill them solo. You can form a posse and kill as a group.
Solo kills are unilateral actions where there is no group consensus. Most of the time, I'm guessing, solo kills are simply griefing, full stop.
Over the past two years, I've added loads of adjustments and limitations to solo killing in the game. Now we have a panoply of warning mechanisms and advantages for the victim. You GASP, the killer looks and sounds angry, you can track the killer off-screen, the killer must wait 12 seconds, and the killer runs more slowly than you. In practice, given all these advantages for the victim, solo kills should be all but impossible. But I've seen it myself: the victim just standing there for 12 seconds, like a sitting duck.
This means that most victims of solo kills are new players who don't know how these warning systems work. This means that most victims of killing are brand new players. That is really bad. Being killed is one of their first experiences in the game.
And like I said, the presence of solo killing does not help with the philosophical point of killing in the game---it doesn't help us vote someone off the island as a group.
So why not remove it entirely?
There are still two cases of solo killing that are dear to my heart.
First, we have the wilderness situation, which I've come to call the Two Hermit Problem. If you're one-on-one in the wilderness, and someone is bugging you, I want you to be able to protect yourself. I want you to be able to say, "scram," and mean it. Even if the person isn't bugging you, the fact that you CAN kill each other is part of the magic of the game. You can kill each other, but choose not to, and that's beautiful.
Second, we have the guarding scenario. With 1-v-1 killing, a guard with a bow can get a bead on a would-be intruder outside the gate, and then open the gate to let people pass through, while preventing the intruder from passing through the guarded area.
The way killing works now in the game, I've been able to preserve the first case, the Two Hermit Problem, but I've had to sacrifice solo guarding, at least for now.
Here are the changes:
In order to kill, you need to form a posse of the minimum size, given the population in your area. In higher population areas, that size is 3 people. But in places with less than six people, the posse size is half of the area population, rounded up. The area is a 30-tile radius around the killer. So if there are only two of you out there, 1v1 killing is still possible. But in a mini-camp of three people, two of you need to conspire against the other in order to kill.
This min posse size is capped at 3, which is what you need in higher population areas.
When you try to kill someone, you still go into murder mouth mode, but you also get a DING message explaining the minimum posse size in your area.
With this change in place, we'll see what happens to the murder rate over the next few days.
|Update: Who's Who|
February 9, 2020
You might call this the information overload update.
First of all, in-game, hit ESC. There was always a graphical hint showing the controls, but over time, the list of "hidden" verbal commands has grown quite long. Now you have a hint sheet for all of them.
There's one new command on this list, and that's the /FAM command. Type this on the chat sheet to see +FAMILY+ labels pop up above the heads of nearby people who count toward your genetic fitness score. These are the people that you need to take care of if you want to climb the leaderboard, have a healthier old age, and unlock more tool slots.
But what about far-away family members? Aside from your mother and grandmother, all of your genetic fitness offspring are younger than you, which means they were born after you (so you had some chance to help them survive). When one of these babies is born, your character will call out, and you'll get a temporary arrow pointing back to the birth location. You will also see +FAMILY+ labels above the heads of all your family members each time a new baby is born.
A similar system has been added to help you keep track of relationships in the leadership system. When you receive and order from your leader, you get a temporary arrow pointing back to them. When you issue an order as a leader, you get an arrow to your closest follower (so you can get the order-passing process started), and you also get +FOLLOWER+ labels above the heads of all your nearby followers.
Note that, thanks to these arrows, issuing an order to your followers can actually help them follow you---when traveling as a group.
Also note that exiled followers don't receive orders or see these arrows, so you don't need to worry about griefers using them to track people. And as a leader, people only get an arrow point to you if you issue an order. So you can control exactly when people can track your location.
Next, to bootstrap the leadership system, everyone auto-follows their own mother, if their mother has no other leader.
Okay, okay, that stuff is pretty cool, but there's one more massive improvement this week. For a long time, curses have been personal. You chose who to curse, and there's a guarantee that the cursed people won't be born near you for the next 30 days. Cursing is a way to say, "Get away from me in the future, I don't want to play with you anymore."
But of course, that didsn't stop people from migrating later in life, returning to the same village repeatedly to cause more trouble. And even though you cursed them, they were impossible to recognize.
Not anymore. Now, each person you curse gets assigned a permanent 2-noun label. Whenever they appear in your game, they have black speech bubbles, and they appear to babble this 2-noun phrase periodically. Only you can see them doing this, though. Other people who have them cursed see a different label. But this will allow you to recognize the same bad actor in future lives.
There are also a bunch of other little changes. A lone griefer can no longer block other people from getting born on low population servers. The waiting period for killing is now 12 seconds, and is cut in half for each member that joins a posse. Posses of three or more people cause the victim to gasp repeatedly in terror, producing a "T" off-screen sound marker. Twins no longer count toward posse size. Human-caused wounds all have a waiting period of 15 seconds before healing can be performed (a gushing state), preventing teams of two griefers from tag-team healing each other repeatedly. When your leader dies, you get information about who replaced them.
After letting the dust settle on the latest genetic fitness score changes, it seems that there is a de facto ceiling around 52. I've adjusted the tool slot curve to account for this:
|Update: Seeking Experts|
January 30, 2020
Still working my way through the list of reported issues. Sometimes it seems like the list is growing faster than I can chip away at it, but I am making progress, and the game gets better each week as a result.
The biggest change this week is that you get a hint when you pick up an unlearned tool about who around you already knows how to use that tool (look for the + speech bubbles above their heads). No more wandering around asking everyone.
A bunch of fixes have been made to the reflector so that it makes better decisions about when to start splitting the game's population up between two separate servers and when to go back to using a single server.
Animals no longer walk through spring-loaded doors.
When you issue an order as a leader, you now receive a confirmation that your order worked.
Let there be dung buckets.
Let there be stacks of empty buckets.
|Update: Curved Tracks|
January 24, 2020
Forum member Wuatduhf made an important discovery: recent changes to the way object patterns work had suddenly made curved cart tracks much more reasonable to implement.
It turns out that I already had the graphics drawn for these curves, and they looked really good back in the day, but I had to scrap them because of the combinatorial explosion that they would entail. For example, north-moving carts already had three "leave" cases (leaving from south ends, north-south tracks, and cross tracks) and three "entering" cases (entering north-south segments, entering north ends, and entering cross tracks). To handle all the combinations, 9 distinct transitions were required for each cart direction, resulting in a total of 36 transitions. That's a lot, but as soon as we add in curves, it blows up even more, with something like 25 transitions needed for each cart direction, or 100 total. That's a lot of transitions to author correctly, and way too much to keep track of along the way, resulting in tons of room for error.
So what changed with object patterns to help with this problem? Something pretty tiny and simple, actually. Part of the bottle update a few weeks back involved emptied bottles that made a final sound as they were emptied. Roughly half of the bottles held liquid, and the other half powders, requiring a different empty bottle state for each to play the "glug-glug" or "swish-swish" sound. All the bottles were part of one big 18-item pattern, but how could I flesh out the empty state for this pattern? Since an object can only occur in a given pattern once, I would need to create 18 separate "empty" bottles, even though they all pretty much did the same thing (half of them playing the powder sound instead of the liquid sound). That's a lot of extra objects that essentially do nothing. But why couldn't a pattern have repeated objects in it? In other words, why couldn't a pattern "converge" on a few common end states? These bottles could be different all along, with 18 variations, but once empty, end up as one of two empty-state bottles to play one of two sounds. Each of the 18 slots in the pattern would contain one or the other of these two bottle objects. I updated the pattern editor to support this, and that was it.
Wuatduhf's observation was that these new "converging" patterns were exactly what was needed to cut through the combinatorial explosion for tracks. As a simple example, when a track cart moves north out of one of five possible north-bound tracks, each of these needs to potentially land in the same connecting track. This can be implemented as a pattern, then, only if the pattern can contain repeats of the same destination track.
Thus, instead of 25 separate north-bound transitions, I was able to implement one set of north-bound transitions describing what happened to a north-bound pattern, and then fill the pattern with all the cases.
This also allowed me to implement tracks that pass through spring-loaded doors pretty easily, preserving the insulation bonus for the room that the track emerges from.
In the end, each of these patterns had 25 elements each (with repeats to cover the various combinations), and the north-south patterns had 36 elements each (due to the extra combinations needed for passing through spring doors). And there were five separate patterns for each direction, resulting in a grand total of 610 items listed in these patterns (all passing through only a small handful of transitions).
There was still a lot to keep track of when fleshing out these patterns, and the whole thing felt about as close to an IQ test as I've experienced while working on this game. My moth-holed, 42-year-old brain muddled through it all, but barely.
But those curvy tracks sure do look nice. Great to dust off 17-month-old artwork and finally put it to use.
|Update: Baby Placement|
January 17, 2020
My wife was out of town all week, so I was left with the task of being a full-time parent as well as a game developer. I did manage to get a few things done, though.
First, there was the question of Eve frequency, and how that tends to spread civilizations out over time. Eve placement is related to baby placement (we place an Eve instead of a baby under certain conditions), and in thinking about the baby placement code, I realized it had grown into a multi-scarred monster over the years of trying different methods inside and outside the rift. Seemed like a good time to start clean and really think about what baby placement is supposed to accomplish.
Our highest priority in placing a baby should be to make sure there's at least one family in each of the specialist skin tones, and if all of them are already present, bolster the population of the weakest skin tone. After that, our next priority is to bolster the population of the weakest family, and place girl babies when the number of potentially fertile females in a given family gets too low. Of course, we also want to respect each mother's birth cool-down when possible, and also each player's previous-life area bans (so they don't get born to the same family over and over). But we should also be willing to ignore cool-downs and area bans if there are no other mothers available. No one should be able to area ban themselves, through suicide, into being an Eve, and we'd rather overload a mother on cool-down than spawn an Eve.
Finally, we need to make sure that the server is never overloaded with babies relative to the adult population (more than 2/3 babies), nor that a few remaining mothers are overloaded with babies (more than 4 babies per mother).
And of course, through out all of this, we respect curses, never placing a cursed baby near a player who cursed them, ever ever ever. If there's no place for a cursed baby to go, they are sent to donkey town.
With those priorities cleanly stated, we can see that we only place Eves in two situations. First, if there are too many babies for the existing adult population or population of mothers. And second, if we're missing one of the specialist skin tones.
Those cases should be relatively rare, which means that new Eves should be rare.
With the simplified code in place, the behavior is much easier to reason about. If there seem to be too many Eves in the future, I'll be able to figure out exactly why.
Next, the Genetic Fitness leaderboard has clearly been getting out of hand, with top scores climbing into the 500s. In looking closely at the top-scoring players, I found something distressing: many of them had very low average lifespans themselves. By keeping their own lifespans low through regular suicide, the were able to farm points whenever they lived an occasional long life. Furthermore, they were essentially handing out free points to everyone else through these occasional long lives. It was also clear that quantity was trumping quality. When scores are potentially infinite, playing a lot of lives is the only way to reach the top.
Implementing a suggestion from Wondible, we're now back to scores that are asymptotically capped at 60, while still solving the problems that the older capped system had (where you got punished for having a new player as a baby). You now gain points whenever you help an offspring player live longer than expected, but the amount you gain is scaled relative to your own score. Thus, the closer you are to 60, the less you can gain from each offspring, but the more you stand to lose if you actually hurt an offspring and cause them to live a shorter life than we expect for them. You also gain points for yourself when you live longer than expected, with your score approximating how long we expect you to live.
Thus, there's no longer an exploit possible through suicide. The best way to get a very high score is to live very long lives yourself, and never suicide, and help all of your offspring to live as long as possible, too.
Returning to a capped score demands a new formula for mapping score to tool slots, which can be seen in this graph:
As part of this investigation, I made more of the leaderboard data public. You can now click on the top-scoring players and see the recent lives that contributed to their score:
Thus, if another exploitative way to boost score emerges in the future, it will be easier for everyone to study and identify it.
But looking at the data now, we're off to a good start. All of the top-scoring folks have very high average lifespans themselves.
There are also a bunch of little fixes. More stuff can be bottled, and bottles are a bit easier to work with.