Update: Town Launch
May 11, 2024
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.
| Update: End Game
April 26, 2024
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://store.steampowered.com/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!
| Update: Launch Prep
April 21, 2024
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.
| Update: Fast Download
March 15, 2024
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.
| Update: Author Credit
February 16, 2024
Content made with the Editor now tracks authorship using a hash of your account's email address or Steam ID. When you export contents 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.
|
|
|
