[Home] [Buy] [News] [Family Trees] [Photos] [Update Log] [Forums] [Tech Tree] [Wiki]
Update: Sweet and Spicy
March 29, 2019


Back from GDC with a bang. This is the largest content update in a while, with over 100 new objects to grow, catch, cook, and eat. And all this from only three new naturally-occurring objects.

What else? Spring loaded doors for your kitchen. That whole GDC basket horse cart right-click bug has been fixed for real client-side. Email-based family tree searches are no longer public (access your personal family trees from the button on the login screen or on your personal download page), so people can't spy on you anymore if they know your email. Animals no longer spawn outside their home biome along biome boundaries. Goodbye, arctic snakes and desert penguins. It was fun while it lasted.

And now for a tale of a funny lurking bug situation. Some of you may have noticed that recently, the whole shebang has been going down like clockwork at 5 am EST for about five solid minutes. Website, forums, login server, everything. I'm asleep during that time, so I didn't notice, and no one bothered to email me about it. Not sure how long this had been going on.

Turns out that 5am is the time when the various backup processes run, and one of these accesses the main MySQL database with mysql dump to back it up. That backup might be locking out other database requests, which would affect the website any everything else. But five minutes is a long time. Turns out that the review/stats server log table had ballooned to over 2 GB in size, with 220 million entries. Uh, yeah, that would take a while to extract with mysqldump. Turns out that it was filled to the brim with bad requests by other servers for non-customers. What other servers? From the IP addresses, these were Chinese servers. To the tune of 300,000 bad requests per day, and each one getting logged. The mobile developers apparently forgot to switch this stat-reporting feature off in their Chinese servers, which means that every time a Chinese player lives a life, I get hammered with a bad "log stats" request from their servers.

And yes, they are the biggest fish in this pond, but there are other bad requests getting logged from small-time servers too, most likely private servers being run by individuals.

First of all, I probably shouldn't be logging every bad request that comes in, since it's a waste of disk space, and I have no control over how many bad requests come in. So, that's fixed, and these logs have been cleared, making them tiny again. Now the backup mysqldump takes 3 seconds instead of 5 minutes, and it doesn't seem to block anything (it's supposed to set a read-only lock anyway, which should at least allow the website and such to load).

I also reached out to the mobile devs to ask them to knock it off. Their Chinese servers are being run by a third party, but I'm hopeful that this deluge of requests will end soon. Anyway, 300,000 lives a day is a lot. Apparently the game is popular in China.

But the fact that so many servers, in general, are submitting requests to me by accident is a bad sign. Yeah, I guess I made "reporting" the default behavior in the public server code on github, which means that anyone who is not paying attention when they set up a server will end up hitting me with reporting requests forever. Because these other servers don't have the secret key, the requests will be rejected, of course, but they're still a waste of time and bandwidth for everyone involved. I can imagine a nightmare scenario in the future where there are 1000s of private servers, and their collective accidental reporting traffic combined results in a DDOS attack. So, the public server code has been fixed to not report by default. Update your server code, folks.
[Link][14 Comments]

Update: More Emotions
March 16, 2019


The past few weeks have been an absolute whirlwind.

First of all, preparations for my GDC talk are complete. I'm actually giving the talk just two days from now. You can read the full description at the link below, but keep the intended audience in mind: "Anyone who isn't ready to roll over and die just yet." Hopefully, that describes you.


Also in the past few weeks: a huge, confusing debate about the boundaries of the public domain and authorship, as it concerns One Hour One Life and the unofficial mobile adaptation. There are very few precedents here, and lots of different opinions. You can get a taste of this here, in what became one of the longest and most viewed threads in OHOL forum history:


You can also read the opposing point of view, in which I almost became a Sith Lord:


There are two upshots of this discussion. First, the mobile developers have decided to eliminate this confusion in the future by hard-forking the game. They will be eventually operating under their own unique title, and they've already started the process of designing their own mascot character, and some of their own background textures, which you can see as sample of here:


I recently realized that the "mascot" they had been using in their mobile icon---my Original Eve character---happens to be my cartoon rendition of my own mother:


The hard fork will also involve a content fork from here on out, so my weekly updates will no longer be rolled directly into their game.

The second upshot is that I've clarified my stance on copyright, moral rights, personal rights, and trademark. In the past, I had only thought about copyright, and decided specifically that I did not want to wield it. Over the past fifteen years, I've never faced the situation of a direct competitor using my work to make a almost-identical service that would be confusing to end users. When I placed my work in the public domain, I never thought, "Hey, that means that someday, people may widely believe that someone else is the original author of my work." Furthermore, I realized that competitors have a huge unfair advantage against me, as I toil away on weekly content updates that they can roll into their product with almost no work at all. Finally, I realized that the ultimate financial nightmare---a completely free but identical OHOL PC service, maybe even operating on Steam---was a possibility, unless I clarified things. Yes, I was hoping Steam wouldn't allow such a thing, but if I'm serious about retaining no rights, that's an intellectually dishonest thing to be hoping. I've decided that trademark is the best tool to use to deal with such issues. My clarified "no_copyright" file can be seen here:


To summarize: you can do whatever you want with my work, with no restrictions and no permission necessary, but don't mislead people, and don't use my non-code work to directly compete against the service that I'm operating.

Despite all of that, here I am, on the eve of GDC, with a small but amusing content update for you.

More emotions. Lots of little bug fixes. Enjoy!
[Link][15 Comments]

Update: Fixes Galore
March 2, 2019


All reported, reproducible issues in both the code and the content have now been fixed. It was a lot of stuff. You can see the full list here:


There's also one surprise in there, and I will say nothing more about it.

Next week, I'm working on my GDC talk, which has been announced here:

[Link][21 Comments]

Update: Turbo Map Load
February 24, 2019


This update has tons of fixes and improvements. The biggest one is an overhaul to the way the map is loaded. You may have noticed that, in the past, the first time you loaded a map, it was pretty slow, but in later lives, it was very fast. This would be true even if you quit the game, as long as you didn't restart your computer.

And by "pretty slow" the first time, I mean very slow, depending on the state of your disk. 60 seconds or more wasn't unheard of, which meant that you were loading through a good portion of your childhood. This has gotten worse over time, as more sprites have been added. Subsequent map loads in future lives would be as fast as 4 seconds, thanks to caching.

Reading files from hard drives the first time is slow, there's no way around that. The game was designed with a lazy, as-needed approach to sprite loading, only keeping the sprites that are absolutely needed in VRAM, and flushing any sprites that haven't been drawn for over ten seconds. The idea was that, with 10,000 objects, all those sprites are never going to fit in texture memory. Maybe not, but we're not there yet, and the total size of all the sprites in the game is currently only about 56 MB. In busier map areas, almost all of these need to be loaded, so we're pretty much using that much texture memory anyway.

It turns out that reading 56 MB from disk isn't slow, generally, but when it's in 1800 separate files, caching prefetches can't help. Bundling all of these into one huge file makes it much faster, and so does compressing them (TGA files that have a lot of transparent borders are very compressible). These all fit, together, into just a single 6 MB file. Might as well load the whole thing at startup, which is what the game client is doing now. While we're at it, might as well do the same thing with the sound effects (which aren't at all compressible, but still benefit from being in one big file together for caching reasons).

So by the time you get around to "map loading," after logging in, there's really nothing to load. This means that a progress bar isn't even needed--it's that fast (most of the "3 seconds" quoted above are spent finding the server and connecting to it).

And thinking about the future, we're definitely not going to have 10x more sprites than we do right now, and that worst case would be 560 MB, which still would fit in the VRAM of some pretty old graphics cards. It might actually be okay to always preload all sprites.

This isn't entirely free, because the compressed glob file has to be made somehow. Given that, between sprites and sounds, this represents about 25 MB currently, and given that these files will change with every update, building them server-side would dramatically balloon the download sizes of the weekly updates.

So, your client rebuilds these, one time, after every update. This can take a bit of time, maybe up to a minute, depending on your hard drive, but after that, the game will load quickly. And furthermore, this process happens before you even login, so it has no impact on your map loading experience.

Okay, what else changed? Too much to list in detail here.

Everything after v199 here:


Everything on February 22, 2019 here:


All reported and reproducible code bugs on GitHub have been fixed now. I'm still in the process of working through all the content bug reports.
[Link][11 Comments]

Update: Temperature Overhaul
February 17, 2019


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.
[Link][75 Comments]

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