[Home] [Buy] [News] [Family Trees] [Leaderboard]
[Photos] [Update Log] [Forums] [Unicode Language Mod] [Tech Tree]
Update: Ancient Names
October 4, 2019

https://i.imgur.com/aMRkV5A.png

First of all, if you live in the Denver area, I'm speaking this Saturday at the Whaaat festival held at CU Bolder. More info here:

http://www.whaaat.io

When baby naming was added to the game 18 months ago, there were 86,000 possible last names and 30,000 possible first names. That's a lot of names. The last names were taken from the US Census 2000 and included all names that occurred at least 200 times. The first names were taken from the Social Security database for the year 2016, and included all first names that occurred at least 5 times.

Taking a closer look at the source data, I noticed that far more names were available. I must have picked the 200+ cut off for last names myself, because the source data went all the way down names that occurred only 100 times. I suppose I was trying to cut down the data size, but now I realize that there's no reason to do this, thanks to the logarithmic time complexity of the name matching algorithm. Adding these extra last names almost doubles the size of the name pool, taking us up to 151,671 last names, and adding gems like Bodnarchuk, Gathof, and Shcnitkey.

For the first names, the list from 2016 only includes babies born in 2016---in other words, modern baby names. Turns out that many widely-known antique names like Helga aren't on that list. Furthermore, the available data is insanely comprehensive, covering all birth years going back to 1880. Might as well merge all these lists, to get a mega-list of all baby names that were ever used in the past 138 years. And wow, all the names are tagged with the gender of the baby. We can do something with that too. No more girls named Robert or boys names Sally.

Yes, there are some unisex names, but we can easily tease them out of the mix. Each name is accompanied by an exact occurrence count for each gender in each year. If a name is more balanced than 80/20 in any year, we call it unisex. It's also interesting that the gender associated with certain names shifted over the past century. Charlie was exclusively male early on, but now it's more female than male.

The result is 7917 unisex names, 32,074 exclusively male names, and 58,411 exclusively female names. Why are there nearly twice as many female as male names? People apparently exercise more creativity when naming their girls. This was true to some extent even back in 1900, when there were 1500 male names and 2200 female names. But it's clear that baby name creativity has blown up for both genders since then, with 18,000 female names and 14,000 male names in 2017---we've gotten almost 10x more creative, or maybe just more diverse, in the past 100 years.

Anyway, these changes mean that there's a lot more first and last name variety available (welcome to the party, Helga), and also that your baby's name will auto-match to the closest available name for their gender, including unisex names.

There's also a small improvement to immersion, as your mother's naming speech will be auto-filled with your actual name. YOU ARE ROBEFJLSKDF might auto-correct to YOU ARE ROBERT, for example. The same is true if the name your mother tried to give you is already taken. If Lucy is taken currently, YOU ARE LUCY might auto-correct to YOU ARE LUCILE. So you don't need to mouse over yourself after naming to find out your actual name.

The other big thing is an improvement to the hint system. When actively tabbing through or filtering the hints, a helpful bouncing arrow highlights the closest target object in the world. No more mousing over a bunch of stuff when trying to figure out what a flint chip looks like. There have been many requests for visual crafting hints, but there are problems with auto-scaling huge objects (like the rubber tree) in an aesthetically appealing way. Visual crafting hints would mainly help you find the object that you're looking for, and this bouncing arrow may solve that problem even more thoroughly.

The arrows can also be leveraged by expert players who are searching far and wide for a rare object. Tab to a hint that requires a tarry spot, and then roam. It will be impossible to miss any tarry spot that passes by on your screen. Since these arrows are only activated when you're actively tabbing or filtering the hints, they'll be invisible during regular, moment-to-moment play.

And bugs have been fixed, including one last cause of grave duplication and spurious (!) off screen sound notifications (sorry for making you paranoid last week, folks).

And what about the changes made last week? Did they work to extend arc longevityl? We just had a record-setting arc, lasting 4+ days after the Eve window closed, as can be seen in this family population graph:

https://i.imgur.com/MNzSGNC.png

We're getting close!
[Link][8 Comments]






Update: The Posse
September 28, 2019

https://i.imgur.com/624Gp3V.png

The big changes this week focused mostly on griefing and long-term family preservation. The most recent arc lasted 67 hours, which is much better than before, but we're still not there yet. Ideally, an arc would last 5-7 days, to the point where we hit an interesting resource-exhaustion situation. The arc ends when there's only one family left, and families were lasting longer, but still dying out too quickly.

After looking at the data, it became clear that very few people were ever going to Donkeytown, even though there were plenty of curses being doled out. In fact, the most widely-cursed player had accumulated curses from 104 people, and even that extreme outlier barely went to Donkeytown. The fixed-radius blocking associated with curses---where someone you cursed is guaranteed to be born far away from you for the next seven days, wasn't working. Even if many of the living players had an incoming player cursed, their blocking radii wouldn't cover enough of the map. There could always be a crack for a heavily cursed player to slip through.

And it was clear that some of these griefing players were actively trying to kill off families to bring the arc to a swift end.

Now the blocking radius for a cursed player grows depending on how many living players have that incoming player cursed, growing by 100 tiles for each additional cursing player. If you try to get born during a time when 10 living players have you cursed, your blocked radius will cover the entire diagonal diameter of the rift, meaning that it's impossible for you to get born there, and you go straight to Donkeytown. However, as the number of living players who have cursed you rises, it becomes gradually harder and harder for you to get born in the rift, as you are pushed further and further away from more and more people. Thus, the more you bother people, the more likely you will be to end up far away from people or even in Donkeytown.

As an example, a recent sample showed that 13 living players had cursed that most-cursed player (the one with 104 curses). That player has gotten to the point where they will almost always be born in Donkeytown. They've bothered enough people that, day and night, there are always a bunch of bothered people online in the game at the same time.

Next, I took another look at killing, and how it gives lone griefers an advantage as they sneak around and pick people off. You now get a 3-second warning when someone targets you before they can actually kill you, and their murder-mouth sounds have a visual indicator when they are off-screen. Your character also shows a SHOCK face while they are targeted. So you can see them coming, with plenty of warning. Still, depending on how skillfully you move relative to them, they might be able to catch up to you. Furthermore, a lone griefer, using skilled movements, can often evade a determined group of players. This never felt right. The group should have a huge advantage over an individual, and a lone griefer shouldn't be able to get the jump on anyone.

The solution to this problem is the new posse movement system. If you're trying to kill someone, acting alone, you move slower than normal. If you join up with a larger and larger group, all targeting the same person, you move faster and faster as a group.

All of these changes make unilateral killing much harder. Your victim gets plenty of warning, and you can't catch them. However, a lone individual can still guard a choke-point or area, preventing anyone from passing through. Lone guards are good. Lone killers are bad. On the other hand, it is also much harder for a lone griefer to escape from a determined group, because the group speeds up. When the whole village decides that you need to go, they should be able to carry out justice without too much mucking around.

But even with these changes in place, I'm still worried about families dying out too quickly. Maybe flukes of baby distribution are still contributing factors. I decided to redo the baby algorithm yet again, this time always giving incoming babies to the family with the fewest fertile females after the Eve window closes. It used to be round-robin, but that kind of even distribution might not be enough to keep a struggling family alive. And so far, it seems to be working. Here's the family graph for three hours from the latest arc:

https://i.imgur.com/zcdqcfz.png

Oh, and one more really cool thing: you can now build boxes on property fences. They allow you to store things there, thus conserving space, but they also serve as pass-through channels, allowing you to pass stuff in and out of a fenced area without opening the gate.

https://i.imgur.com/mU002kc.png

Specialized work units are now possible. Get ready to apply those time and motion studies!
[Link][9 Comments]






Update: End Trigger
September 20, 2019

https://i.imgur.com/3dzZ0DL.png

Another week of glorious bug fixes. The list is still pretty long, but I made a dent in it.

Over the past few weeks, I've been watching the server-wide arcs rise and fall. More recently, the arcs have been getting shorter and shorter. The arc currently ends when there's only one family left, and families have been dying out very quickly.

For example, here's the family population graph of a recent arc:

https://i.imgur.com/yXFYI8W.png

Total server population is on the Y axis, and each family's portion of that total is represented by how thick their color band is. For example, the forest-green band represents the Kelderman family, which got thin after about an hour and a half, and then made a bit of a comeback after that before finally dying out. But what actually happened to the Keldermans? To help us answer this, let's take a look at Wondible's amazing family tree visualizer:

https://wondible.com/ohol-family-trees/#server_id=17&epoch=2&playerid=2076067

Some of their fate was player-driven, and that's fine. In fact, that's partially the point of an arc end condition: to put the fate of the server into the hands of the players. But we can also see a lot of rectangles at the end of their family tree. Rectangles are boys that cannot have babies themselves. Thus, it's possible for a family to die out simply due to a random fluke of genetics.

While this may be true in real life too, and is somewhat interesting, over the long haul, this particular fate is likely to befall every family eventually. When an assortment of families is what's keep the arc from ending, this kind of randomized attrition doesn't feel right, because it's completely outside the realm of player control.

So, among loads of fixes and improvements this week, I adjusted the gender distribution algorithm to force girl babies if a given family has less that three potentially fertile females left alive. With this change in place, we'll see how long the arcs last, and what the family population graphs look like, over the next week.

You can see the full list of server-side code fixes in the change log here:

https://github.com/jasonrohrer/OneLife/blob/master/documentation/changeLog.txt

This week's content fixes can be viewed here:

https://github.com/jasonrohrer/OneLifeData7/commits/master
[Link][8 Comments]






Update: War Report
September 13, 2019

https://i.imgur.com/fL1N3jK.png

I'm back from PAX West with a bunch of bug fixes and improvements. The arcs have generally been pretty stable during this time, lasting one to four days before we get down to a single family. I'm still not fully satisfied, and I'll be putting a lot more effort into making it even better in the future, but this is a good place to turn my attention to other matters, namely the enormous list of user-reported bugs that have built up. This week, I got through all of the reported and reproducible code bugs. Next week, I'll be tackling the list of content bugs.

The biggest change this week is the war report feature: mousing over someone from another family will now tell you if you're currently at war or at peace with that family. War status changes should also let you know, but what happens if you're born into a war or peace that was declared generations ago? Now you have a way of finding out.

The road-following code was also overhauled, and it now works perfectly in all situations, including diagonal roads that join other roads, double-backs, and so on. If there's a viable road ahead, you will follow it.

Other small fixes:

--Parked horse cart no longer overlaps weirdly with the object to the left

--You can paste text into chat with ctrl-v (requested by a player with brain damage who has trouble typing)

--Single-click set-down on surrounded tiles.

--No more ghost monument locations after an apocalypse.

--Fixed a glitch that allowed children to pick up swords and cars via swapping what they're holding.
[Link][4 Comments]






Update: Live from PAX West
August 30, 2019

https://i.imgur.com/QZvugpJ.jpg

I write to you from rainy Seattle.

If you're at PAX West, please stop by and say hello. I'm in the PAX Rising area, and I've got:

--500 Limited Edition OHOL purchase cards with unique QR codes (on sale for the first time at 25% off for PAX attendees only)

--Mofobert stickers

--Sandara posters

--Diamond Trust of London

https://i.imgur.com/6kWXj17.jpg

https://i.imgur.com/ExnLVhu.jpg

https://i.imgur.com/TXZYbnn.jpg

https://i.imgur.com/wJ6EhjG.jpg

The update went out on Wednesday evening, before I left, and it includes several improvements, which I will simply list here:

--Eve window remains open for 8 hours.

--Arc ends if we ever get down below two families.

--The bug causing the apocalypse whiteout to stall has been fixed, so families can easily survive the end of the arc now.

--Fixed a imprecision accumulation in server walk speed code that could potentially allow WASD mods to walk slightly faster.

--You can spend YUM to do hungry work, and you must always have a 5-hunger buffer when doing hungry work (for safety, so you don't starve immediately after).

--After the Eve window closes, babies are distributed to families round-robin, to prevent one family from getting baby starved.

--A new family population log has been added, so I can make nice graphs of families over the arc.

--Pine trees are no longer hungry work (softwood, naturally)

--You can eat carnitas straight.

--You can eat onions and tomatoes straight.

--You can deconstruct the track cart kit.
[Link][3 Comments]






[Prev][Next]
[Home] [Buy] [Wiki] [Food Stats] [Fail Stats] [Polls] [FAQ] [Artwork] [AHAP] [Credits]