Launch pads must now be built in populated areas, with coordinates discovered from the remote orbital alignment location. This brings rocket-building home, returning it to to community endeavor that it was in the beginning, while still limiting rocket launches to once every five hours.

There have also been many fixes and improvements to the Editor, based on feedback from the Another Planet content team.

All pieces are in place now for the One Hour One Life end game.

You can build a rocket inside OHOL. And coming full circle, you can listen to Tom Bailey's amazing music when you do.

You can ride that rocket to Another Planet, which gives you a Steam Key to let you into the beta test of this exclusive new, unreleased game.

https://steamproxy.net/steamstore/app/2787060/Another_Hour_Another_Planet/

After gaining access to Another Planet, you can specify your own Github account name, and you can also vote for a Content Leader using their Github name.

The Content Leader has full Push access to the AnotherPlanetData Git repository, and the ability to push changes live to the playerbase.

The Export functionality makes it easy for people to collaborate with the Content Leader, submitting sprites, objects, animations, and sounds.

All contributions to Another Planet are tagged with an authorship hash.

When Another Planet is finally released for sale, in February 2026, authorship tracking will be used to divided 60% of the first year's revenue among the players who contributed content to it, based on the portion of the content that each person contributed.

But most importantly... you can now build a rocket. A rocket!

All of the remaining infrastructure for Another Hour Another Planet is in place now.

It is now possible to ride the rocket inside One Hour One Life, leave the planet, and gain access to Another Hour Another Planet via a Steam Key and an off-Steam download link. And once you're playing on Another Planet, it's also now possible for you to specify your GitHub account name, and to vote for the current Content Leader. The current Leader is automatically granted Push access to the anotherPlanet data repository on GitHub, and that access is removed whenever they leave office and are replaced by someone else.

All of this stuff has been tested on my end, and seems to be working. But I need you to help me test it more thoroughly.

Starting on Monday, I will be making surprise VOG appearances in the game, and placing test launch pads for people to use. By triggering these launch pads, they will be able to ride the test rocket, gain access to Another Planet, and help me make sure that all of this infrastructure is actually working correctly.

The last thing to do, for me, is to actually draw the rocket, and flesh out the tech tree changes that will make constructing the rocket possible. Currently, the rocket features place-holder art, and it's currently uncraftable, except by me in VOG mode for testing.

I've been working on the infrastructure for the Another Hour Another Planet endgame, and the various pieces are coming together.

There are now two AHAP servers running, which you can see here:

http://onehouronelife.com/ahapReflector/server.php?action=report


These are live and playable with bare-bones placeholder content, which is being managed here:

https://github.com/jasonrohrer/AnotherPlanetData


Eventually, the elected Content Leader will be able to edit and add to the content in this repository, and then make it live using this update trigger interface:

http://onehouronelife.com/ahapUpdateGate


The general idea is that the community will make content (sprites, objects, sounds, and animations) and the submit it to the Content Leader as OXZ export bundles. The Leader will then choose which content to accept and integrate it into the master content tree, which is being maintained on Github. Once an "update full" of content is ready, the Leader will be able to push it out to the AHAP servers and players.

Off-Steam, One Hour One Life has always used its own custom-built update-downloading system. But elements of that system are going to be exercised heavily by all AHAP players in the future---even Steam players---since that's how user-generated content, selected by the Content Leader, will be delivered to players.

In testing this, I noticed that the first diff bundle for AHAP, the one that includes my place-holder content, was annoyingly slow to download. At around 48 MiB large, it was bigger than most individual OHOL diff bundles. At first, I thought the bandwidth on my download servers was lacking, but in doing some stress-testing, I found that downloading through the OHOL client was 2 to 4x slower than downloading the same diff bundle directly.

Long ago in my development career, I digested a bit of wisdom and took it to heart: threads are evil. Avoid using them whenever possible. A corollary is that when you're making networked systems, non-blocking IO is the performance king. In your main thread, you just check the socket to see if there's new data to read, and you read as much as you can, and then you continue on doing other things, and then you return to check the socket again later. While this is 100% true server-side, when you need to handle requests from hundreds or thousands of simultaneous clients, things end up working a bit differently in interactive GUI software when you're just trying to maximize download bandwidth.

In order to keep the GUI responsive, you have to keep returning to it and synchronizing with it---you need to wait for the graphic cards VSYNC interval. But waiting for VSYNC can take a while. On my test system, which was updating the screen at 60 Hz, you can end up waiting for 16.6 ms, worst case. But what's happening during that 16.6ms? Well, more data is arriving on the socket, and you're not reading it, because your main thread is stuck waiting for VSYNC. On a fast network, this is bad, because a lot of data can arrive in 16.6 ms. Let's say the OS receive buffer for your socket is 8192 bytes, which is the default size on many systems. And let's say you're on a pretty average DLS connection like mine, downloading at 40 Mbps. Well, during that 16.6ms, something like 83,000 bytes will arrive, which overflows the OS receive buffer ten times over. Even if you code things just right to do as much work as possible between VSYNC, if you wait for even 1/10 of the VSYNC interval, your receive buffer overflows. I haven't looked into the details of what happens when the buffer overflows, but my guess is that the socket has to send some kind of signal to tell the server to stop sending data (or maybe it's just through lack of packet ACKs coming back to the server). Regardless, the server is sending packets that aren't being received, and at the bare minimum, they will need to be re-sent later. Goodbye max throughput.

You can imagine all kinds of tricks to overcome this problem while still using threadless, non-blocking IO, but they all hit the hard reality of waiting on VSYNC eventually. Even if they don't wait on VSYNC as much, you can't have a responsive UI with a progress bar unless you're occasionally drawing to the screen.

The most straight-forward way to solve this problem is with a thread that runs in the background, receiving data from the socket as fast as possible, while your main thread continues updating the GUI and progress bar in a responsive way.

So yes, there's a thread in OHOL now! Actually, there was always one other thread in OHOL, because it turns out that on many platforms, resolving a DNS host name to an IP address cannot be done in a non-blocking fashion. But that LookupThread was pretty trivial. This new thread is doing a substantial amount of work.

And with all that in place, the OHOL client downloads stuff fast, maximizing the available bandwidth between the download server and you.

For the time being, this will mostly impact off-Steam players who are downloading all of their OHOL updates through this system.

Content made with the Editor now tracks authorship using a hash of your account's email address or Steam ID. When you export content as OXZ files to share with others, your authorship hash goes with your content. Thus, over time, we can keep track of the portion of the content that each person contributes. This will be important in connection to the plan for Another Hour Another Planet, which I will explain here.

Another Hour Another Planet will be a separate game, released for real on Steam.

First of all, how will people gain access to Another Planet? For the time being, there will be a hard-to-build object inside One Hour One Life which requires some kind of server-wide collaboration and consensus: a rocket ship. Once this rocket is built, there will be room inside it for one lone traveler. Whoever is chosen by the collective action of the players on the server will ride the rocket and gain permanent access to Another Planet. For each rocket launched, one additional person will gain access.

And the content on Another Planet? It will be entirely conceived, designed, drawn, animated, and assembled by the player community. Each person who has access to Another Planet will also get the right to vote for the current Content Leader---the person in charge of curating, assembling, and testing the content submitted by the player community. And yes, the Content Leader might make bad choices, try to sabotage the game, or even just burn out. A new Content Leader is always just a vote away, and the entire process will be organized through an immutable Github repository, meaning that a future Content Leader can roll back bad content changes if needed.

Over the years, lots of people have disagreed with various content design decisions that I have made. This will be a chance for the community to make their own decisions, chart their own course, and make the game their own.

Only the content will be modifiable by end-users. Another Hour Another Planet will use exactly the same binary client and server code as One Hour One Life, and I'll still be maintaining that, and fixing bugs, into the future. So we don't need to worry about player-submitted virus code.

Finally according to Steam's policies, games that appear in the Steam Store and in people's game libraries must eventually be sold. They don't want prestige items, only accessible as prizes earned outside their usual sales channels, clogging up their store and confusing their customers. So yes, while Another Hour Another Planet will only be accessible by rocket from inside One Hour One Life during it's beta development period, it will eventually be sold to the general public as a real game. I've set a deadline for you folks, in fact: roughly two years from now, on February 13, 2026. Of course, you can all keep working on it and adding content to it after that release date, but you should shoot to have a solid, compelling Another Planet game experience by then.

But if it's sold, that means it might make some money, and then what?

Coming full-circle, that's where the Authorship Tracking comes in. I promise to share 60% of the revenue from the first year of AHAP sales with each and every person who contributed content to the game world, based on the fraction of the total content that they contributed. Details still need to be ironed out, but sprites, sounds, objects, animations, transitions, and music will all be factored in. But even if you only contribute one thing, you will get some money during the first year.

During future years after that, I will make a good-faith effort to continue sharing 60% of revenue with content contributors who's portion of the revenue would total more than $500 for the year. In other words, I'm not going to continue paying thousands of people a few dollars per year forever. I will do that during the first year, however. Regarding the "good faith effort" part: obviously, I won't live forever, etc.

And the point of all this?

I've dedicated eight years of my life to One Hour One Life. I'm now 46 years old, and I may not have that many big software projects left in me. It's time for me to move on to other things, before it's too late. I could just turn One Hour One Life over to a dev team, or even sell it to a company, in order to keep it going. But given that I drew every pen line, played every piano note, and recorded every sound myself, it's a very personal work. It is exactly how I want it to be, and I want to leave it that way, going into the future. People who play One Hour One Life should be playing my One Hour One Life. But how can the game really live on, and the community keep thriving, if I stop working on it? Another Hour Another Planet is an outlet for that future vitality.

One Hour One Life also maintains a certain degree of visual consistency, in part because everything in it was drawn by the same hand, using exactly the same tools (heck, even on exactly the same paper stock). Any collaborative effort would obviously deviate from that consistency. In fact, I imagine that Another Hour Another Planet will be a bit of stylistic mish-mash. But that's perfectly fine, given the theming: it's supposed to be an alien world, after all. Alien worlds can be strange.

There are obviously lots of details to iron out, but that's a broad overview of the plan.

We recently received some sad news. Methman, a friendly pillar of our community and Discord moderator, died late last fall.

The One Hour One Life community has been remembering him in various ways this week.

His primary online handle was MaDc0w, and I just recently learned where the "Methman" nickname in the OHOL community came from. Mofobert designed an "OHOL Portrait" of MaDc0w using the Editor, and MaDc0w loved this hilarious image so much that he adopted it as his Discord icon. MaDc0w thought that this wacky OHOL character with the red cape looked like he was high on meth, so the name Methman was born.

Here is a direct quote from the email that I received from his friend:

Now that the family has had a couple months to grieve we are providing the following statement in one of his online communities. I pass this information on to you so you can choose to make a statement or have a remembrance as well.

It is with deep sadness that we announce the loss of MaDc0w, a friend so close to us that they are considered family. He unfortunately passed suddenly and untimely in the morning on November 30th while in his home. He lived an amazing life with a love of Technology matched by few. MaDc0w was a leader in our community and will be missed by all.

Rest in peace, Methman. You will be missed.

A small mid-week update this week. You can now pile baskets of soil, just like you can with baskets of charcoal. There's also been a gotcha fixed with worm farming: taking the last worm from the wormy soil pile no longer permanently ends the worm farm, since you can put the worm right back in if you've removed it by mistake.

I also spent a good chunk of time this week ironing out the details of AHAP and starting to implement it. You'll hear more about this soon.

Tomorrow, I'm heading out to Utah for the premier of the documentary Eternal You at Sundance, which is in part about Project December, my AI side-project. More details here:

https://festival.sundance.org/program/film/6569ff9efac9f46f45c03c81


I'll be back early next week to resume work on One Hour One Life.

NOTE: this update announcement was posted last week as a time limited contest by accident, which limited its visibility. This is a repost. The original announcement date was Saturday, January 13, 2024.

A bunch of improvements to the Editor this week.

First of all, along with loading mods, which are temporary, the Editor can now import content permanently. You can either replace objects content (similar to how mods are loaded, but permanently) or add entirely new objects. To import, drop an OXZ file into the new import_add or import_replace folder. The idea here is that people who are working together on new content can easily share their work with each other.

The various pickers in the Editor now support searching by ID numbers in addition to name text.

Next/Prev paging in the pickers works more sensibly when holding CTRL and SHIFT for bigger jumps (jumping by 25 on CTRL, 125 on SHIFT, and 625 on CTRL+SHIFT).

You can also search using a new field=value, field>value, or field<value syntax. For example, searching for food>10 will find all food objects that are worth more than 10 food. Searching for MapP>0 will find all objects that occur naturally on the map. Almost all of the text field and checkbox names in the Editor can be used as part of this new search syntax.

There's also a new contentSettings folder, which ships as part of the content updates, to cover settings that are content-specific. Before, all settings shipped as part of the platform-specific binary client updates. This meant, for example, that when adding a new emote, both the content (for the emote's appearance) and the binary client (for the emote's settings) would have to receive an update. Now a content editor, who wants to make deep changes to the game world, can do so with a content update alone and without touching the binary client codebase.

And most importantly, you can now put dried beans in piles and buckets.

Steam Workshop support is live. You can find it here:

https://steamproxy.net/app/595690/workshop/

Instructions for posting mods to Steam Workshop can be found here:

https://steamproxy.net/sharedfiles/filedetails/?id=3121137673

And I'm holding a contest for the best mods, as voted by the community, between now and New Year's Day. Post your mods to Workshop between now and then. The mods with the most subscribers at or around Noon EST (New York City Time) on New Year's Day win.

There will be ten winners. Each person can only win one prize, even if they have more than one highly-subscribed mod.

Prizes are as follows:

1st place: $500
2nd place: $400
3rd place: $300
4th place: $200
5th through 10th place: $100

Prize winners can choose from the following payment methods:

--PayPal

--Cashier's Check by Mail.

--Gold coins/chunks by Mail.

--Silver Coins by Mail.


This is obviously a contest of skill, not a lottery. If it is illegal in your area, I feel sorry for you.