[Home] [Buy] [News] [Family Trees] [Photos] [Update Log] [Forums] [Tech Tree] [Wiki]
Update: High Society
April 6, 2019

https://i.imgur.com/McyEgaN.gif

This update is mostly about one thing: New clothing, and lots of it.

But there are also a few key fixes under the hood. Your family's last name is remembered, even if your mother doesn't give you a name. So later, if you name your own child, they will get that "invisible" last name passed on to them. This will make family trees more coherent, with a last name shared by every named person in the tree. No more lost family names over time.

Even cooler is the new grave-mouse-over feature, which now works for all graves, not just graves for people who died in your lifetime. Family history is now apparent directly inside the game, when you visit the family grave yard. To make this work, the server remembers everyone who ever lived, and keeps a new database of grave positions for each of those people. To prevent this from growing indefinitely, people get "forgotten" after a week, or when the server restarts, and the grave position database is flushed at server startup. But if your family has been around for a while, you will see a lot of family history on the ground.

In other news, community member Futurebird has created a survey for players, which you can find here:

https://www.surveymonkey.com/r/3LKVW7P

Here are the results:

https://www.surveymonkey.com/results/SM-LRBDYL2FV/


There most likely won't be an update next week---I'm scheduled to be on vacation with my family.
[Link][2 Comments]






Update: Sweet and Spicy
March 29, 2019

https://i.imgur.com/klsOnmR.gif

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

https://i.imgur.com/UaorIul.gif

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.

https://schedule.gdconf.com/session/2014-vs-2018-the-shape-of-financial-success-before-and-after-the-indiepocalypse/864486

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:

http://onehouronelife.com/forums/viewtopic.php?id=5479

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

http://onehouronelife.com/forums/viewtopic.php?id=5534

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:

https://pbs.twimg.com/media/D1eWNo7XgAY35Bt.jpg

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:

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

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:

https://github.com/jasonrohrer/OneLife/blob/master/no_copyright.txt

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

https://i.imgur.com/l9CNBGN.gif

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:

https://github.com/jasonrohrer/OneLifeData7/commits/master

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:

https://schedule.gdconf.com/session/2014-vs-2018-the-shape-of-financial-success-before-and-after-the-indiepocalypse/864486
[Link][21 Comments]






Update: Turbo Map Load
February 24, 2019

https://i.imgur.com/tyYXGyx.gif

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:

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

Everything on February 22, 2019 here:

https://github.com/jasonrohrer/OneLifeData7/commits/master

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]






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