A multiplayer survival game of parenting and civilization building. Get born to another player as your mother. Live an entire life in one hour. Have babies of your own in the form of other players. Leave a legacy for the next generation as you help to rebuild civilization from scratch.
Recent Reviews:
Mixed (119) - 64% of the 119 user reviews in the last 30 days are positive.
All Reviews:
Mostly Positive (749) - 79% of the 749 user reviews for this game are positive.
Release Date:
Nov 8, 2018

Sign in to add this item to your wishlist, follow it, or mark it as not interested

Buy One Hour One Life


Recent updates View all (18)

February 16

Weekly Update #49

Temperature Overhaul:

The problem of temperature in the game was much harder to solve than you might think. The old model was based on a thermodynamic cellular simulation, which would supposedly allow for heat from fires to be captured in rooms and flow out open doors. The model was accurate, but it was based on thermal conduction, not convection (which is much harder to simulate), and the result was hot areas right around heat sources, and cold areas everywhere else, even in enclosed buildings. In other words, buildings were pretty useless for keeping warm.

Clothing also fit into this simulation, but in a bit of a strange way (it served as extra insulation in the tile that you were standing on). Clothing would amplify any heat source in your tile, turning fires into extreme heat death traps. Finally, biomes were also part of the simulation, adding small heat sources (or sinks for cold biomes) at every cell in the simulation grid. Again, clothing, which insulated the center cell of the simulation grid (where you were standing), would also amplify biome heat. And biome heat effects would blend at biome boundaries (a thermal grid simulation is actually a form of blurring between the grid cells). This meant that there were near perfect areas at the boundaries between hot and cold biomes.

Players, being the rational folks that they are, reacted to the peculiarities of this thermal simulation by avoiding buildings, founding towns along desert boundaries, wearing minimal clothing, and generally not depending on heat sources for warmth. This was never my intention for the game, of course, but that's where things stood. I envisioned a game were buildings, clothing, and heat sources brought crucial advantages to a civilization, and all of the more advanced civilizations would depend on all three.

So, how could I fix this? A different thermal model of course, but what model? And if I wanted both hot and cold biomes (which make a lot of sense), how could I prevent exploitation of the boundaries? I really wanted there to be no "perfect" spot on the map that would make temperature regulation technology irrelevant. If such a spot existed, the smart players would find that, and settle there, always. Cold biomes should be too cold. Hot biomes should be too hot. There should be no "middle ground" in between.

First of all, many thanks to all of the players who engaged in a lengthy discussion in the forums. Also thanks go to my local designer friend Casey, who stuck with me through at least three hours of in-depth discussion about this topic (at the end of our first two-hour discussion, we had pages full of notes, diagrams, and graphs, but still no workable solution to the biome boundary problem).

Okay, now the solutions.

I should mention that what I'm calling "R value" here is different than the standard term as used in the insulation industry. My R value is a fractional heat retention value between 0 (no insulation that loses all heat) and 1 (perfect insulation). This makes it easier to reason about and program for. I suppose I should call it something else, but I don't know what to call it, so I've been calling it R.

First, for walls, I really want to simulate some kind of convection, so that heat spreads more evenly in indoor spaces. Instead of a cellular simulation, I'm now walking through the entire airspace around the player, flood-fill style, until I hit a boundary of insulating walls (or the edge of the 8x8 simulation grid). After that, I find the insulating boundaries, and compute an average R value for those boundaries. The heat sources inside that airspace (which may be the entire 8x8 grid, if there are no walls) produce heat which is spread evenly throughout the tiles of the airspace. That heat is modulated by the R-value of the boundaries of the airspace (if the average R value is 0.5, then half the heat is lost, and the rest is spread evenly in the enclosed space). Floors themselves count as part of the boundary of the space (if there's no floor in a tile, that tile counts as one of the air boundaries, thus reducing the average R value).

So what happens in this new model when you open a door? Suddenly, your airspace gets much bigger (the inside of your house plus the area outside your house), and your airspace boundary also gets bigger---and likely includes some air boundaries at the edge of the 8x8 simulation grid---so the average R value of the boundary decreases. Thus, opening a door, if a fire is running inside, will cause the house to get colder. Closing the door causes it to warm up again.

Thus, we're essentially modeling perfectly even convection throughout the entire enclosed airspace.

But shouldn't standing next to a fire also warm you up, even if there are no walls at all? Yes, but that's not due to convection. There's also a radiant component in the new model, which is based on your distance from each heat source that is in your airspace (which might included everything in the 8x8 simulation grid, if you are outside). So, getting close to a heat source, indoors or out, warms you intensely (perhaps too intensely, depending on the heat source). In other words, up close, radiant. Further away in a house, convection. The effect of radiant heat becomes negligible beyond a few tiles away.

Next, the biome effect is based only on the tile that you're currently standing on, and it's added into the heat calculation after the heat at your tile is computed based on heat sources and walls. If you're in an enclosed airspace, the biome heat contribution is modulated by the average R value of the airspace boundary, but only if the entire airspace also has floors. This means that an enclosed house with a floor can make a hot biome cooler, and a colder-than-normal biome, like the polar biome, warmer.

Next, clothes are applied in a separate part of the code, and they slow the transition from your body heat level to the environmental heat level (as computed based on walls, heat sources, and biome). If you're naked, you change temperatures pretty quickly. If you're fully clothed, you change temperatures very slowly. Thus, you can warm up in a house, near a fire, until you are just right, and then put on clothes before a journey to "hold it in" for a long time, and keep yourself close to perfect along the way.

And finally, the hard part: biome boundaries. As the new system is described so far, the old boundary-blending issue is fixed (because only your current biome tile contributes to your heat equation, without blending), but an exploit is still possible: by jumping back and forth across a boundary, between a hot and cold biome, you could warm yourself up to perfect temperature without fire, clothes, or walls.

So, I added a system for thermal shocks. This occurs whenever you go from a too-cold biome into a too-hot biome, or vice versa. Your temperature instantly jumps from the cold side of the scale to the hot side, right to the new biome's target temperature (or from hot to cold, if crossing the other way). This shock effect is also modulated by clothing. More and better clothing reduces the magnitude of this shock. Furthermore, the shock is never allowed to bring you closer to perfect on the other side of the temperature scale than you were before crossing. So if perfect is 0.5, and you were at 0.3, you will jump to at least 0.7 when you cross into a hot biome, no matter what clothes you are wearing (if you're naked, you might jump all the way up to 0.9, though, so clothing still helps).

This means that you can never improve your food consumption rate by crossing between hot and cold biomes. In the very best case, your consumption rate will remain the same, but it will usually get a bit worse (and if you're naked, it might get a lot worse).

There is also still a small body heat effect inside clothing, so in a cold biome, clothing will gradually warm you up over time. This effect is somewhat larger than it was before. The general idea is that, in cold biomes, clothing gets you 1/3 of the way to perfect, while fire and walls take you the rest of the way there. If you actually want to work in one area and remain at a perfect temperature the entire time, you're going to need all three bits of technology.

One other problem in the old system was that the desert, while hot, was not as hot as the other biomes were cold. The jungle was too close to perfect, and the mosquitoes didn't offer enough of a trade-off. So the jungle is now as hot as the other biomes were cold (moving between prairie and jungle now results in no change to your hunger rate), while desert is now as hot as the polar biome is cold. You've always been freezing to death in the snow, and you are now cooking in the desert. Think of it like hot snow.

The other biomes remain unchanged for the naked player. Thus, the game isn't really any harder now than it was before, unless you count the loss of the desert-boundary exploit as making the game harder (yes, that was easy, but the game was never supposed to be easy like that). Clothing and walls are so much more helpful now, that the game might even be easier, ignoring the old exploit.

Here's hoping that the new system leads players toward advanced civilizations full of heated buildings and clothed residents.
22 comments Read more

February 10

Weekly Update #48

Client Lag Fix:

What made this bug so hard to find and fix was the fact that it affected so few people, relatively speaking. However, for the affected people, it affected them all the time, and pretty much ruined the game for them.

The symptom: in busy areas, apparent network lag would grow and grow, resulting in up to twenty seconds of delay between trying to do something (like pick a berry) and have the action resolve (like have the berry in your hand). On its face, this sounds like classic network lag. The first thought is that the server isn't keeping up with demand. However, other people playing in the same area were not experiencing lag. In fact, the affected player would often ask about lag, in-game, and be told by others that there was no lag for them. Also, if the server was being bogged down, the lag would be experienced everywhere in the game world, not just in busy areas, because all areas are processed in the same loop.

Maybe they were in a remote part of the real world. Maybe they were on spotty WiFi. The problem would often clear itself up instantly if they walked out of the busy areas. And certainly, the server is sending them fewer messages out there, because it filters the messages based on what is relevant to your location. In a busy city, you need to receive a lot of information, because so many people are walking around. In the wilderness, there's much less change happening. So this symptom was generally consistent with network lag.

A while back, I built a /PING and /FPS command into the game, so that people could run tests if they were experiencing lag. Sure enough, during these lag situations, ping times would balloon. Normal ping times in the US are below 100ms, and not more than 400ms anywhere in the world. But during lag, the ping would grow to five, ten, or even twenty seconds. That's really bad, and probably transcends any normal network lag.

And for these people, things have only gotten worse when we moved everyone to bigserver2. Big cities are much more common, so many of the affected people were experiencing unplayable lag almost every life. Of course, for everyone else---those who never experienced lag---bigserver2 was great.

But finally, almost miraculously, I experienced this issue myself for the first time this week. A unicorn! I was playing in a busy city, on my slow dev laptop with a weak GPU, and sure enough lag. Bad lag. Really bad lag. My in-game ping time grew to more than 14 seconds. The game was totally unplayable.

During this time, I also noticed that my FPS dropped from around 60 down to 40 or so. Frame rate and network lag aren't necessarily related, but my lag was very hard to reproduce---it would come and go seemingly at random, even in the big city, depending on where I walked---and it seemed to be correlated with this drop in FPS.

I set up a chaotic Eve-only city on bigserver2 on Friday to conduct a real stress test. 120 players all spawning in the same spot (0,0) is no joke, and I could very consistently trigger lag on my slow dev laptop.

I also found that my gaming rig would not see lag in the same area, but it is running at a solid 85 FPS (odd, I know, but it's a CRT). So, same network, different CPU and GPU, higher FPS, no lag. So yeah, with proper hardware, the client can easily handle 120 players all in the same area. It was chaos, but buttery smooth chaos.

Someone pointed out that outside-game-pings (using the command line) aren't necessarily slow during an in-game lag, and I was able to confirm this. Someone else suggested that I sniff the raw network packets and figure out exactly how quickly the server was responding to my PING with a PONG---just to rule out server-side lag. Sure enough, while my client took 14 seconds to register the PONG, the PONG arrived on the network within the normal 70 ms, even on the slow dev laptop. There was some kind of networking issue inside the client.

I spent quite a bit of time testing my underlying networking code and looking for reasons that network messages might get backed up, but found no issue in isolated network tests. I also considered some kind of kernel networking issue (my laptop is running Linux, while my gaming rig tests were on Windows7). No dice.

Meanwhile, someone else had been able to pinpoint the exact problem in the client, and they posted their fix in an old, lingering Github issue. Finally, someone drew my attention to this fix, which was rather hidden on the Github side.

JRuldolf, we all owe you one!

Turns out that this problem has been with us since an update back in October, before the Steam release, when message frames were added. A frame groups messages together that occur during the same server processing step, forcing the client to wait to react to any of these messages until all the messages in the frame arrive. This prevents, for example, a message about a map change from being processed before the matching player update is received (if a player dumps a bowl of water into a bucket, the bucket on the map changes, and so does the bowl in their hand, and there are two separate messages, but they only make sense if they occur client-side at the same time).

This frame system was great, and fixed a heap of potential inconsistencies in client behavior.

However, there was also a bug in the way that frames were processed. Each client step (each rendering frame), the client would read the next message and check if it was an end-of-frame message. If not, it would put the message in the holding queue and go on to the next rendering step.

You can see how this can cause trouble when message frames contain more and more messages (which they do in busy areas): a frame with five messages takes at least five client frames to fully receive, even if all five messages have arrived, because we only check one message per frame. Once the 6th message is checked, the end of frame message, we call the frame ready, and process all five messages together.

What we need to do, instead, is loop as long as any messages are available, checking for the end-of-frame message, but if it's not there, continuing on to the next message, until no more received messages are available. Thus, we process all received messages every client frame, regardless of how long the message frame is. This even allows us to process multiple server message frames on a single client rendering frame, if several server frames are waiting client-side.

If we don't do this, during times with high message rates and large, multi-message frames, we can see how a message backlog would build up. Assuming, of course, that more than 60 messages were arriving per second.

And if the FPS drops on top of that, you can see how it would get even worse, because we are running even fewer processing steps per second. So players with weaker GPUs were pretty much experiencing the perfect storm in busy areas. Lots more messages, and a slower client-side rendering loop that was effectively only processing one message per rendering frame.

The fix was literally two lines, putting a loop in there where it should be.

And suddenly, the client could handle the very busiest areas with absolutely no network lag. Even if I artificially reduced the frame rate to 5 FPS, the game was completely playable in busy areas (yes, it was choppy, but each action was executed instantly, with no lag). Before the fix, such a low frame rate would spell disaster in a busy area.

Now, how did such a devastating yet simple bug go unnoticed for so long? Well, as long as the frame rate is high enough, and the incoming message rate is low enough, it generally doesn't matter. We're processing at least one message every frame, and 60 messages a second is a lot, so we usually keep up, even if we don't process all available messages as soon as we have them. I didn't write the code this way on purpose---the original code, before message frames were added, intentionally processed all available messages every rendering frame. But the implementation of message frames quietly subverted this intention.

The move to bigserver2 made this very rare bug less rare, because the cities got bigger, and the message rate higher, causing slightly more people to experience the issue. Including, finally and thankfully, me.

Bug fixes take a long time, but they are worth it. More bug fixes next week. The plan is to get clothing and heating working in a more sensible way.
8 comments Read more


“This game broke my heart and restored my faith in humanity.”
Vice Motherboard

“The stories you create are intimate, complex and multidimensional... a moving microcosm of the human condition.”

About This Game

A multiplayer survival game of parenting and civilization building. Get born to another player as your mother. Live an entire life in one hour. Have babies of your own in the form of other players. Leave a legacy for the next generation as you help to rebuild civilization from scratch.

Hey folks, I'm Jason Rohrer, and I've been working on One Hour One Life for more than three years. I've been doing everything myself---I drew all the graphics on paper with pens and markers, I coded the entire engine from scratch, I composed and performed all of the music, and I even made all of the sound effects. It's a very personal game, and it's really unlike anything else that's out there. It's also a huge game---over 1300 fully interactive, craftable objects already. And it's only getting bigger, with weekly updates adding new things all the time. The game was initially released on my own website in February of 2018, and over the intervening months, I released 29 updates off-Steam. I've promised to keep releasing weekly update for at least the next two years, with the end goal of making the largest, most comprehensive crafting game in history.

Okay, so what about the game itself?

First of all, you only live for an hour, where each minute marks a passing year. You join the game server as a newborn baby, and some other randomly-chosen player is your mother. You depend on her for your survival. And why will she be willing to waste her valuable time and resources to keep you alive? Because she's going to die in an hour just like everyone else, and if she wants what she accomplishes in her lifetime to have any meaning, then the next generation (aka, you) is her only hope. And if you survive into adulthood, you may get the chance to have babies of your own---other players, just joining the server---and those babies will be the next generation that gives meaning to your own life accomplishments.

Across this ever-growing family tree of generations, players are collectively conducting an enormous project: they are rebuilding civilization from scratch. The online game world starts out as a near-infinite expanse of wilderness (four billion meters wide from east to west, and four billion meters wide from north to south, with a total surface area of over 18,000,000,000,000,000,000 square meters, or 36,000 times bigger than Earth). The very first player to join the server is Eve, and she starts out in the wilderness as the root of the family tree. Eve and her immediate offspring lay the foundation for the future civilization, perhaps making a few primitive tools, cooking basic foods, and starting a small farm as they scrape out a meager existence before dying. Future generations will build on this primitive foundation, eventually mastering more and more advanced technology, including domesticated animals, metal working, permanent buildings, and transportation networks.

But as real-life history has shown, civilization is fragile. A generation that is born into the lap of luxury---on the backs of their ancestors' hard-won accomplishments---can just as easily squander their inheritance as build upon it. Key resources run out over time, so careful management, planning, and organization are necessary to prevent an inevitable collapse. Thus, the game graduates from the individual challenge of primitive survival in the early stages to a group organizational and leadership challenge in the later stages. How do rules and procedures for group survival propagate across multiple generations? What did our great grandparents have in mind for this village?

The main mode in the game involves being born as a helpless baby to another player as your mother, but you can also play with your friends as twins, triplets, or quadruplets. One baby is hard enough to take care of---any mother that can successfully take care of quadruplets deserves the eternal gratitude of you and your friends.

All of this is happening on my own centrally-managed, persistent servers, and your purchase includes a lifetime account on these official servers. After you buy the game, you can instantly connect to this world with no configuration or server set-up. It all just works. You also get access to the full source code, including the server code. Technically-minded folks can run their own private servers, or even use the powerful content editor to make their own mods.

I hope you'll join us as this sprawling civilization-building experiment continues to unfold. Many thousands of players have already collectively lived over 400,000 hours in this endlessly-changing world so far. Before the Steam release, the average playtime for each player was 17 hours, with dozens of players logging over 500 hours each, and 94% positive off-Steam player reviews. This is a deep and rich game already, and there are still hundreds of content updates to come.

No two lives are ever the same, and a new story always awaits on the other side of the [GET REBORN] button.

Jason Rohrer
October 2018
Davis, California

System Requirements

    • OS: Windows XP or newer
    • Processor: 1.7+ GHz or better
    • Memory: 2 GB RAM
    • Graphics: GeForce G210M or better; 256 MB or higher
    • Network: Broadband Internet connection
    • Storage: 250 MB available space
    • Sound Card: Any

What Curators Say

37 Curators have reviewed this product. Click here to see them.

Customer reviews

High Volume of Reviews Detected
Exclude  or  View Only
Review Type

Purchase Type


Date Range
To view reviews within a date range, please click and drag a selection on a graph above or click on a specific bar.

Show graph

Display As:
Review Beta NEW!
When enabled, will sort reviews by new Helpfulness score. Read more about it in the blog post.
Show graph
Hide graph
Review Helpfulness Beta Enabled
There are no more reviews that match the filters set above
Adjust the filters above to see other reviews
Loading reviews...