One Hour One Life Forums

a multiplayer game of parenting and civilization building

You are not logged in.

#1 News » Update: Curved Tracks » 2020-01-24 00:56:22

Replies: 4


Forum member Wuatduhf made an important discovery:  recent changes to the way object patterns work had suddenly made curved cart tracks much more reasonable to implement.

It turns out that I already had the graphics drawn for these curves, and they looked really good back in the day, but I had to scrap them because of the combinatorial explosion that they would entail.  For example, north-moving carts already had three "leave" cases (leaving from south ends, north-south tracks, and cross tracks) and three "entering" cases (entering north-south segments, entering north ends, and entering cross tracks).  To handle all the combinations, 9 distinct transitions were required for each cart direction, resulting in a total of 36 transitions.  That's a lot, but as soon as we add in curves, it blows up even more, with something like 25 transitions needed for each cart direction, or 100 total.  That's a lot of transitions to author correctly, and way too much to keep track of along the way, resulting in tons of room for error.

So what changed with object patterns to help with this problem?  Something pretty tiny and simple, actually.  Part of the bottle update a few weeks back involved emptied bottles that made a final sound as they were emptied.  Roughly half of the bottles held liquid, and the other half powders, requiring a different empty bottle state for each to play the "glug-glug" or "swish-swish" sound.  All the bottles were part of one big 18-item pattern, but how could I flesh out the empty state for this pattern?  Since an object can only occur in a given pattern once, I would need to create 18 separate "empty" bottles, even though they all pretty much did the same thing (half of them playing the powder sound instead of the liquid sound).  That's a lot of extra objects that essentially do nothing.  But why couldn't a pattern have repeated objects in it?  In other words, why couldn't a pattern "converge" on a few common end states?  These bottles could be different all along, with 18 variations, but once empty, end up as one of two empty-state bottles to play one of two sounds.  Each of the 18 slots in the pattern would contain one or the other of these two bottle objects.  I updated the pattern editor to support this, and that was it.

Wuatduhf's observation was that these new "converging" patterns were exactly what was needed to cut through the combinatorial explosion for tracks.  As a simple example, when a track cart moves north out of one of five possible north-bound tracks, each of these needs to potentially land in the same connecting track.  This can be implemented as a pattern, then, only if the pattern can contain repeats of the same destination track.

Thus, instead of 25 separate north-bound transitions, I was able to implement one set of north-bound transitions describing what happened to a north-bound pattern, and then fill the pattern with all the cases.

This also allowed me to implement tracks that pass through spring-loaded doors pretty easily, preserving the insulation bonus for the room that the track emerges from.

In the end, each of these patterns had 25 elements each (with repeats to cover the various combinations), and the north-south patterns had 36 elements each (due to the extra combinations needed for passing through spring doors).  And there were five separate patterns for each direction, resulting in a grand total of 610 items listed in these patterns (all passing through only a small handful of transitions).

There was still a lot to keep track of when fleshing out these patterns, and the whole thing felt about as close to an IQ test as I've experienced while working on this game.  My moth-holed, 42-year-old brain muddled through it all, but barely.

But those curvy tracks sure do look nice.  Great to dust off 17-month-old artwork and finally put it to use.

#2 Main Forum » RECORD BROKEN » 2020-01-23 15:49:49

Replies: 8

Congratulations to the Sauler and Connell families, who both broke a 20-month-old record yesterday.

Clearly, the new baby placement code is working as intended.... maybe a bit too well.  But it's clear that families aren't dying out "by accident" anymore.

And oil does dry up (I VOG-visited a town a few days ago that had two dry oil wells nearby, and they were in the process of looking for a third).  So long-term perils abound, hopefully.  Maybe it's not quite hard enough...

But two of the initial families (Underberg and Cool) did die out along the way, so that's good.

The two record-setters will meet their demise with the update restart, of course..... that's a testament to how long they survived!

#3 Re: Main Forum » Any way to force-drop something in a bad biome? » 2020-01-23 15:42:17

I've watched that video closely but been unable to reproduce it on my end.

It seems that exactly what allows this to happen is a mystery.  You can see in the video that he walks back and forth a bunch, but only has the bug happen once....

#4 Re: Main Forum » Jason's Pattern update has accidentally made Curved Rails viable » 2020-01-20 22:23:19

Yes, this fixes the problem that I was having.

I'll check this in for now, and try tackling the full monty tomorrow and see if I can keep my sanity.

#5 Re: Main Forum » Jason's Pattern update has accidentally made Curved Rails viable » 2020-01-20 22:20:12

Oh, I see the problem....

I need to arrange the orders of the different patterns so that they CROSS properly.  One pattern needs to be ABCABCABC, and the other pattern needs to be AAABBBCCC

Sheesh, I can't imagine keeping all of this straight for all those lists...

#6 Re: Main Forum » Jason's Pattern update has accidentally made Curved Rails viable » 2020-01-20 22:15:16

Okay, here are some screens of what I've got for East-moving carts and tracks (no curves).

For some reason, this isn't working, and all the carts (which start on west-ends in my test) crash after I wind them up.  The only one that seems to work is where a West-end is hooked directly to an East end.

What am I missing here?  I've been staring at this way too long today...

#7 Re: Main Forum » Jason's Pattern update has accidentally made Curved Rails viable » 2020-01-20 21:59:04

Wuat, I hope I'm missing something here, but I'm still kindof encountering a hairy combinatorial explosion.

I'm just trying to handle east-moving carts with patterns (without doing curves yet), and I'm running into the fact that each pattern needs 9 members (with 3 members repeated three times each), and there are FIVE of these patterns just for east-moving carts.

Also, even this far, it seems very error-prone, because my east-moving carts aren't working correctly currently, and I'm having a really hard time finding the bug.  I probably have some object in the wrong order in one of the patterns.

In the pre-pattern implementation of east-moving carts, I could figure out which case isn't working, and then check the transition for that case.

Here, I'm kinda flying blind.

And to actually flesh this out just for east-moving carts with curved tracks included, there will be 25 elements in each pattern, and five patterns as well.  So 125 elements in order-sensitive lists just for east-moving carts.

Of course we'll also need S-moving, N-moving, and W-moving carts.  Which means a grand total of 500 items on order-sensitive lists.

That's pretty insane.

Yeah, it's great that we don't have to specify all 500 transitions (or however many)....   actually, I think that because of the duplication necessary, there are MORE items on the lists than would be necessary if the transitions were all done manually.  I think it would be way less than 500 transitions.

The duplication on the lists is necessary because the pattern implementation doesn't explode the combinatorics automatically.  I.e., if you have a pattern of 3 items on the actor side and 4 items on the target side, it doesn't auto-generate all 12 transitions for you.  If you want that to work, you need to flesh these patterns out into 12 each with repeats.

But even if the pattern implementation DID auto-explode for us, it wouldn't work here, because the actor and the target side MATCH in terms of number of members.

For example, we have 3 east-moving carts, 3 tracks left behind, and 3 possible destination tracks (currently, without curves).  So the pattern implementation would see 3 on the right and 3 on the left, and think the whole thing was one big pattern, and not generate all the combinations (not that it does that anyway, currently).

#8 Re: Main Forum » Jason's Pattern update has accidentally made Curved Rails viable » 2020-01-20 20:53:07

Also, the PGUP/DOWN glitch in the pattern editor has been fixed.

#9 Re: Main Forum » Jason's Pattern update has accidentally made Curved Rails viable » 2020-01-20 20:52:43

When you say "trains," you mean a bunch of linked cars?

Yeah, that's not happening in this engine, currently.

And if you mean, "Things on tracks that people can ride in," again, the engine doesn't support that either.

A + B = C + D is pretty powerful, but it can't do everything.

So far, everything in the game fits that pattern, or some version of that (an animal or track cart is A and the thing it's moving onto is B, for example).

Stuff like a train with multiple cars all moving together would obviously not fit this pattern, which would require custom-coding.  The whole point of the engine is to see how far we can go in simulating almost everything without custom coding.

And for the few things in the game (currently) that don't fit the A + B = C + D pattern, like writing, maps, flight, and radio, the were all implemented through some kind of quick, simple hack.  If you look at the amount of custom programing done to support each of these things, there's almost none.

Trains, boats, multiplayer vehicles, and networks (plumbing, electric) are not do-able with simple hacks.

#10 Re: Main Forum » Jason's Pattern update has accidentally made Curved Rails viable » 2020-01-20 19:16:55

Ah, thanks for pointing out the page-up/down bug.  Will fix.

#11 Re: Main Forum » Jason's Pattern update has accidentally made Curved Rails viable » 2020-01-20 19:01:20

Anyway, first step will be to see if I can get the existing NS and EW tracks converted over to patterns in a sensible way.

I must say that this kind of multi-layered complexity makes my 42-year-old brain a little nervous...

Reminds me of the mental gymnastics necessary for functional programming.

This kind of thing is a young man's game, for sure!

#12 Re: Main Forum » Jason's Pattern update has accidentally made Curved Rails viable » 2020-01-20 18:58:54

Yeah, they were never checked in as sprites.

But I still have the source (and scanned) artwork in the cache.

The trick for very exact drawings like this is to lay them out in CAD first to get the angles all perfect.  Then print the cad, and trace it with pen and ink on a light table.

Here's what they looked like in CAD:


I've also used this trick for walls, doors, and some other things that need to be exact.

Oh, and the whole engine was done this way.  Lots of tiny parts that need to line up exactly.

#14 Re: Main Forum » Jason's Pattern update has accidentally made Curved Rails viable » 2020-01-20 18:43:20

Ah, I see what you mean.  We essentially can have an "entering from left" pattern that every right-moving cart dumps into...

#15 Re: Main Forum » Jason's Pattern update has accidentally made Curved Rails viable » 2020-01-20 18:35:02

I drew the curved rails a long time ago, and they looked really good...


I'm still worried about combinatorial explosion, but I'm looking into how this change to patterns affects the situation.

#16 News » Update: Baby Placement » 2020-01-17 21:07:51

Replies: 9


My wife was out of town all week, so I was left with the task of being a full-time parent as well as a game developer.  I did manage to get a few things done, though.

First, there was the question of Eve frequency, and how that tends to spread civilizations out over time.  Eve placement is related to baby placement (we place an Eve instead of a baby under certain conditions), and in thinking about the baby placement code, I realized it had grown into a multi-scarred monster over the years of trying different methods inside and outside the rift.  Seemed like a good time to start clean and really think about what baby placement is supposed to accomplish.

Our highest priority in placing a baby should be to make sure there's at least one family in each of the specialist skin tones, and if all of them are already present, bolster the population of the weakest skin tone.  After that, our next priority is to bolster the population of the weakest family, and place girl babies when the number of potentially fertile females in a given family gets too low.  Of course, we also want to respect each mother's birth cool-down when possible, and also each player's previous-life area bans (so they don't get born to the same family over and over).  But we should also be willing to ignore cool-downs and area bans if there are no other mothers available.  No one should be able to area ban themselves, through suicide, into being an Eve, and we'd rather overload a mother on cool-down than spawn an Eve.

Finally, we need to make sure that the server is never overloaded with babies relative to the adult population (more than 2/3 babies), nor that a few remaining mothers are overloaded with babies (more than 4 babies per mother).

And of course, through out all of this, we respect curses, never placing a cursed baby near a player who cursed them, ever ever ever.  If there's no place for a cursed baby to go, they are sent to donkey town.

With those priorities cleanly stated, we can see that we only place Eves in two situations.  First, if there are too many babies for the existing adult population or population of mothers.  And second, if we're missing one of the specialist skin tones.

Those cases should be relatively rare, which means that new Eves should be rare.

With the simplified code in place, the behavior is much easier to reason about.  If there seem to be too many Eves in the future, I'll be able to figure out exactly why.

Next, the Genetic Fitness leaderboard has clearly been getting out of hand, with top scores climbing into the 500s.  In looking closely at the top-scoring players, I found something distressing:  many of them had very low average lifespans themselves.  By keeping their own lifespans low through regular suicide, the were able to farm points whenever they lived an occasional long life.  Furthermore, they were essentially handing out free points to everyone else through these occasional long lives.  It was also clear that quantity was trumping quality.  When scores are potentially infinite, playing a lot of lives is the only way to reach the top.

Implementing a suggestion from Wondible, we're now back to scores that are asymptotically capped at 60, while still solving the problems that the older capped system had (where you got punished for having a new player as a baby).  You now gain points whenever you help an offspring player live longer than expected, but the amount you gain is scaled relative to your own score.  Thus, the closer you are to 60, the less you can gain from each offspring, but the more you stand to lose if you actually hurt an offspring and cause them to live a shorter life than we expect for them.  You also gain points for yourself when you live longer than expected, with your score approximating how long we expect you to live.

Thus, there's no longer an exploit possible through suicide.  The best way to get a very high score is to live very long lives yourself, and never suicide, and help all of your offspring to live as long as possible, too.

Returning to a capped score demands a new formula for mapping score to tool slots, which can be seen in this graph:


As part of this investigation, I made more of the leaderboard data public.  You can now click on the top-scoring players and see the recent lives that contributed to their score: … eaderboard

Thus, if another exploitative way to boost score emerges in the future, it will be easier for everyone to study and identify it.

But looking at the data now, we're off to a good start.  All of the top-scoring folks have very high average lifespans themselves.

There are also a bunch of little fixes.  More stuff can be bottled, and bottles are a bit easier to work with.

#17 Re: Main Forum » [Discussion] The new Genetic Fitness calculator doesn't fix the issue » 2020-01-17 20:09:26

In your example, don't live to 60 ten lives in a row.  Lives to 60 only 2 lives in a row, then SIDs 10 lives in a row.

#18 Re: Main Forum » [Discussion] The new Genetic Fitness calculator doesn't fix the issue » 2020-01-17 20:06:40

Wuatduhf, the issue is way bigger than altruism

The people on the TOP of the leaderboard had very low average life expectancies.

In studying what they were doing, by using /DIE to keep their own average low, they were able to farm points from the occasional 60+ lives that they lived.

So they weren't just "taking one for the team" by giving other people points, but also boosting their own score by doing this.

If your average lifespan is low, doing SIDs 9x in a row loses you very few points.  Then living to 60 twice gains back the lost points, plus extra points, without raising your average too much.  Repeating this process for infinite score.  And of course, on top of this, you are boosting the score of others.

Having unlimited scores is also messy because it makes it hard to map scores to benefits nicely.

#19 News » Update: Bottle It » 2020-01-09 20:43:22

Replies: 10


Still working my way through this list of issues:

Some of the issues provide inspiration about obvious holes in the game's content space.  This week, I fleshed out bottles, which had previously only been used for wine.  Now they're used for almost every liquid and powder in the game.  Wall shelves were fleshed out too, to go along with this, so now colored walls can have shelves too.  Colored wall shelves full of colorful bottles.

More bottles means you're going to need more glass, and Tarr pointed out that glasswort was the current bottlneck there (bottleneck, see what I did there?).  Now you can cultivate glasswort, but of course, it's a desert-loving plant.  And yes, in real life, glasswort doesn't grow in the desert, but instead along the edges of brackish bodies of water.  We don't have a beach or salt marsh in the game yet, though, so we can at least imagine that our desert is an ancient sea bed.

Fleeing rabbits now avoid floors when digging their new holes.

Together, all these changes resulted in 138 new objects, most of them varying states of the 18 new types of bottles.  But yeah, that's a lot of new bottles.

#20 Re: Main Forum » PSA: Eve grid is borked » 2020-01-06 22:11:51

Yeah, so... server reset incoming to fix this.

#21 Re: Main Forum » PSA: Eve grid is borked » 2020-01-06 21:53:26

I'm fixing the bug in the code that is causing this.

Opinions needed:

Is this worth a Monday server restart to get the fix out ASAP?

#22 Re: News » Update: Fixes Continue » 2020-01-04 00:52:24

Well, the idea is that the stem is kinda woven in the band of the hat.  But yeah, it wouldn't have been too hard to "chop" off the rose stem when making these.

It's a little late now, though, because there are 85 unique hats that would need to be manually fixed!

#23 News » Update: Fixes Continue » 2020-01-04 00:03:15

Replies: 22


Still plowing through this list, with only 168 more to go:

Some of the fixes this week involved quite a bit of new content, as I fleshed out the dye possibilities for knitted clothing and roses, and patched some gaps in hat decorations.  Over 135 new things, but most of them are the result of combinatorial explosion (red hats with blue roses and blue hats with red roses).  Regardless, there's a lot more visual variety in clothing now.

Tables are useful for storing a few things even when you're not feasting, way stones no longer block movement, grapes can be removed, and a bunch of things that weren't containable are now containable.  Rabbit holes can be dug up.  You can no longer dump fresh water back into a water source, so there's no more confusing situation where you gain or lose a unit of water by doing that.  Drunkenness has been refined a bit and clarified with a blushing emote.

The little photo icons in the family tree are back, for anyone starring in a photo.  A few cases of spurious tool learning have been fixed (you no longer learn the knife when taking it apart, for example).

And most exiting of all:  another cause of the bouncing-forever (wild bug appeared) has been found and fixed.  Hopefully, that's the last one (this mysterious issue has been lurking for more than a year now, it seems).

I gird my loins to plunge back into that list of 168 and make another dent next week.

#25 Re: Main Forum » Place your bets! » 2020-01-03 02:12:36

Only 167 reported issues to go.

Board footer

Powered by FluxBB