a multiplayer game of parenting and civilization building
You are not logged in.
lychee wrote:A fertility boost to fatherhood — even in the absence of fathers/marriages, girls still have some baseline fertility.
33% based off whether a woman is married/child has a father.
33% based on yum up to a cap of +10 where you get the full .33
33% based on the temperature of the mother.
1% based on whether you have 15+ years of game development.1/2 of those can maxed by a player who actually wants to have babies while the other two require commitment either to game development or another person.
I’m generally in favor of this kind of thing, but to play devil’s advocate — fertility mechanics are hard!!
Tweaking fertility mechanics is a relative zero-sum operation. By giving one woman more kids, you take away kids from another mom. OHOL works that way because the amount of players at any given time is roughly constant.
I’m cautious about balance changes that favor big towns because in a purely mathematical world, the big families have an exponential spawning advantage over isolated eves or pseudo-eves. Pushing changes that favors big towns decreases the viability of eve/pseudo-eve play and encourages the development of mega cities.
Lineage bans definitely help eves (though not pseudo-eves), but the more exogenous mechanics Jason adds to balance this spawning distribution actually nerfs the impact of fertility boosts.
—————
What if spawning was tier based?
1. First balance small/big town/lineage spawns
2. Then spawn to any parent that is married
3. Only spawn to unmarried moms if married moms are unavailable
I thought that marriage would give a fertility boost if you didn't have the same last names. Otherwise it just adds "married to Name_Link" to the family tree. So ways to make new last names other than being Eve would be nice and might take some pressure off of that area...
I often wish I could pick a name and it's part of the reason I long to be Eve... I want to see the Bird family take over the world!
I remember you had a *married couples can pick a new last name* suggestion.
Tbh I think the problem with that one is that it’d become too easy to rename yourself if it was tied to something like marriages. A majority of lineages would probably die off solely because players rename themselves out of the line.
This needs to be discussed/debated for balance, but:
Orphans: Every child that’s born has some rate of losing their parent’s last name. Maybe mutate the last name to something that looks similar but is different (e.g. McAllister => McAndrews). Would help introduce last name heterogeneity to homogenous towns, if the incest is that much of a concern.
Initialize orphans with the same language/race, but consider them no relation.
Needs balance discussions because swords/eve griefing similarities.
There must be some benefit to heterogenous towns that outweigh the risk of outsider griefing (perhaps marriage is the benefit?)
A fertility boost to fatherhood — even in the absence of fathers/marriages, girls still have some baseline fertility.
In this thread (https://onehouronelife.com/forums/viewtopic.php?id=6814), futurebird raised the issue that it seems like there are a small subset of players who are SIDSing 200+ times per day.
Summons wondible. XD
I might work on this later in the week. The mapping is fairly trivial but I’m particularly interested in family line tracking and village tracking; maybe through dbscan clustering.
Welcome back, Jason!
So basically the point is to stream more and record as much as possible?
Agreed!
The only other factor I kind of want to add is that teaching other players can be a big part of the game too — or retention of new players.
In my view, sometimes the long-term goal of cultivating a good player base is equally important — if not more important than the tangible goals in OHOL (e.g. making that oil rig). Consequently, I’ll usually prioritize a new player who’s willing to learn over almost anything else I could be doing.
There’s a very famous adage regarding giving a person a fish or teaching a person to fish.
It’s important to me to give a good experience to players who are experiencing OHOL for their first couple weeks. IMO, that’s the most magical time of the game. In contrast, when you become experienced, the game becomes more rote and repetitive. So for me, I really strive to be that family member (amazing mom, amazing uncle) who taught me something cool while being badass and amazing when I was just starting out.
I don’t quite RP, but words can go farther than you might expect. Simple things like:
“Good job”
“Thank you!”
“Wow, that’s awesome!”
“I’ll miss you”
Can go a long way in making people feel valued and contribute to the “feels” that people have when playing OHOL.
This is a #life thing too, but compliment people more often (even for little things), and the world might get a little rosier.
In either case I think ohol is a bit too underpopulated and a lifetime is too short for most markets to work well.
If there were to be markets, I sort of prefer to see he stock market method.
Someone posts a selling bid, and someone else could post a selling bid for a different price and quantity, etc. Then buyers could take the bids or post their own buying bids for a price and quantity.
If no one takes, then stuff just remains unsold.
Works fine in a bartering system or any arbitrary currency.
To me, I think a currency backed in some essential resource would make more sense. Gold is non-essential and consequently not valuable in OHOL, so it’s preferable to pick something else like a banknote that represents one bowl of water or one iron ore.
Im personally a little skeptical of currency in OHOL’s case because I don’t think the markets will be stable enough. Not enough buyers and sellers (or surplus for that matter) to really allow stable prices to occur — the fluctuations would be crazy.
Some thread a while back someone suggested a fixed price that scales with the amount of goods in the market, but IMO that’s just as bad. Rarity doesn’t correlate well with value in OHOL (e.g. candles are super rare in OHOL but they’re also useless!)
Would also be interesting to compute /dies vs. play time (daily), but too lazy for that tonight. xD Might do it another day.
Maybe Jason should rate-limit the number of /dies a single player can do. xD
>.<
Put that in a spoiler! It's so long!
@Futurebird for Sunday June 2
Histogram:
(number of times used /die - number of unique players - percent contribution to daily /dies):
1: 103 (1.6%)
2: 45 (1.4%)
3: 30 (1.4%)
4: 21 (1.3%)
5: 21 (1.6%)
6: 22 (2.0%)
7: 21 (2.2%)
8: 12 (1.5%)
9: 7 (1.0%)
10: 4 (0.6%)
11: 5 (0.8%)
12: 11 (2.0%)
13: 3 (0.6%)
14: 6 (1.3%)
15: 5 (1.1%)
16: 6 (1.5%)
17: 3 (0.8%)
18: 6 (1.6%)
19: 7 (2.0%)
20: 6 (1.8%)
21: 1 (0.3%)
22: 3 (1.0%)
23: 1 (0.3%)
24: 2 (0.7%)
25: 7 (2.7%)
26: 3 (1.2%)
27: 4 (1.6%)
28: 2 (0.9%)
29: 1 (0.4%)
31: 4 (1.9%)
32: 2 (1.0%)
34: 3 (1.6%)
35: 1 (0.5%)
36: 1 (0.5%)
37: 1 (0.6%)
38: 1 (0.6%)
39: 3 (1.8%)
41: 1 (0.6%)
45: 4 (2.7%)
47: 1 (0.7%)
48: 3 (2.2%)
51: 1 (0.8%)
52: 3 (2.4%)
53: 2 (1.6%)
56: 1 (0.9%)
58: 2 (1.8%)
59: 3 (2.7%)
65: 2 (2.0%)
68: 2 (2.1%)
69: 1 (1.0%)
72: 1 (1.1%)
77: 3 (3.5%)
90: 1 (1.4%)
91: 1 (1.4%)
93: 1 (1.4%)
106: 1 (1.6%)
116: 1 (1.8%)
119: 1 (1.8%)
136: 1 (2.1%)
137: 1 (2.1%)
138: 1 (2.1%)
146: 1 (2.2%)
222: 1 (3.4%)
229: 1 (3.5%)
238: 1 (3.6%)
There were 427 unique players who used /die at least once on Sunday, for a total of 6573 /dies (56% of all lives) - average of 15.4 /dies per unique player.
Hurray for python (and dictionaries)~
Ignore this post, pulling some quotes from the eco wiki that I found interesting in some way or another:
For example, anyone can craft Hewn Logs at a Workbench, even before they've invested a single skill point; however, someone who has invested a skill point into the Hewing skill will become much more efficient at the task (meaning that it will take both fewer resources and less time to craft Hewn Logs, as well as certain other items made from wood). A person who has therefore specialized in the Hewing skill will be able to craft more, craft better, and craft cheaper than someone without it, thereby making them much more effective when selling these items through the in-game economy.
Once the Carpentry Table is up, someone with the Hewing specialty can craft Hewn Logs at greatly increased efficiency.
Example: Player A has taken the Gathering and Advanced Campfire Cooking specialties, and now they need a house to be built. Player B has taken the Hewing specialty, but he is in need of great quantities of food (as chopping trees is tiring work!). Player A and B, therefore, have an incentive to trade with each other -- Player A sells food to Player B, while Player B sells building materials to Player A. Both sides have specialized, and both sides have their needs met by engaging with each other via their world's economic system.
At a research table, you can craft Skill books, which will allow you to unlock new skill trees. Each book requires a large amount of materials, but one book can spawn an infinite number of Skill scrolls, which players use to unlock the skill. Therefore, in theory, only one of each skill book is needed for an entire server of players. Tip: on servers with high populations, it is often more economical to purchase some basic skill scrolls from players who have already crafted a skill book, as you may lack the resources or specializations necessary to easily craft a skill book of your own.
Eco utilizes a bartering system that trades items for items. To set up a trade, right click on the store inside of the building and set the price for a good (designated as the item under the 'Price' half of the trade screen) and the good for sale (designated as the item under the 'For Sale' half of the trade screen). You must then fill the storage of the store with the items you are selling. As players buy from your store, the items you set for the price will go into this storage
The exchange of resources in ECO is based on an entirely player-created economy which players can use to sell goods and services. Unlike most games which only allow players to sell items, Eco allows players to sell contracts for labor, which the game will enforce.
Need someone to build you a house? Take out a contract and they will complete the job, with payment being held in escrow until completion.
This system of contracts forms Eco's "quest" system, where a quest is an actual job needed by another real human in the game, which your player has the specialized skills necessary to complete. Through specialization and game-enforced exchanges and contracts, a rich economy will develop in Eco that forms the basis of all resource allocation.
There are two types of currency in ECO: player credit and minted currency.
PLAYER CREDIT EDIT
Player currency is created automatically when the player joins the world for the first time. Each player currency is unique to a specific player and can only be acquired by selling items to their Store(s). It may also be gifted with the /pay commandMINTED CURRENCY EDIT
Main article: MintSince player currency is inconvenient, players may want to invest in creating a Mint, which uses certain items to craft currency that can be used globally. Any player may create a currency, assuming there are no laws to prevent it, which others may mint if they have access to the mint. Minted currency can be created from resources as widely available as wood pulp, as rare as gold, or many things in between
INFLATION EDIT
Any number of Mints can be created, and more currency can be made with various resources. Since any player can mint any currency (except player credits) this behavior can cause rampant inflation. Eco players may use the law system to deal with this in various ways: By restricting the production of Mints or by taxing the creation of new currency
I'm fairly fond of this general idea (and the other variants that have been proposed in the past). xD
--------
((Don't read beyond this point if you have better things to do)):
I've always been sort of intrigued by the premise of what if the objective of OHOL was the complete opposite of the way Jason designed it. Like: the *only* way to play the game is to be reborn as your own grandchild++. If you failed to have any descendants, there'd be no way you could spawn into the multiplayer server until after some time period reset (in the mean time, you'd have to kill time on a local singleplayer server or a "chill donkeytown" server, maybe with a better "campaign" and some "AI"), after which point you'd never ever see that old family/town again.
It wouldn't be like "Minecraft" (as Jason often says he'd like to avoid) because having a living chain of descendants is pretty hard (in OHOL, lots of family branches die out all the time) and takes a lot of time/energy to raise a kid. In all likelihood, your chain will die out sooner or later.
Instead, there would be a powerful motivation to ensure that your kid(s) do well. You would *want* to teach your kids everything, from avoiding mosquitos or standing on items during a bear attack, how to run a diesel pump, or how to make pads. You'd *want* to help see your son get married, you'd be happy to see grandchildren, and you'd *want* to leave some kind of inheritance/property to your kids and grandkids.
You'd probably want your own kids to do better than your cousin's kids.
If a town is going up in flames, you might put your own family ahead of the rest of the town. Maybe you'll take a wagon and jump ship before it's too late, and look for greener pastures along with your kids. It'd just be you, your spouse (same objective/goals as you), and your children in a household.
It'd be a different feeling to the game, I wonder?
^^; this thread is pretty intense.
OHOL is a game; not everybody plays it to be 100% optimal/efficient, and honestly all each player is looking for is to have fun (however they find it fun).
With regards to "core concepts" of the game, Jason may have had something in mind while making the game, but that doesn't necessarily mean that players will play a game exactly the way a developer intended it (or the way experienced players think it should be played). That's natural. No developer can manipulate/force/control their players to play a certain way or feel certain emotions. However, they can design the game in ways that incentivize (or de-incentivize) certain behaviors.
In the case of OHOL, Jason can't force players to care for their offspring just by waving pretty words. That's outside of Jason's scope of power, and it's not very effective to complain that players aren't playing the game the way it was originally intended. Regardless of what philosophies or objectives or ideals we might have -- a gamer is only going to be looking to have fun.
However, how to get players to *want to care* about their offspring is another question entirely, and a much more interesting use of one's time to discuss.
A brute force temporary solution could be:
Firing Cycle 1: "Newcomen Pump"
10% chance to transition to "Rickety Newcomen Pump" (a transitional object indicating an older pump that *could* exhaust).
Firing Cycle 2+: "Rickety Newcomen Pump"
10% chance to transition to "Exhausted Newcomen Pump".
The mathematics of this checks out such that you still have an expected value of 20 uses (1/0.1*2) on the pump, although the transitional object ensures there is at least two uses on the pump. By adding more transitional objects, you could guarantee a higher number of minimum uses.
Jason had a thread on this some time ago, but idk if it got fixed.
There's a 5% chance that the pump exhausts each time it fires, and currently there's no method to count the number of cycles the object has been through since each firing creates a brand new object. There is no persistence of information from one firing cycle to another.
Requires engine work. Can't have a cistern both hold buckets and bowls. As is, it either holds a bucket (10 water) or it holds a bowl (one water). This is why we don't see bowls already being usable on cisterns.
Would assume the same is true for compost piles.
Well, nUses is stored at an object level. It’s possible to use different objects of the same size (e.g. bowl vs. waterskin) on an object like a pond because each transition decrements nUses by 1, so it’s not really the issue of multiple objects, but rather the fact that nUses can’t decrement by a variable amount.
If the transition struct is changed such that the nUses column is changed from a Boolean to short (signed char would even work), it would be possible to have a transition increment or decrement nUses by a predetermined value.
Also, technically this is all brute-forceable without any engine work by making each “use” a new object. So 21 objects for a Compost Pile, with the transitions manually made. Of course, I don’t really expect Jason to find this to be an attractive solution since it would bloat the object table and transition table if a similar approach was taken for other things.
When I first started playing OHOL, something that confused me immensely was why you couldn’t use a bowl on a pile of Composted Soil, or why not a bowl on a Cistern, or empty a half-full bucket into a cistern.
It didn’t make logical sense to me, and in fact it took me a long time to learn OHOL’s quirky mechanics because all the soil sprites look very similar. It’s a bit of a frustrating experience, and I’m sure all of us see new players struggling with this quirk all the time.
This is a suggestion for OHOL or CCM:
Bowls AND Buckets should work on Cisterns and similar water sources.
Bowls AND Baskets should work on Compost and other soil sources.
Implementation:
1. Change the uses of a Compost Pile from 7 baskets to 21 bowls (the smallest unit).
2. Make bowls usable on Compost Piles.
3. Make Baskets decrement 3 uses on each transition.
If modifying the use code in OHOL is non-trivial, this approach can be brute-forced by making 21 Compost Pile objects (representing 1...21 uses). Using bowls makes transitions from object n to object n-1. Using baskets makes transitions from object n to object n-3.
I believe that changes like these are important quality of life improvements that make OHOL more approachable to new players.
PS.
- Please make salt water look obviously different from fresh water.
- Please allow us to dump salt water.
Maybe add the ability to make a directional signpost.
Or dirt roads.
Because there's really no real reason/stake to play for your "kids".
OHOL is a game in the end, and the primary objective of each player is to have fun (however each individual player defines it).
Consequently, some fraction of players consider it more fun to do certain game projects (e.g. build a house) than raise kids.
Some fraction of players are the opposite and they really enjoy kids.
A good portion of players play for the longevity of their settlement ("wanting to leave their mark on the world") -- which can translate into a desire of having girls -- but this is more about having a high frequency of kids more so than treasuring each child deeply and equivalently. In most circumstances, most players don't care if it's their own kid versus someone else's kid, as long as there are girls to continue the settlement.
In OHOL, the game mechanic simulates "caring for kids", but that feeling isn't actually the same as it is on Earth.
jason made a short video about art games:
Thanks for the video!