Update: Games of Chance
November 3, 2018
This week I developed an extension of the category system which allows crafting transitions to have more than one possible outcome. This is obviously needed for things like fishing, which is included in a minor way in this update. The old "do this and get that, guaranteed" just doesn't feel right when dipping a hook in the water. You'd be hauling 'em out one after another.
All transitions in this game are A + B = C + D. In the past, A and B could be categories, which might mean that an axe can chop anything in the "kindling source" category into kindling.
The new probability system now allows C and D to be categories as well, but a new kind of category with weights for each member. Whenever the transition is invoked, one of the members is picked at random, according to the weights. The weights can be any probability distribution. Some outcomes can then be very rare, when that's appropriate (like catching a special fish, or finding a diamond in a mine).
But I didn't stop at fishing. To fully put this new system through its paces, it made sense to explore the human activity that led to the development of probability theory in the first place: games of chance. Also known as gambling. Thus, I didn't just stick in a probability set with a few outcomes, like fishing. I included one set with 21 outcomes (for a pair of rolled dice), and another with 52 outcomes (for a deck of cards). Good thing I did this, because including categories this big unearthed a serious, long-term crash lurking in the category system.
And come to think of it, fishing and gambling really do go hand in hand.
The tutorial was also updated with some improved wording and a "hint hallway" for people who are really stuck (age-gated at 35, so you have to have been trying for 20 minutes before you get any hints).
Those of you who saw moving ice holes related to penguins, that bug has finally been found and fixed. And a new protocol is in place (PING/PONG) to help the client detect true cases of the bouncing-forever bug, as opposed to just genuine network outages. This should result in far fewer false reports. And one new cause of bouncing-forever, this time caused by the new reconnect system, has been fixed.
And stacks, and partially-used objects, no longer revert to their full state on server restart. Their true states are correctly remembered. This also means no more weird universal locks after server restart.
All that said, I still have quite a long list of mini-bugs on GitHub to fix this week before the Steam release on Thursday. That will be my focus, and there will be no new content this week (it would be weird to ship a content update on the very day that the game goes live---the new players will need a week to settle in). I hope to push out the final bug fixes (including content fixes) on Tuesday, to allow time for some last-minute fixes on Wednesday as well.
The plan is to put out a nice-sized content update the following week, and then continue with weekly content updates thereafter.
| Update: Plaster and Paint
October 26, 2018
Plaster is cheap, but pigments are a bit harder to come by. Except for yellow. That one is easy, but oh so cruel. Outlawed in 1908, in fact. Have you ever noticed that mangoes make your mouth itch a little bit? Now imagine being force-fed the leaves!
And yes, I suspect that I'm one of the only game designers in the world who, upon deciding to add wall paints to my game, realized that I would also need to add mango trees. That leads me to ask: where would this game be without Wikipedia? There's an information rabbit hole lurking around every corner.
Steam integration seems to be up and running smoothly. When this update went out, the Steam client fetched and installed it (with a bit of automated goading on my part). The plan is to get one more content update out the door next week before Steam launch week. I also have a nice fat queue of GitHub bug reports to go through. Thank you, and keep 'em coming, folks.
| Update: Steam integration complete
October 20, 2018
All the pieces are finally in place to make the game work on Steam. The automated update scripts (both for client binaries and platform-independent content updates) have been augmented to include a Steam build step, which posts the changes to Steam automatically. Steam actually has a pretty powerful command-line interface (steamcmd), which makes scripting possible.
Account creation, server-side, based on Steam ownerership, is also working. And the final pieces are in place to enable all of you, the existing owners of the game, to unlock the game on Steam and automatically access your account details on the Steam side (you won't even need to type in your key again after installing the game through Steam). However, I'm still waiting for Valve to flip the switch on the GrantPackage feature for OHOL. Hopefully, they will do that early next week, and then you can all start testing the game on Steam.
So close!
One thing I should warn you all about is that the Steam release will be Windows-only for the time being. The build process is complicated enough, and the Mac platform is finicky enough, that I've decided not to tackle it for now. Come to think of it, the old Mac that I build the game on probably can't even run Steam, so I'd have no way to test it. And sadly, Linux on Steam is even less of a priority. In my experience, Mac and Linux users make up only a tiny sliver of the Steam audience anyway. The Mac and Linux builds will continue being updated off-Steam as usual, however (and anyone who buys the game on Steam will be able to access them). Hey, I'm typing this update message from Linux right now, so I'm a true believer, but I don't even have Steam installed on here.
And the bug reports keep on coming. Thank you everyone for your diligent work reporting all this little stuff to me. When it's all organized on GitHub, I can just go down the list and knock out fix after fix. And this week, there are a ton of fixes. You can now use your baby's head to open doors and launch rail carts. Donkey Town residents see a count of their excess curse score. Some 10-year-old causes of spurious network disconnects have been fixed.
As I type this, there are 15 more new bug reports that just came in. More, please. Content issues go here:
https://github.com/jasonrohrer/OneLifeData7/issues
Programming issues go here:
https://github.com/jasonrohrer/OneLife/issues
Now that the Steam stuff is mostly dealt with, I will spend the next few weeks returning to content updates, as well as fixing the remaining bugs.
| Update: More bug fixes
October 13, 2018
First things first. The Steam page for One Hour One Life is live here:
https://store.steampowered.com/app/595690/One_Hour_One_Life
Steam integration has been going well, including support for automating the weekly update process. Next week, I'll be working on Steam account integration. Hopefully, those of you who already bought the game will be able to unlock it on Steam soon and help with Steam testing.
Beyond that, this has been another week of pretty deep bug fixes. It's astounding to me how long some of these took to track down. The infamous "bouncing forever" bug has had many causes. Two more big ones have just been found and fixed thanks to your reports. The fixes involved some general robustness changes to the protocol that will improve and normalize the behavior of the game in all kinds of situations. Using a randomized network latency simulator, I found that the game was degenerating pretty horribly when messages arrive with inconsistent delays and bursts.
For example, some messages sent by the server are meant to go together. When you pick up a stone the game, the server sends two messages: one about your changed state (a PLAYER_UPDATE message, you now have a stone in your hand), and one about the map's changed state (a MAP_CHANGE message, there's now an empty tile where the stone used to be). The server sends these to you at the same time, and under normal networking conditions, those messages will arrive at the client at the same time, and end up changing the display (of you and of the map) during the same rendering frame. However, with a flaky network, these messages can arrive with a big time gap between them. This would mean that you would get updated to show you holding the stone, while the map would still show the stone on the ground, giving the false appearance of temporarily duplicating stones. Things get even worse when the messages are about parents and their held babies.
This has been corrected with a new message FRAME protocol. Messages that happen during the same server step are grouped into a frame, and the client waits until all messages in that frame have arrived before processing any of them. Thus, the updates to you and the map, when you pick up the stone, are always shown at the same time on the client, because the server sends them in the same frame.
There were also some lingering inconsistencies with actions that held babies attempt to take right before being picked up, depending on the order in which messages arrive at the server. This has been fixed by the server ignoring further messages from held babies after it has decided that they are indeed held---until they send a JUMP message to leave their parent's arms. Before, even something as simple as a baby removing a hat right as they were picked up would cause a weird behavior---a seemignly disappearing hat. Now the server enforces a strict ordering of events for held babies, and the behavior is much more consistent.
Most of these issues have resulted in occasional glitchy behavior that has been with us since the beginning. Good to finally have these things fixed now.
There were also a bunch of other little content and bug fixes. Fence gates are a thing now, for example, and other non-gate fences cannot be easily opened with a bare hand. Teleporters have been fixed.
Many of these fixes were the direct result of people logging issues on GitHub, which is the main way that I keep track of things that need to be fixed. You can log content bugs here:
https://github.com/jasonrohrer/OneLifeData7/issues
If you think you've found a programming bug, you can log that here:
https://github.com/jasonrohrer/OneLife/issues
Special thanks to Stylingirl and IEatDaSpaghetti for all their helpful bug reports this week.
| Update: Temperature system fixed
October 5, 2018
This week's update focuses on a bunch of important fixes. First of all, the temperature system, which was always very finicky, has been smoothed out. The "just keep running" exploit to lock your temperature no longer works, and your temperature will no longer jump around suddenly and unexpectedly when you step next to a fire. Instead, your body temperature gradually moves toward the environment temperature over time. Furthermore, temperature updates happen whether or not you are moving (every two seconds). This also means that if the fire goes out next to you, but you don't move, your temperature will eventually go down to reflect the new, cooler environment around you.
The code that determines where you click when you click on yourself has been fixed to prevent mistaken clicks on your clothing that extends behind your face when you click on your face. This was particularly troublesome for children wearing backpacks or aprons. Clicking their face to eat food used to mistakenly put the food into the backpack or apron pocket (because for a child, the backpack strap and apron top are behind their face). Now the head takes precedence, given that it's actually in front of the clothing anyway.
Some of you may be aware of the game recording feature. For bug-catching purposes, every game you play is recorded in a compact, text-only form. These are saved in your recordedGames folder. They contain all mouse, keyboard, and network events, allowing the game you played to be simulated at a later time. Dropping one of these files into your playbackGame folder, and running the game, will allow you to watch a "ghost" version of yourself playing. As you can imagine, this is very useful for reproducing bugs.
However, these recording files can also take up quite a bit if disk space over time. The game now defaults to keeping only the most-recent 20 recordings (though this behavior can be tweaked in the settings folder). Turning recording off completely has always been possible, and it will increase performance a little but, but I encourage people to keep it on for the time being, because you never know when you will get a recording of a rare bug.
That hilarious clothing blushing bug has been fixed, along with a few lurking server bugs.
Next week, I'll be focusing on the Steam integration process. Hopefully, there will be a way to "unlock" the game on Steam for all of you to start testing next week. I have discovered a way to do this without handing out Steam keys, which is even easier for the end-user, and there's always the danger that unwanted Steam keys will get sold on key marketplaces at a discount.
|
|
|
