a multiplayer game of parenting and civilization building
You are not logged in.
The home marker distance indicator shows distance as if it were real-world distance, i.e. the square root of the sum of the squares of the X and Y distance. But for travel purposes, the direction makes a difference. You travel one tile diagonally in the same amount of time that you travel one tile horizontally or vertically.
So something that's 1.4k directly north-east is effectively only as far away as something 1.0k directly north or directly east.
Distance for travel purposes is effectively the largest of the X and Y distances, not the square root of the sum of the squares of the X and Y distances.
... of course, people often won't travel perfectly diagonally. If you don't, that makes the effective distance longer. In the worst case, you'll travel only horizontally and vertically, which makes the effective distance the sum of the X and Y distances.
So the practical effective distance will be somewhere between the largest of X and Y, and the sum of X and Y. The length of the hypotenuse is probably a reasonable estimate, since it's always going to be between those two distances.
This is funny, but remember that there's no way to learn how any of this works other than trying it. A huge part of the game for new players is sheer guesswork.
Private servers are toys. Public servers are games.
//once a badland is void of iron, leave a large x in white stones, stacking two flat rocks in the middle to prove it’s man-made. (Maybe also when a green biome is void of milkweed)
Oh, now that's a neat idea.
Makes me think of another: if you spot an iron vein while you're out gathering (no matter what you're gathering, it doesn't have to be iron), mark that spot! Rearrange all the nearby stones into some obvious pattern that's easy to spot from far away. Like, make them into a big long line ending at or near the iron spot.
The thing is if you give options to early game how much do they really matter? Early game is already something that can be finished within one to three generations (my definition of early game is no sheep, all steel tools unfinished.) Adding in more options at the very bottom might seem great but if you are only using these options in the first 40 minutes of a villages life it seems like a complete waste of development time.
Not to mention this could become noob traps for players not knowing better. "Oh they made copper tools, I guess they were too lazy to go get iron /die." The biggest issue with early game besides almost always being the same thing is the amount of people just sort of standing around doing nothing.
There's always going to be one path that's optimal, and you and pein are always going to find it. That's fine. As long as the other paths are interesting and fun then they'd be a worthwhile addition to the game (for everyone other than the minmaxers).
The "trunk" as I put it extends up through the newcomen engines. I'd love to see more content that creates multiple intertwining pathways not just in early game but all the way through. I also think you're dramatically underselling the value of early game simply because you're good enough to blow through it quickly. Most people spend a lot more time there than you do; you don't notice that because it doesn't happen when you're around. Also, there's plenty of time spent in the middle game (post sheep and tools) that's still a lot of work, still mandatory, and still very repetitive. Lots of room there for the kind of diverse pathing that I'm asking for; lots of value that it would bring to the game.
Rather than preaching at kids to stop wasting food by eating pies, we should be educating adults to stop wasting water and labour by eating from berry bushes. [..] You cannot have a village without berry plants and some berry eating will inevitably happen, but experienced players should view berry eating on a similar level as carrot eating. Once you have sheep, stop eating berries/carrot and switch over to a mutton pie-based diet as soon as possible.
Oh, lord, I just realized you are right. In the typical village where you have a surplus of mutton and threshed wheat (because soil demand required making compost but pie consumption has not kept up), the surprising result is that NO ONE should eat berries. Not even children. Not even noobs who eat as soon as they lose a single pip. ALL of those players, as wasteful as they are, should eat mutton pies instead of berries.
Say you have a bunch of noobs to feed. Say they are going to eat something as soon as they lose one pip. Say you need to feed them 48 times (to make the numbers nice and round; imagine feeding 12 different noobs four times each if that helps).
To replenish their bar by one pip, they either need 48 berries (i.e. seven bushes) or twelve pies. Each berry fills their bar and wastes four pips. Each bite of pie fills their bar and wastes fourteen pips.
Seven bushes:
Resources: seven water, seven soil
Effort: gather seven water and seven soil
Twelve pies:
Resources: three water, one kindling
Effort:
. Gather three water, three bowls of wheat, twelve mutton, one kindling
. Make three flour, make three dough, put dough on twelve plates, put mutton on twelve pies
. Light oven, bake twelve piesEven at its absolute most wasteful, it's better to feed people with mutton pies than with berries if you have surplus mutton and wheat lying around. It uses fewer resources, although perhaps more effort (although quite honestly I'd rather bake twelve pies than tend seven bushes, it might take a bit longer but it's more fun).
Eating pies instead of berries when all the surplus wheat and mutton has run out is a different matter. At that point you have to factor the following into the cost of twelve pies: the six soil, three water, and three tillings required by the three wheat, plus the effort of planting and harvesting wheat and feeding and slaughtering sheep. It's still pretty close, and if you assume these children / noobs are good enough that will actually delay eating until they need two berries to fill them up rather than only one, then once again feeding them pies comes out on top.
I feel like the past few updates have had very little effect on the overall game. While they did add a crazy amount of new items and recipes, those items are usually just crafting ingredients for the main item of the update. And while the main item of the update is usually cool and different, it doesn't really add anything to the game, which means the gameplay loop is exactly the same as it was in the previous version. The main item of the update takes a lot of time and effort to make and is usually made by one or two people, but is only made once to see the new shiny thing and then never touched again. I feel like this applies to every update that came out since the Jungle update in one way or another.
I agree with this.
I don't think that necessarily means that the recent updates are bad. I like that all of these new things exist, even if they don't modify the core gameplay. Toys and trinkets and challenges are good.
But I agree that more content that enhances the core gameplay would be very, very welcome. Greater diversity in options among the required paths, and greater interaction between those paths. Right now there's a very small set of things that you must do, and you have no realistic alternative to doing them, and you must in general do them the same way each time, and you must devote most of your effort to doing them.
I love that we have shiny toys like the cars and the radios and the christmas trees, but I'm sad that so few people will get to make them because we have to spend so much time fixing the broken compost cycle or everyone starves. We have lots of other things we can make along the way, like stew and tacos and clothing and crowns, but none of them are integrated into the path of civilization. They're branches away from the trunk - they aren't necessary and they don't go anywhere important.
The path upwards along the trunk isn't bad. It's good. It's complicated and challenging, but it's linear and mandatory. I'd love to see more content that transforms the tree trunk into a set of intertwining pillars.
Still thinking about a RAM-based solution to the back-end database.
How would you implement that, if RAM were not a concern?
(I am not an expert, nor even a real developer)
Am I correct in thinking that the current database stores the values on disk, and stores a hashtable in RAM that contains pointers to each key's value on the disk, but that the values themselves are not stored in RAM, and thus every value read requires a disk access?
Since you've determined that disk reads are your bottleneck, it seems like using some kind of caching of the keys' values in RAM would speed things up. Here is a short article about some different caching strategies and their trade-offs. You'll also need to consider things like cache invalidation, time-to-live, and cache eviction when out of memory. You could write your own caching mechanism, or you could integrate an off-the-shelf product like redis or memcached.
Alternately, instead of keeping the "source of truth" on disk and caching whichever results happen to get queried, and thus having to deal with issues like cache invalidation, you could instead keep the entire database in RAM and use the disk only for long-term persistence. It seems to me that for OHOL you could use a very lazy flushing-to-disk strategy, only updating the database (or even rewriting it entirely) on disk every now and then, perhaps every few seconds. As long as the server is running, you don't need to worry about the data on disk being stale, since the RAM copy will be the source of truth. If the server is shut down gracefully, then you'll have ample opportunity to flush the RAM copy to disk after the server stops writing to the database. And if the server is ever halted ungracefully, you'll lose a few seconds of data - which won't matter, because everyone in play will have been summarily disconnected anyway, with no expectation of resuming where they left off.
Keeping the db in RAM means you'll have to decide what to do when you run out of memory. Or you could monitor the db size out-of-band and just make sure it never grows larger than the amount of RAM you've purchased, knowing that if it ever does the server will probably crash ("If you choose not to decide you still have made a choice.").
If you use a cache, you can write your own or use something existing. The leading candidates appear to be redis and memcached. Here is a nice post describing the differences between them and showing several different ways that you can use them. It sounds like redis could be a good fit for you - you can use it to store all of your data, it will store it all in memory for fast access, and it will write it to disk so that you won't lose it if the system halts.
A quick-and-dirty solution would be to keep using your database code exactly as you are, but store the database file on a ramdisk. Have something that periodically copies the file from the ramdisk to the SSD. You could even get away with not trying to make the copy operation atomic, if you do some kind of integrity check on the database when the server starts up and just bluntly delete any records that aren't consistent. In most cases probably everything would be just fine, and in the worst case you might occasionally lose an object here or there if the server ever gets halted ungracefully.
make an outpost [..] When you get so many excess persons, would help on the lag for others, its unsustainable to have so many players in such a small space.
I don't think that lag is affected by the number of people that are in a single location.
Having many people in a single location means that the server messages for that area have to be sent to more people, but I am pretty sure that's a fast operation and is never a bottleneck.
|--> server1.onehouronelife.com : 8005 ::: 45 / 120
|--> server2.onehouronelife.com : 8005 ::: 92 / 160
|--> server3.onehouronelife.com : 8005 ::: 37 / 160
|--> server4.onehouronelife.com : 8005 ::: 34 / 160
|--> server5.onehouronelife.com : 8005 ::: 1 / 160I suspect that Server2 is where the pros are. First off, the manual connections by pros to Server2 will increase the player count on that server above what would be sent there by the reflector as an even share of non-manual connections. Secondly, the pros are going to do a better job of keeping everyone alive, which increases the server's total share of the population. The longer the average lifespan, the larger the resulting player count.
This is the opposite of what we had before Jason's change this evening. All servers would have (roughly) the same population regardless of how quickly or slowly the players on each one died.
And this still wouldn't solve the problem of player interaction on multple servers (yeah, they would share the same underlying map DB, but that doesn't mean they'd see other players walking around from other servers, because that's not in the map database). In other words, the actions of other players on other servers would initially be invisible and then "pop in" the next time you re-fetched that portion of the map.
Unless he means one central "interaction" server managing all users connecting to multiple DB backends..... maybe that would help, somewhat (ignoring network latency vs straight local SSD access), but that certainly wouldn't scale to millions or billions of users!
Hm.
You could have a three-tier architecture, one not too dissimilar from the two-tier architecture you have now. Tier One would be a reflector like you have now but with a bit more logic, Tier Two would be a pool of gameplay servers like you have now but without persistent data store, and Tier Three would be a pool of database servers. Move the spawning logic from the current server tier to the reflector, so that the reflector can make decisions about where and under what circumstances the players spawn. The reflector sends players to a specific gameplay server depending on their spawn location. Each gameplay server is responsible for a given set of regions of the map. Each server uses a networked database, locally cached in RAM, for both the map data and the player data. The network database is itself divided up between multiple db servers. That allows you to scale up by adding servers to the gameplay tier and/or the datastore tier as needed, depending on where the bottlenecks are. Only the reflector would be a single server, but it would only be used once each new connection, not constantly during each game.
Most of the time everyone would be localized on their own gameplay and datastore servers, and most of the time player/map interactions would be in the local server's RAM cache. Cross-region interactions involving players from one region and map objects from another region would have to hit the network, and cross-region player-player interactions would hit it even more. But those will be rare. You want them to be possible ("everyone is playing in the same one big world") but even so they'll still be rare.
You could even set it up so that the gameplay servers are also the datastore servers, so that each server keeps its assigned map and player data in RAM and serves it up locally to the local gameplay instance (common) and remotely to the remote gameplay instances (rare). Gameplay servers would have to know which of the other servers to query for which map regions.
All very complicated. But possible!
Whether it's feasible or valuable is an entirely different question.
In this post Gederian speculated about using memcachedb (etc) to make a scalable db backend that could be shared by all the servers, making the whole thing effectively a single server.
In this post I speculated that eliminating sticky sessions in the reflector could bring about results similar to having a single server.
Agreed that avoiding lag is the higher priority.
Just to keep clarity on the other issues: With the previous load balancing algorithm, a significant chunk of the playerbase would find themselves with no children when the global population fell, due to the servers being removed from the active pool. With the current load balancing algorithm, everyone experiences a modest reduction in fertility and no one experiences a dramatic reduction in fertility (which I think is a big improvement); but at the same time, server populations get low enough that each server has only one or two active towns.
Anecdotally, I think the change has dramatically improved the subjective impression that towns often fail because there just aren't any children born. I think the fix to the temperature-based weighting has helped a lot with that as well; experienced players (such as those on the forum and discord) know to stay warm and generally have plenty of children, while inexperienced players stay cold and childless - but we don't hear from them because they aren't on the forum or discord, and they were probably going to die anyway regardless of fertility because they tend to starve or get bitten.
The low-population / few-towns issue is new. I think it's a lesser issue, but it's still an issue. It's worst when there's only a single town on a server; when you get lineage banned from that one town, you will spend a long time playing in Eve camps (either as Eve or a low-gen child). The more towns there are on a server, the fewer Eve spawns there will be and the fewer Eve camps you will play in, as you will instead bounce between towns with each life. If the server population is low enough, it's even possible that the only town on the server will die from infertility simply because every player on the server is lineage-banned from that single town simultaneously.
If server performance were improved, you could raise the upper add-a-new-server threshold. And if you raised the lower remove-an-existing-server threshold, the not-enough-players-to-keep-towns-alive problem would be ameliorated. And if you had a large enough spread between the upper and lower thresholds, you'd reduce the frequency of adding and removing servers, which would ameloriate the everyone-on-a-server-becomes-sterilized problem.
So I have to ask, does food waste even matter?
No.
Good post, lots of good details. Thanks.
---
I don't worry about the heat placement of anything except the berry farm and the kiln/forge. The berry farm will have a lot of people spending a lot of time on it, and most of them will be low-skill players (because most players are low-skill). It's very important for it to be warm, because that has a very large effect on the overall food consumption of the camp.
Having the forge be a good temp is valuable because it will be occupied by high-skilled players doing very important tasks under tight time constraints. It's very helpful for them to not have to stop frequently to eat.
Everything else (i.e. the pen and the bakery) will only be occupied for extended durations by a few people, probably higher-skilled, doing non-time-sensitive tasks. Keeping their food consumption low is nice, but not crucial. They'll have access to food and the experience to not starve, and by the time the pen and bakery are in constant use the town's food supply will be stable and abundant, so it's fine if a few people are too cold or too hot.
---
I keep all my kids and recommend everyone do it. Any kid that can be a net producer is an asset, not a liability, so the trick is to make sure they are net producers.
How?
Tell them to gather food! Give them a basket (give them yours, and go make a new one yourself) and tell them to bring it back with food. If they were going to be a burden, they'll die. If they live, they're an asset.
The ones that clearly know what they're doing can be repurposed later to gather wood and clay and iron and soil.
The ones that are noobs but show some promise, i.e. they ask what to do or how to do it, give them some assistance; show them what to do once, give them encouragement and a positive experience, then turn them loose and hope for the best.
The ones that seem like they know what to do but are just hopeless at it will die, and that's okay. They'll learn to do better after spending some time in more-developed settlements.
---
At first I wanted to keep all my kids from the moment I spawned. Now I don't keep any of them until I have found my spot. It's not feasible to look for a spot and have children follow you, even if they are old enough to feed themselves. They move much slower than you do and have to stop much more frequently to eat. Coordinating movement between multiple players is difficult under any circumstances. Progress will be very slow, and they are likely to either get lost or die trying to keep up. The result is that you will fail to find a good spot and fail to establish a good camp; your children will have had a miserable, difficult, and boring life and will die without having created a lineage.
Sometimes I'll keep my very first child and carry it with me while I search. That can be fun if there's some decent conversation between you, but it can also be very boring for your child who is essentially along for the ride with nothing to do. And it can be a long ride. Finding a good spot could take five minutes, or it could take twenty minutes.
---
The search for a good home is also a race against time. The more time you spend looking for a spot, the less time you have to produce children who might carry on the lineage. Accordingly, sometimes I will take a chance on what looks like a promising spot without knowing that it's perfect. I won't necessarily count the milkweed plants, I'll just be hopeful that, if the nearby grasslands looks big enough, it probably has enough milkweed to get started. I'll assume that no matter what, it'll be possible to get the resources needed (food, rope, clay, reeds, soil, iron, rabbits, stones, etc) even if I or my kids have to travel some distance to find them.
My minimum is "warm, next to water, near grass". Warm meaning desert, or jungle with a sufficiently large area clear of trees and mosquitoes. Next to water meaning at least one pond within a few tiles of where I want to put the farm and at least two more fairly close. Near grass meaning a large green grasslands within easy walking distance. If I can find that much, I'll take it.
---
i wouldn't put oven at all before sheep cause there is no benefit making 4 rabbit pies or carrot pies early on, over gathering raw food, and focusing on tech. but somebody will snap a stupid oven somewhere and better to do yourself.
I'd go ahead and make the oven. Like you say, someone will do it anyway, so it's better you place it well. And like it or not, someone is going to go hunt a ton of rabbits; might as well have someone make them into pies rather than cook them on skewers, especially if there is wild wheat nearby.
I think we need a "partial shutdown" state where babies are allowed but not Eve spawns. At the moment server 5 never reaches the shutdown threshold because eves can still spawn. If we can disable eve spawning then lineages could die out naturally.
That's a great idea, but would be a pretty big change. The reflector doesn't know anything about spawning conditions on the servers; it only knows each server's max population and current population. The server only makes a decision about whether the player will spawn as an child or an Eve after the client has been sent there. And similarly, the server doesn't know anything about its state as seen by the reflector - the reflector knows which servers are "active" (i.e. will receive new connections from the reflector) but the server has no idea whether it is active or not. It just accepts any and all connections - whether from the reflector or from manual selection - until it reaches its max, and then it stops accepting new connections.
To implement your idea, the reflector and the servers would have to have some way of mutually knowing that any given server is being made inactive and should reject connections that would be Eve spawns.
But also, note that the server can't determine whether or not a new connection will spawn as an Eve until it knows who the player is! If it's in "no more Eve" shutting-down mode, it can accept some players but will have to reject other players (ones who are lineage banned from all current lineages on the server). Whereas today, a server either accepts all new connections or rejects all new connections without regard to which player is connecting.
So it would take a significant degree of changes. Maybe Jason can do it quickly and easily, I dunno. Obviously that's up to him.
And if I ended up at a pro town which kills newbies, I'd probably slack off there.
I would grief it.
... and I don't grief. But I'd make an exception for a town full of assholes.
What is the actual maximum of a server btw?
It says 160 for all servers except server 1 at 120 but never seen this many on one server, at which point it starts to be too much for a server?
Each server has its own defined maximum, which is what you see on the server report. However, in November Jason tweaked the load balancing algorithm to cap each server at half of its defined maximum, so now most servers will be maxed out at 80 and server1 will be maxed out at 60. He did this as a quick fix to solve reported performance problems post-Steam release.
I don't know how Jason determined what the maximum for each server should be. I know he expected it to be higher (200 per server) early on in the game's development, but reduced it sometime after the initial release. He's also done a number of things to improve server performance, like replacing the original database code to use a much faster algorithm.
we could maybe have 100 players on a server which would be enough to make it really interesting
The current problem is not that we can't put lots of players on a server. The current problem is that the population on each individual server is allowed to become low when the global population falls, rather than shutting down servers and consolidating the players onto fewer servers when the global population falls. But this is deliberate; the alternative is that servers are shut down when population falls, which kills all the lineages on the servers that are being shut down.
they are way too big i think
You're talking about the size of the map? That has no impact on server capacity or performance. The map tiles don't exist (and therefore don't consume resources) until someone goes there.
Not to hijack, but it's worth mentioning Awbz' prebuilt server for Windows:
Download the win_full package
Unzip it
Go to the "server" folder, right-click on "runServer.bat" and choose "Run as administrator"
In the game client, connect to 'localhost'
Many different options available; choose the one that works best for you!
Nice! Thanks!
I've been spending most of my time cutting down all the trees in the jungle and spreading out the wood to trap the mosquitoes in the most distant corner.
Oh, I guess that was you I saw yesterday. I said "WHY NOT STACK" and you said "TO TRAP MOSQUITOS" and I was like "OH RIGHT GOOD IDEA".
Really wish more people would help pushing mosquitoes
Count me in.
Thanks to those of you who tell people to get off jungle and desert tiles if they get bit.
I've been telling people "GET COLD" but that's probably a mistake, since they probably have no idea what temperature means. Probably need to say "GET COLD" and then one second later say "GET OFF JUNGLE", or maybe vice-versa. They need to know what to do (get cold) and how to do it (get off jungle), or alternately what to do (get off jungle) and why to do it (get cold). The two together will probably spur faster compliance than either one alone.
If its just a matter of more people knowing how to compost then i got a way for parents not to have to teach their children how to make it: https://onetech.info/624-Composted-Soil
Fuck that.
Half the fun - for me - is learning things IN the game, not studying a spreadsheet. People like me may be in the minority, but you don't get to tell me how to enjoy myself.
You don't want to teach me? Fine. Go play how you like. But plenty of people love the hell out of teaching (and learning!), and find it the very best part of the game.
I taught someone compost the other day, and as far as gaming experiences go, I'd trade it for all of the "successful" villages you played in that same day.
One server is not enough to handle all the players. Making that one server large enough to handle all the players may not be technically possible, as the load on a server (reputedly) increases non-linearly with the number of players.
In other words, putting twice as many players on one server may require much, much more than twice as much RAM or CPU. This would get expensive, and could become impossible at any cost.
(I'm not certain what the exact constraint is. My guess, actually, is that the number of disk seeks increases exponentially, in which case it wouldn't matter how much RAM or CPU the server had. Beyond a certain point the server would start responding too slowly to client requests, and the game would become unplayable, and there would be nothing anyone could do to make it go faster. But this is only a guess.)
In short, if you have a kid, and that kid says they are new, dont feed them.
That works exactly once.