Population questions

joshwithguitar · 2017-07-06 07:17:20

I was thinking about population dynamics in OHOL and it seems that there might be a number of issues that have to be dealt with.

Firstly, the overall number of users is likely to decline after launch. How will the servers deal with this? If the decline is spread throughout the servers then each might become fairly sparse. So it might make sense to drop off servers and just accept that some of the worlds that have been created will cease to ever be active again.

But if you drop servers off we could have another issue. Population won't just vary over weeks but will likely vary quite a bit during each day as as player numbers naturally rise and fall. If we send new players during the natural daily decline to a smaller number of servers you'll end up with a whole bunch of servers going to a population of zero and then later in the day respawning a lots of Eves when the numbers increase. This doesn't seem ideal.

So are there any plans in place to deal with these issues? Overall it looks like the fluctuation of current user numbers is going to have a pretty massive effect on how these worlds develop whatever method is implemented.

jasonrohrer · 2017-07-06 16:20:11

If you look at the reflector/server.php code in the source, you'll see the current algorithm, which works like this:

1. In general, always send people to the main server. This server is currently set to support up to 200 simultaneous players before new players are rejected (but that number will likely change once we actually get a crowd of people on there... maybe more than 200, maybe less).

2. The other servers (there's currently only one, but I can bring up others as-needed with a few mouse clicks) are all "secondary" servers, only to be used in the case of the main server getting full. Furthermore, they are tiered, so the third server is only used if the second server gets full, etc. As the population declines (like at night, when people are sleeping), the secondary servers will no longer be used, and everyone will be on the main server.

3. The balancing alg works like this, assuming that each server has a 200-player hard cap:

A. If the main server has less than 20 players, set its spreading flag to false.

B. If the main server has less than 100 players, and its spreading flag is false, send new players to main server.

C. If the main sever is 95% full or more, go to E.

D. If the main server has more than 100 players, or if its spreading flag is true, set its spreading flag to true, then flip a coin for each new player and send 50% to the main server, and for the other 50% go to step E.

E. Look at the next secondary server down the list.

E2. If the secondary server has less than 20 players, set its spreading flag to false.

E3. If the secondary server has less than 100 players and its spreading flag is false, send the player to it.

E4. If the secondary server is more than 95% full, return to step E for the next secondary server.

E5. If the secondary server has more than 100 players, or its spreading flag is true, set its spreading flag to true, then flip a coin and send 50% of players to it. For the other 50%, return to step E for the next secondary server.

Once the population reaches a certain threshold, we start spreading players evenly to the next secondary server, resulting in these two servers reaching even population sizes over the long run. But once the balanced populations get too low, we switch out of "spreading mode" and stop sending new players to the secondary server entirely, and it becomes a "Children of Men" scenario while the last generation of people live out their lives there.

This works similarly when the population is big enough for three servers. We keep spreading them evenly until the spread population drops below the 20 threshold, and then suddenly stop spreading them.

Actually, the spread isn't even with three or more servers. Because of the multiplying fractions, only 25% end up on the second and third servers. With 5 servers, the fractions are: 50%, 25%,12.5%, 6.25%, and 6.25%

Of course, this means that in a really heavy population boom, the main server will still reach 95% faster than the rest, and so on down the line.

Maybe it's okay... but the algorithm can be improved to make it more even, someday.

I just realized that you can currently "game" the placement alg at the 50/50 stage by suiciding over and over until you finally land on the server that you want to play on.

I can fix it by seeding the random number generator with your supplied email address. However, the correctness of that email is not currently verified. It could check that the email exists on the ticketServer, but even that's not so great, because you could try known email addresses until you land on the server of your choosing (assuming that the reflector doesn't actually log you in and block other people from using that email address). Even if we verified their account key as well, you could share your email and key with a friend so that you both land on the same server (with modified clients that send separate account details to the reflector).

Well, I guess modified clients can bypass the reflector entirely, so I shouldn't worry about them. There's also a useCustomServerAddress setting that can be used to bypass the reflector without even modding the client.

So, I guess I just need something that will work for the average player who knows nothing about this, to prevent repeat-suicide until you end up in the "old world," because if everyone is doing that, the load balancing essentially doesn't work.

So doing it by email---or even better, IP address---is probably sufficient.

joshwithguitar · 2017-07-07 12:17:43

Thanks for the detailed response!

I've run a rough simulation of your server system in which I had a max of around 1000 players and a min of around 500 over a day.

What I found happened was that during the times with the most players 7 servers were populated with a distribution something like:
191 191 191 190 100 50 50
So the first 4 stayed 95% full 5th around 50% and the next 2 25%

During the times with the least number of players the last 2 servers would go extinct and the distribution would be something like:
189 184 74 33 33 0 0

Would it make sense to try to maintain a bare minimum population on each daily active server in order to minimize the number of Eves that have to be spawned each day? Ideally the player would always be born to a lineage that stretches back to when the server began, and Eves would only be spawned when there was a surge in the overall player population, such as during the launch.
If a server continued to languish at a small population for more than a week without ever rising you could have some method of letting it die off knowing that it is unlikely to be needed again.

jasonrohrer · 2017-07-07 15:39:26

Well, those numbers look reasonable to me.

I do want the majority of players to have a "full server" experience, and have the "desolate server" be a more rare experience.

In your last case, where the population falls to 513, we have 72% of the player population on very full servers, 14% on an almost-half-full server, and 12% of players on desolate servers.

An even spread across all 7 servers would put 100% of players on an almost-half-full server. But trying to maintain an even spread no matter what would mean that sometimes the entire population of players experiences more and more desolation. In the case of a dip in population, we really want to consolidate somehow and bring the remaining people together onto the same server.

The reflector currently has two main parameters;

startSpreadingFraction and stopSpreadingFraction

The first is the fullness threshold on a given server where we start spreading it's players 50/50 with the next server on the list, and the second is the fullness we need to dip below to stop the 50/50 spreading (in which case, servers further down the list would get no new players).

Can you run your sim with various parameter settings and take some measurements?

Like, number of lone eves? Number of times a server gets cut off from new babies and dies off completely?

Currently, the reflector is using 50% and 10%. Maybe other settings are better.

Also, if we count the number of servers that are currently being spread to, we can spread with different splits along the way (instead of 50/50 at each step). Like with 7 servers, the first server should send 6/7 to the next server, and that server should send 5/6 to the next server and so on.... I that should put 1/7 on each.

Yes, the front server starts with a higher pop, so during a boom, it will keep a higher pop, but only for an hour max, until those people die. After that, each server will have 1/7 of the population.

We could still keep the stopSpreadingFraction, and once the 1/7 amount dips below a threshold, we start letting extra servers die off and focus new players onto the remaining servers.

But I'm not sure if that's better.... maybe there's something good about keeping the top servers more full.

We can either give most players the better experience, at the expense of some players having a less good experience, or give everyone the same mediocre experience.

The equality version obviously can't be gamed as much through custom server picking (i.e., ignoring where the reflector tells you to go), because all the servers are more equal (though the main server will still have the oldest civilization, always).

joshwithguitar · 2017-07-07 16:09:50

I agree that it is probably best to try and concentrate population rather than spread it thin, what I was considering is some way to maintain a small population on the servers that would otherwise die out, just to keep the continuity and prevent new Eves. Perhaps make sure they get new players after they drop below 10. Only problem is that it would be hard to fit such a thing in with your current system as the last servers would have to somehow guarantee that few players join them.

I've a quick run of some different threshold values and the main difference you get from adjusting the upper threshold is the number of servers that end up spawning. When it is set to 75% 10% you get a maximum of 6 servers and only one drops down to 0 during the day, so this could be better.

At 87.5% 0% you get 6 servers and none ever drops out... perhaps once a server starts spreading it should remain spreading?

jasonrohrer · 2017-07-07 16:58:05

Well, the problem with 0% as the lower threshold is that the population will remain spread, forever, no matter what, after it starts spreading. So if it dies down to only 5 players, there will be one on each of 5 servers. At that point, they should obviously be together on one server.

I'm trying to make a system that doesn't require any manual babysitting.

joshwithguitar · 2017-07-07 17:06:50

Hmm, maybe 5% would be better.

I've uploaded the sim as a webpage so you can try tweaking the numbers yourself:
http://joshuacollins.net/ohol/serversim.html

Last edited by joshwithguitar (2017-07-07 17:11:15)

jasonrohrer · 2017-07-07 21:12:59

Wow, sweet!

Ain't javascript grand? Too bad its too slow for more elaborate games...

jasonrohrer · 2017-07-07 21:14:44

What average lifespan per player are you assuming here?

Looks like you may have it set at 60?

joshwithguitar · 2017-07-08 06:08:07

I just did a calculation, average life span is currently ~30 years.

I've set it so that you have a 5% chance of dying in each of your first 5 years, then a 2% chance of death each year after that until 100% chance at 60.
I've also set it so that a player has a (years of life)/60 chance of starting a new game after death.

I didn't see any real difference in the outcome after modifying these numbers. You basically have the same thing happen if you have everyone live to 60.

Purumus · 2017-07-25 08:34:47

Josh, how do you think that the current game would change because of the number of people and their longevity? I've been playing it frequently, and I keep imagining that some of the issues will either be solved by the masses or exacerbated by them, especially when trying to synchronize the things that we would be trying to build together, or amidst a lot of clutter left by others. But when playing and thinking of what feels in-theme, I don't know how to project and resolve it based on player numbers and on-screen items. Maybe some kind of Fits law calculation?

Dogamai · 2018-03-11 08:45:29

I would suggest instead of changing your spread algs, what if you update the spawn radius instead?
So if a server has a really low number of players, they all spawn close to eachother.
As the server population increases, increase the spawn radius.
Then you have the ability to tune average town populations to suit the tech growth rate as you implement higher tech levels.
Could even have the spawn radius tied to the local tech levels as well. So if you have an area with high level tech items built, the spawn radius centers there and shrinks, to help grow populations in higher tech areas, since higher tech areas need more people to sustain them.

Dogamai · 2018-03-11 08:58:54

And thinking about it, you could curb the spawn center at the very high end of the local tech, so once a village has grown to the end of the tech tree and sustained for a while (getting stagnant gameplay-wise), push the spawn radius center away from the village, so people can start a fresh life in the wilderness again.
Automated cyclical evolution.
with the added bonus of explorability, because as time goes on, a single person choosing to spend their whole life exploring in a single direction would be able to stumble upon numerous abandoned mega-villages, rather than just tiny failed camps.
Perhaps that person could make it back to living villages as an old person and try to tell people about their discovery, and get people to migrate and reclaim the old cities.
If you have some really long term perishability on items, like baskets, seeds, and stone/wood tools and such (maybe 10,000 years? 50k ?), those abandoned mega cities would still require a lot of work to bring alive again, but it would be a somewhat different approach than just building a fresh city, since you might still have things like Walls and floors and roads and wells(dry?) and kilns and forges, etc.

Anyway, food for chewing

Dogamai · 2018-03-11 09:00:36

Actually maybe you are doing all of that already.... I just realized I really have no idea.

Dogamai · 2018-03-11 09:27:41

On a different note, as far as how many servers to have / how to spread populations, I think the most effective method is probably still the classic mmo method:

List all the servers, and their current populations and let players pick which servers to play on.

I would still keep in the Auto-server-select feature (make it a checkbox option during server select), but to improve on the boring old method, I would make this modification:

Allow players to select "Favorite Servers".

Give each player the ability to mark a couple servers with their priority. So they have say 4 favorites, they mark them #1 - #4 and when they respawn, if they have Auto-server-select option turned on, the spawn spread algorithm tries to place them with priority on their favorite servers, until those populations are too high.

So you get the best of both worlds. People can still chose to stay working on a specific server, or they can bounce around as they please ( pretty much already doing this with customServerAddress ) as easily as checking a box on the respawn screen.

and you wont have as many dead servers when overall game population declines eventually, since likely numerous people will have selected a low pop server as their favorite, most servers will still have a dedicated group justifying keeping it alive.

Of course inevitably some servers will die off, but you can let it happen more naturally.

ameliewilde · 2018-03-11 09:33:18

Dogamai wrote:

On a different note, as far as how many servers to have / how to spread populations, I think the most effective method is probably still the classic mmo method:
List all the servers, and their current populations and let players pick which servers to play on.
I would still keep in the Auto-server-select feature (make it a checkbox option during server select), but to improve on the boring old method, I would make this modification:
Allow players to select "Favorite Servers".
Give each player the ability to mark a couple servers with their priority. So they have say 4 favorites, they mark them #1 - #4 and when they respawn, if they have Auto-server-select option turned on, the spawn spread algorithm tries to place them with priority on their favorite servers, until those populations are too high.
So you get the best of both worlds. People can still chose to stay working on a specific server, or they can bounce around as they please ( pretty much already doing this with customServerAddress ) as easily as checking a box on the respawn screen.
and you wont have as many dead servers when overall game population declines eventually, since likely numerous people will have selected a low pop server as their favorite, most servers will still have a dedicated group justifying keeping it alive.
Of course inevitably some servers will die off, but you can let it happen more naturally.

We are already doing that, aren't we?

http://onehouronelife.com/reflector/ser … ion=report

"you can join the server by changing 2 files in the settings folder:

useCustomServer - change the 0 to a 1

customServerAddress - change localhost to server#.onehouronelife.com
# = the mainserver you want"

Dogamai · 2018-03-11 11:05:49

ameliewilde wrote:

We are already doing that, aren't we?

yeah thats what i said

Dogamai wrote:

can bounce around as they please ( pretty much already doing this with customServerAddress )

One Hour One Life Forums

#1 2017-07-06 07:17:20

Population questions

#2 2017-07-06 16:20:11

Re: Population questions

#3 2017-07-07 12:17:43

Re: Population questions

#4 2017-07-07 15:39:26

Re: Population questions

#5 2017-07-07 16:09:50

Re: Population questions

#6 2017-07-07 16:58:05

Re: Population questions

#7 2017-07-07 17:06:50

Re: Population questions

#8 2017-07-07 21:12:59

Re: Population questions

#9 2017-07-07 21:14:44

Re: Population questions

#10 2017-07-08 06:08:07

Re: Population questions

#11 2017-07-25 08:34:47

Re: Population questions

#12 2018-03-11 08:45:29

Re: Population questions

#13 2018-03-11 08:58:54

Re: Population questions

#14 2018-03-11 09:00:36

Re: Population questions

#15 2018-03-11 09:27:41

Re: Population questions

#16 2018-03-11 09:33:18

Re: Population questions

#17 2018-03-11 11:05:49

Re: Population questions

Board footer