One Hour One Life News

I do have a 102 fever right now, so I'll keep it brief (gotta go lay down).

This week's update adds one new major feature, sounds associated with the "kill face" that you make when targeting someone for murder. You can hear them when they enter that state, and you can hear them as they come at you. No more griefers sneaking around off-screen and pouncing.

Polls are also in-game and working, but most of you have noticed that already.

The life limit feature has been tweaked a lot. You now get 12 lives max, with one earned every 20 minutes. With the old 60-minute system, unless you lived 60 minutes every time, you'd always see your count going down a bit, and even if you lived 60, the count would stay the same and not rise. Now your count will generally rise as you play, quickly recovering from any short lives you had.

Also, new players no longer have bonus lives. This was confusing for some, and meant that new players saw a number going down and never going up, which is discouraging. Believe it or not, some players were so angry over their confusion that one is threatening me with legal action over this change. Ah, the adventurous life of a solo game dev! Contesting a $20 lawsuit in small claims court is going to be interesting.

So, new players, like everyone else, will generally see their count going up as they play. Good stuff. And yes, this system will continue to be adjusted in the future. As with the curse system, I kinda see it as a place-holder solution until the heart of the game is adjusted in other ways to make it an unnecessary feature.

A few bugs have been fixed, and there's a major quality-of-life improvement with building stakes. The floor stakes are the first transition (duh, you build O(N^2) floors for every O(N) walls), not to mention the tedium of building long roads. Also, there's always a common stake in the middle as the other stakes move around, meaning you can keep your mouse in the center when cycling through (instead of the hitbox changing entirely with each click).

I spent a good portion of the week on deep design work, thinking about this core problem: how can you really CARE about the survival of your immediate family members? In real life, you'd do anything to save your child or grandchild. In this game, you just kinda shrug and move on. This reduces the potential variety of family-based stories.

The current idea is to add a kind of genetic score to the game, attached to your account, based on the weighted success of your most-recent in-game relatives. They'll be weighted geometrically by birth time, meaning that the success of your youngest grandchild will be worth more than your oldest child (just like real life, where the littlest ones always are the priority, for good reason). Men will base this on the success of their nieces and nephews (the gay uncle gene), and of course your own success will count too. (Success means longevity, by the way.)

There will be a ranking for these genetic scores, so you'll be able to compare with others, and there will also be an in-game bonus for high scores. Currently, the idea (proposed by forum-member Wondible) is that the degradation of your old-age food bar is reduced (hey, you got good genes!). If you manage a perfect score (close to impossible), your food bar will remain at peak capacity all the way until you die. It will be strictly a bonus, and won't negatively affect anyone who gets a low score (the normal age-based capacity degradation will still happen).

Here's a little graph of possible weightings that each sum to 1, where X=0 is your most recently born relative (grandchild or whatever), and X=10 is your 11th most recently born, etc. By varying the severity of this curve, we can control how much more you care about the youngest members of your family.



I'm currently leaning toward the red (middle) curve.

Your mother and grandmother will count a bit too (but less, because they were born so long ago), so there's a mutual benefit effect to helping each other survive.

Now I'm off to bed. Well, actually, my kids are waiting to watch Porco Rosso tonight. Nothing like anime on a high fever!

An update like this is long overdue. Thanks to all of you for reporting everything you reported. As a result, a pretty long list of issues had built up. This week, I got through all of the known and reproducible issues affecting the game engine and code. A few bigger fixes are worth mentioning specifically. If you've ever seen a "ghost" player standing there, aging, who no one else can see, the source of that problem has finally been found and fixed (it was caused by someone passing through your area, going at least 64 tiles in one go without ever stopping their walk). The issue with animals and other movable items not respawning when nature reclaims an area has been fixed. And most importantly, a server message overload that was triggered when you targeted a family member with a sword has been fixed. That overload was so extreme that it caused nearby clients to get bogged down and disconnect. A full list of the changes can be seen here:

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

Next week, I'll be focused on fixing all of the known content issues. Again, a lot have piled up (118, currently).

As always, if you find an issue with the game engine or code, please report it here:

https://github.com/jasonrohrer/OneLife/issues

And if you find an issue with the game content (like a missing transition, or something not containable that should be), please report it here:

https://github.com/jasonrohrer/OneLifeData7/issues

There have been a lot of huge changes to the structure of the game over the past month, so this is a good place to take a step back and let the game breath a bit with these big changes while I focus on fixing reported issues.

Life has been cheap in the game for a very long time. It always bugged me. Death is inevitably going to be somewhat meaningless, but it was a bit too meaningless. Yes, in any game where there's reincarnation, players are going to leverage that to achieve various goals. However, there should still be some trade-offs and difficult choices involved. Infinite and free is boring, because it makes you not need to decide.

The original concept for this game was actually One Dollar One Hour One Life, and that would have dealt with this problem quite squarely, while also committing commercial suicide in the process. I've also toyed with only allowing one life per player per hour, but that also seems too extreme.

There's a wide spectrum between those extreme options and life being completely free/infinite, though. It needs to have some cost, so you feel the pain of death a bit more, and so you at least have a more interesting choice to make when you choose death on purpose in order to get born into a different life. The solution is to only give you one life per hour, but let the lives build up over time, so that you have a buffer.

These numbers will be adjusted in the future, but currently, you start with 24 lives, and you earn one new life every hour whenever you dip below 12 lives. You earn lives this way day or night, whether you are playing or not. Most people will build back up to a full bank of 12 lives every night while they're sleeping. You start with 24 to give brand new players some cushion as they learn the game.

It's amazing how many of the long-term problems in the game are in some way related to life being too cheap. From griefing, to baby suicide, to too many Eves. We've tried a lot of laser-focused solutions to these specific problems, but the over-arching problem of cheap life remained.

To accompany this change, the lineage/area ban on /DIE is back, mother birth cooldown has been restored to the way it used to be, and the Eve spiral is back, replacing the newer Eve grid placement. The spiral now works along with the ancient map culling, resetting back to the center of the map once it has been reclaimed by nature, so Eves will come closer together periodically, instead of just once a week when the servers restart. Finally, roads, along with stone walls, are not reclaimed by nature, so you can build long-term routes across the map, even as civilizations die out along those routes. This should help distant villages continue to find each other over time.

And snowballs no longer make you drop what you are holding.

John Serafin was one heck of an interesting guy. He always had a funny story to tell, or a wisecrack, or a hot take, and always in that amazing Queens accent of his. He was a real character, and he knew it. He always called me a character too, and I knew that I was. How often our friendly verbal fencing matches---as he called them---ended with him shouting, "Jeez, Jason, come on!" in exuberant exasperation. He was unusually tall, but not as tall as me, and it took him years to get over the extra four inches that I had over him.

The first time he met me---me, the man who would eventually marry his only daughter---he approached me with a stern look on his face, and said in a gruff voice, "Who's this guy?" I was frozen for a second, but then he cracked a smile and started laughing. By the end of that first evening, he and I were getting along famously. He was impressed that I was driving a Ford Taurus---that's a dependable car!---instead of a rusted out piece of junk. But that conversation about my Ford Taurus was just the beginning.

Above everything else, John Serafin was a car man. He lived through some interesting times on Long Island back in the day, and he longed for a return to a more elegant era. The old money. The sprawling estates. The hired help. The glistening lights of distant garden parties shimmering across the still evening waters of Long Island Sound. The mystery and romance of it all. But most of all the cars, those glorious cars of his childhood. Cars that his impoverished family didn't even have---just blurs of chrome and metallic fleck paint zooming past him as a small boy in his rough Queens neighborhood. The cars from that era were huge, heavy, and all curves. We get excited about a V6 today, but how about a V8, a V12, or even a V16?

Did I say he was a car man? That was too vague. John Serafin was a Cadillac man. Cadillac was his make and his life-long passion. He eventually realized his dream of owning one of those glistening marvels that was so out of reach during his childhood. Here is his baby, a 1935 Cadillac Fleetwood convertible sedan:



All original parts and paint. Cracking original rubber gaskets around the doors. He claimed it was a one-of-a-kind, a V8 edition in a year when no other V8s were made. When I said these things are heavy, I meant it: a good portion of the framing is made out of solid wood. I got to ride in it. At one point, late in his life, when his legs started to fail him and he could no longer operate the clutch, he even let me drive it. This was indeed a machine from a different era---a time when a trip to the mostly-deserted tip of Long Island on the rustic parkways was a daring adventure, and a time when flat tires were the norm. That is the Long Island we read about in the great novels of the past century.

But he was more than just a car guy. He was the father of my darling wife. He was a grandfather of my three boys. He was my beloved pal and verbal fencing partner---that initially gruff guy who quickly welcomed me, this tall, strange, seemingly unemployed young man who was in love with his daughter, into his family with open arms.

John Serafin, the Long Island Cadillac man, died last night. Goodbye sir, I'm going to miss you.


With that important story told, I'll now turn my attention to the update. It comes to you a day early, because we're catching a plane tomorrow for the funeral. Needless to say, there probably won't be an update next week.

The biggest changes are to storage. Baskets no longer decay. Yes really. I finally caved on that sore point after a whole year of holding the line. Looking through the existing content, I found 67 different bowls of stuff that weren't containable but probably, logically, should be. That's a lot of stuff that used to sit on the ground, but can go in a box now. I've also added a new kind of box, a slot box, that can be used to store 10 small items (instead of four big items like the regular box). Before, the only way to store that many small items in one spot was to nest baskets in boxes, which made the items fiddly to access.

Before this update, there were over 1000 Eves every day, and it was clear that many players were abusing the /DIE feature to ban themselves from all family lines so that they could play as Eve. These "unnecessary Eves" were creating too many families, spreading babies out into too many doomed family lines, and starving the existing, long-running lines of necessary babies. Even worse, with the latest close-together changes, many of these Eves were griefing existing towns---and an Eve has very little to lose.

The effect of /DIE as a baby has been changed, in that it no longer triggers a lineage ban, but instead adds that family to your temporary skip list. Once you've skipped through all families, and there are none left to try, your skip list clears, and you go back to being born through all the same families again. In other words, you can't use /DIE to become Eve anymore. You only become Eve if another Eve is really needed (there are actually no available mothers around to have you).

This cut the number of Eves down by a factor of 10x, which will take a huge bite out of the above problems.

There has also been a problem of growing clutter over time, with everyone close together, and a lack of greener pastures for fresh starts. A new long-term map culling system has been added, where any 100x100 region that hasn't been seen by anyone for at least eight hours slowly goes back to nature, one tile at a time. The only things that survive the ravages of nature are stone walls, which remain in place, with trees regrowing up inside of the outlines of former building. This culling should help to create some greener pastures for new Eves. By the way, this only happens on servers with 15 or more simultaneous players.

Two client-side movement glitches, affecting the movement of other players, have been fixed. Hopefully, rubber-banding when trying to follow someone on a long walk is a thing of the past.

This game was never meant to feature a full-fledged combat system. The protocol was designed to allow movement and actions from hundreds of simultaneous players with as few messages as possible, ensuring logical consistency (two players can't both pick up the same object at the same time and cause the object to duplicate), but not realtime interaction guarantees. In fact, the protocol was design with extreme and variable latency in mind, because I always intended players from around the world to connect to the same server. One of my test cases involves using the tools TC and NETEM to manually insert up to 2.5 seconds of latency for all messages sent to my test server. The game still mostly works, even in those extreme network conditions.

So why is there combat in the game at all, then? Because it's necessary for society to function. How can you have rules or laws if you can't enforce them? How can you enforce anything without, well, using force? So yes, it would be easy enough for me to remove combat from the game entirely---just a few mouse clicks. But then the whole thing would fall apart, and the game would be ruled and ruined by griefers, happily ever after.

As a simple example of an endless annoyance: you set down a tool that you are busy working with, and a griefer grabs it and won't give it back. This is kindergarten stuff, but it graduates to petty or even grand theft in the adult world, and in any case, we solve these issues by adjudicated force, at the end of the day. But let's say we want no violence in our game. How do you deal with the person who took your tool and won't give it back?

A game could "solve" this problem for you---and many games have tried---via a very detailed system of hard-coded privileges and rights and transfer operations, essentially hard-wiring a legal system into the fabric of the game itself. Your tool would have an owner list, and that other player couldn't touch that tool unless you added them to the list, and they can't add other people unless you also add them to the admin list. All to just lend someone a tool. If this sounds fiddly and tedious, you're right. We might call such a design a "trust system," but is is anything but, as I will explain in a bit.

Much simpler to let an understanding develop between players---who was using the tool first, when it's acceptable to grab it yourself, and when you should ask first---and give the player the power of force-in-numbers (in other words, law) if that understanding is repeatedly violated. If you say, "Don't plant wheat here, I'm tilling these rows for milkweed," it's expected that the other person will listen. If they don't listen, you complain to them, and warn them. If they keep on with their violations, you get the backing of the town elders, and you take it to the next level. After all, they can't keep violating the community standards if they're dead. Unvarnished, it sounds barbaric. But that principle is at the beating heart of every functioning society in the real world. The less-barbaric-sounding version is imprisonment or banishment, but even those are carried out at weapon-point, for obvious reasons.

Even without the will of the majority to back you up, you can see how an understanding could develop between two isolated players over time, and how that understanding could blossom into a real sense of trust. Real trust comes from freedom and power: you could hurt me if you wanted to, but you choose not to. If you are powerless, I may not need to worry about you, but that doesn't mean that I develop a trust with you. Two free wolves develop a real trust. Two toothless dogs stuck in neighboring cages have no need for trust. That's why a hard-coded trust system, in the place of powerful and free players, actually squashes trust instead of fostering it.

And that is what One Hour One Life is about, from its very first moments onward. Two strangers trusting each other, sacrificing short-term gain for long-haul mutual benefit. Mother and baby are the basic example. There's no hard-coded guarantee that you won't betray me, but I have your back, and you have mine, and you haven't betrayed me for the past 30 minutes, so even though you're a complete stranger to me, I sense that I'm growing to know you. And just maybe---dare I say it---I'm growing to love you. Because you could kill me, but you choose not to.

All that said, for this to function, we don't need a full-fledged combat system. Violence can be a logical operation, or at least it should be, and was meant to be, in this game. If I choose to kill you, I should be able to do that without any execution skill required, and regardless of network latency and so on.

Which brings us to that infamous dancing griefer. Because the movement protocol is not a realtime one, it was possible to exploit it to make yourself nearly impossible to kill. The server essentially had no "sync points" between players in the system until the players landed at the end of their movement. Okay, the player's movement just ended, and we know where the player is standing, for real, and all clients and server agree about that. Now they can execute an action on an neighboring tile. Mid-move, due to variable latency, all bets are off about where a player actually is on each client screen. Griefers could exploit this by moving continuously.

Even if the protocol didn't work this way, a moving target is still way harder to click. And what happens if you misclick? Well, you just right clicked on the ground, which means you just dropped your weapon. Trying to finally hit a dancing griefer was an absolute click-fest of frustration. So even if the town elders have collectively agreed that this person needs to go, they had trouble carrying out their decision. And the griefer, who could sneak up on an unsuspecting person who wasn't busy dancing, would get the jump on each victim and be able to land the kill.

This update changes the semantics of the client KILL action.

It used to be an isolated action that would either succeed or fail depending on where you clicked and whether the server believed that the person was actually there and in range.

Now KILL is a state, not an action, and SHIFT-right-click puts you into that state, with essentially a death warrant for whoever was closest to your mouse when you clicked. You get a forced-ANGRY face when you're in this state, and you can still move around freely. But if you ever cross paths with your target server-side, so that the target of your request is in range of your weapon, the kill action is executed instantly.

This comes as close to a logical operation as we're ever going to get, while still preserving the effects of weapons with different ranges. If you kill-target someone with your bow who is in a locked room, and you stand by the door, the arrow will fire instantly as soon as the door is opened. If you target someone outside the gate with your sword, and then stand by the gate, you will attack them instantly the moment they walk through the choke point.

You can cancel this state by putting your weapon away momentarily, and your angry face will return to normal. The face also gives the target some warning about your intentions---and of course, it can be bluffed with the usual angry emote.

This is a pretty big change, and it will dramatically change town griefing dynamics. But there are some other big changes beyond that.

The temperature system in buildings has been improved again. Now the heat simulation map is 13x13 instead of 8x8, allowing larger buildings to function as insulated spaces. Furthermore, an enclosed building acts as a direct temperature bonus on its own, and also doubles the effectiveness of the clothing that you're wearing. So buildings do more than just hold in the heat of a fire. The best way to think about it is that they reduce some kind of inherent wind chill in cold areas of the world. But for this to work, you have to be completely indoors, which means walls on all sides and corners, along with a full floor, and along with a closed door. If the door stays open too long, the wind will blow in, making you colder slowly over time.

The way last names are passed down to babies, especially in the case of a generation gap where no name is given, has been standardized. This should fix the lost-family-name bug.

Laying tracks for rail carts is now a lot cheaper---one kit can lay six tracks instead of just one. Gates can be built across roads again, and unused property twig bundles decay away quickly, so you don't need to spend time cleaning them up. You can finally move bowls of sterile pads around---mobile medicine can be a thing now.

Next week, I'll be tackling Eve overload around existing cities, and also the balance between close towns and stripped natural resources.