a multiplayer game of parenting and civilization building
You are not logged in.
jasonrohrer:
> no inter-tile interactions. There's no "water" under the ground or
> anything.
Right, but it is still possible to make constructed resources be limited by
local natural resources.
Here's a simple way that could work in the case of wells. Make the final step
in well construction be the addition of a "bucket of fresh water". This is
obtained by filling an empty bucket from a pond, which permanently dries up the
pond. The bucket of fresh water decays to stagnant water after a short delay,
and it can't be carried with a vehicle. So the result is that each well
replaces a nearby pond, so the number of wells is limited by the number of
ponds in the vicinity.
This isn't enough on its own, because there should be a way to correct the
mistake of trying to connect a pond to a too-distant well. The simple way
to do that would be to allow dried-out ponds to be replenished by adding a
bucket of stagnant water, but that allows chaining ponds to exceed the
intended distance limit. Maybe that's not too bad; otherwise, an artificial
way to fix it would be to have the bucket be keyed to the pond it's filled
from, using the same random hidden category instance mechanics that keys and
locks use, such that the only pond which can (reliably) be refilled with the
stagnant water is the one the water was taken from. I don't see a better way.
Linking constructed resources to natural ones in this way also opens up
another possible effect for advances in technology: increased rate of
extraction of a fixed finite resource. So a pond could have 1000 uses, but
after each use it can't be used again for 5m; a basic well would have a
maximal number of uses copied from the pond it's linked to, but with a shorter
cool-off period between uses, and then pumps would reduce the cool-off period
further. Variations: allow n short-term uses rather than just 1 (at the cost
of introducing lots of objects); also have slow replenishment of the long-term
uses, representing natural replenishment of groundwater while allowing
unsustainable extraction in the short-term; have more advanced tech also give
a one-off increase to the long-term uses, representing reaching deeper
groundwater.
Higher tech could also allow exploitation of more distant resources.
I don't know if this is a good way to go, but it's a possibility. I do think
it's important to somehow represent ecological constraints on civilisation -
anything else would be boring as well as misleading.
How about: store with each entry the current deepest descendent and its depth,
then when a death is logged recurse up through the maternal line of ancestors,
setting the newly dead descendent as the deepest while it is the deepest
(you can abort the recursion as soon as it isn't).
It's currently really quite easy to live on your own until old age: just go
out into the wilderness, stick round the edges of deserts, and forage. Once
you manage to make a basket, you're basically guaranteed to live unless you
mess up or are really unlucky. It's a grind, but not actually much of a
challenge.
I agree it isn't a huge problem, but I do think it's a significant blemish.
Currently having a small patch of desert is a big plus for a potential
settlement location. I've seen others express this opinion too. It provides a
natural place for childrearing, and an easy means to minimise food use when
there's a temporary famine. I've also seen suggestions that you build your
smithy along the edge of a desert.
My problem with it is that it feels like exploiting a glitch rather than a
natural part of the game.
What I'd like to see instead, as well as a gradual temperature gradient in
deserts as discussed above, is to have fires given a bump so they provide
significant warmth in a sizeable radius (even if that means standing too close
gets you burnt). Then fires would form a natural focus for activity.
Currently, a small patch of desert is all that's needed to provide some tiles
which are at near-optimal temperature. In a village with some such tiles,
fires and clothes lose much of their value.
(This also combines badly with the bug about temperature not updating when
moving (https://onehouronelife.com/forums/viewtopic.php?id=1131), but that's a
separate issue.)
I think this effect is too strong. Being able to find a sweet spot in the
desert where the food consumption rate is minimal should either be impossible,
or come at a cost.
One way to make it impossible is just to scrap deserts. That would be a shame.
Given the temperature system, the only other ways to make it impossible are to
scrap the idea that desert tiles output heat, and instead have them act the
same as any other non-arctic biome, or to add some other component to the food
consumption rate calculation which is worse in the desert - moisture level,
say. Having deserts not be hot would be odd, though, while adding a new
humidity system just for this sounds like a bad idea.
Alternatively, the way biome temperature works could be adjusted so that sweet
spots still exist but are a fair way into a desert, so for a village to make
use of them it has to pay the cost of having a large desert where more
productive land could otherwise be. This could be combined with nerfing cacti,
and maybe forbidding farming on desert tiles, to increase that cost.
Glancing over the code, it looks like the simplest way to implement this might
be to adjust the grid heat output of a desert tile according to the
"secondPlaceGap" (the difference between the desert biome weighting and that
of the second highest biome in the vector produced by the map generation).
A different implementation could be to directly take a sum of biome
temperatures weighted according to this vector, so even tiles which aren't
sufficiently desert/arctic to be drawn as such would get some temperature
effects. That sounds trickier to balance though - I don't know if it could be
tweaked so that inner deserts are overly hot while non-desert areas remain
cold.
I don't think repurposing the containers system wouldn't have to be a hack
exactly.
What I really mean is: you already have a concept of an object coming with a
list of subobjects. The map storage and protocol already handle this. I see
the protocol only allows nesting of depth 2, but I guess this could be fixed
relatively painlessly.
Containers are one purpose this concept of subobject can be used for.
Properties like agedness could be another.
It would indeed mean complicating the transitions system, so transitions are
able to be conditioned on and to adjust subobjects. It would definitely be
uglier than A+B-->C+D.
The downside of the current system is that you'll have keep the use numbers
low when there are interactions - 20*7 might be manageable, but I guess
1000*1000 would be problematic.
Actually, how about this as a completely different approach which would
linearise that quadratic factor.
Add a new kind of transition outcome, an "action". e.g.
shovel_38 -> shovel_37 + dig_action
Allow actions as inputs of transitions:
dig_action + bush_5 -> dug_bush_5
Then when checking for whether a transition applies, as well as looking for
direct transitions, search also for chains of transitions going via actions.
This could replace many of the categories, and would help with hints -
currently category transitions generate a hint for each instance of a
category, which would be overwhelming if you have many tools all able to
trigger a certain transition. This would replace those hints with a single
hint naming the action.
Most likely you've thought of this and it doesn't work, but just in case:
could you use the containers system for properties?
e.g. have a tool "contain" some cracks, and have these be passed on after a
transition. Since (iirc) boxes can be turned into carts without losing their
contents, presumably there's already some mechanism for carrying container
contents through a transition.
OK. I'm happy to consider the bug fixed if you are!
Good, I think this is an improvement.
I think I'd still prefer there to be some static indication that there is a
hidden (non-natural) object, even if you still have to mouse-over to identify
the object. It's too easy to accidentally leave an important tool behind a
tree or wall, and then having to carefully mouse over every possible hiding
place to find it again doesn't sound like fun (though definitely better than
having to right-click on empty space in every possible hiding place, as was
the case before the mouseover highlights).
That sounds ok.
But not allowing mouse-over discovery of naturally placed objects would be
annoying in the case that they are just barely visible - then you know they're
there, but it's very fiddly to actually select them. It would also be
confusing for natural objects which are totally hidden, because it would mean
you mysteriously can't put down objects in that tile.
Maybe the world generation could just avoid placing one-tile objects above
two-tile objects?
> I find this really mars the artwork.... It's also not terribly readable.
This is pretty much what I had in mind, and I agree it isn't beautiful or
perfectly readable.
> Can you guess what the second thing from the right is, behind the yew tree?
No.
Maybe in place of the highlight, you could have the foreground object be
transparent in the highlighted region?
Or just make two-tile-tall objects actually take up two tiles, so there can't
be anything behind?
I don't know what's best. But being able to hide objects from other players
seems strange and surprising, and if there's going to be any sort of conflict
in the game, I guess it would be heavily (ab)used. The neighbouring tribe is
coming to raid our village - quick, hide the pies behind the walls!
Sorry, I can't figure out how to do it in GIMP. But what I'd draw if I had the
chops is a pair of trees, one above and behind the other, with something like
the current stencil highlighting being drawn as if you were mouse-overing the
back tree, but drawn only on the overlap of the two trees.
Maybe it would look too noisy. I didn't have this case of two large objects in
mind, and really it would be better if it only applied to a small object
behind a large object. Can you detect that? Does the engine know that the tree
is drawn on two tiles?
Sorry, badly edited post there. Delete the "not only".
So I meant that obscured objects and obscured parts of objects should always
be marked. Effectively making objects transparent where they would otherwise
obscure something.
I'd say not only that hidden (parts of) objects should always be shown, even
when they're not moused over. This could be done for example by always drawing
the stencil highlighting on the foreground object.
Hiding the world state from the player for the sake of aesthetics seems like a
bad idea to me.
It looks like items hidden behind scenery are often invisible. If you dropped
the item, it appears when you mouse over its position, and you can interact
with it. But this seems not to apply to items which were on the map when you
were born. I also noticed that the remains of a burnt-down fire hidden behind
a wall couldn't be interacted with - I guess any result of a transition
becomes hidden?
Just tried this; I ended up with a directory without a transitions/ directory,
which led to a segfault.
"ln -s OneLifeData7/transitions/ ." seemed to fix it.
jasonrohrer:
> I wonder about hiding the transition list on the server only
I don't think you should worry too much about players being able to get hold
of the transition list. Given wikis and such, it's inevitable anyway. And
exploring the transitions outside of the game is less of a spoiler than it
might seem, because of the distinction between declarative and procedural
memory.
I did "spoil" myself for the present game by exploring the transitions in the
editor, but when I got into the game I found I could remember only a few key
surprising ideas. I discovered that steel existed in the game, but actually
producing it requires a graph of transitions so intricate that there was no
way I could learn it as a collection of facts. I'd have to learn it piecemeal
and in-game, learning how to achieve various intermediate goals by actually
performing the necessary series of steps.
Ah, very good.
Somehow my source directory, compiled from the v22 source distribution, did
have a binary.txt file for version 23. But I've tested that with binary.txt
deleted it updates only data files, and doesn't create a binary.txt file, and
that it updates the binary when binary.txt is there. How it came to exist in
my directory I have no idea, but hopefully it won't happen again. I've checked
that the latest source distribution has no binary.txt.
Could I ask for auto-update of the binary to be made optional, and preferably
disabled by default for the source release?
It's a security hole, and rather makes a mockery of the option to compile from
source.
Really I'd disable it by default for linux in general - it isn't something
linux users expect, and it's generally frowned upon for its security
implications.
The warning sound and the mouseover highlights help a lot.
I still find selecting small objects to be annoying and error-prone, though.
How about a minimum radius for the hotspot?
I think I'd also like keyboard controls - say roguelike "hjklbnyu." for
movement, with modifiers (e.g. shift and ctrl) for interacting with
neighbouring squares (or the current with '.'). Then some more keys for
interacting with clothing. I guess moving a square at a time means more
network traffic, but hopefully not so much as to be a problem?
As someone accustomed to using a keyboard for everything, I find the mouse
interface rather fiddly, and I frequently misclick. Too often this leads to
death while I have food within reach, because I didn't hit the right pixels.
It's also frustratingly frequent that I'll make it to a food source before
starving, only to find that I have something in hand and there's nowhere
sufficiently close to drop it.
So maybe as a slight modification to Vescator's idea, the "starving" state
shouldn't completely incapacitate you, but should let you move only very
slowly. That gives you a chance to feed yourself if you've planned ahead and
reached food, as well as allowing others to feed you.