When a game has 2servers up and full... Can the waiting list be available? Like when someone leave the game you could already join. ??? Because of the power of the waiting list :)
Well the BYOND Hub doesn't know when a server is "full." The game needs to specify that the server is full. This seems like an interesting feature to add - a new proc that lets the hub know that the server is allowing no more players. And then the feature you mentioned can be added.
#2 Dec 6 2008, 12:03 am (Edited on Dec 7 2008, 10:16 am)
world.max_players
Default: 0
Explanation: This defines a maximum player limit for BYOND games. If set to 0, this feature is disabled.
If there are too many players, new connections will be rejected and the server will be flagged as 'full' on the BYOND Hub, which may cause the waiting list feature to become available until a new server is hosted or one of the already hosted servers has a spot free.
Note that the latter functionality is only available on hub entries owned by BYOND Members.
----------
world.reserved_players
Default: null
Explanation: This is to be used together with world.max_players.
It is a list of keys and/or IPs which are exempt from the player limit. If there are 4 players online, and a player tries to login which is on the above list, that player will still be allowed entry.
Note that unless world.count_reserved is unset, the player will still be counted towards world.max_players.
----------
world.count_reserved
Default: 1 (TRUE)
Explanation: If this value is set, reserved players will still count towards the player limit despite their immunity.
This can be turned off to avoid players being unable to reconnect thanks to reserved players, and to avoid weird results on the hub in the form of "5/4 players online".
--------------------
Note that the above suggestion is ignored on reboots. By that I mean that if there is a reboot, and there are 5 players logged in (max_players = 4, 1 reserved player is logged in), all of the 4 other players can login just fine without one of them being disconnected due to the reserved player. However no more players can join unless they too are on the reserved list.
That'd work too, but it's less work for just world/full or similar to indicate to the hub, and let the game handle it, since then everything is customizable and up to you.
Tom and I have discussed something along these lines before. The trick is, as others have mentioned, figuring out how to tell if a server is actually full. Complicating this further, some servers are full only for regular folks while they keep some provisional slots open for subscribers or BYOND Members.
A related problem is that some servers are up, but not ready to play, like a game of Incursion with one person in it. It's helpful to be alerted when it's up, but it's even more helpful to know when multiple players are in it.
As you might imagine, this has caused a lot of back-and-forth discussion that's gotten us nowhere so far. Is there a way to set up a theoretical minimum number of players for a hub entry before people are alerted about it? If so, how do we get the entry to reach that minimum if no one is alerted? What about cases where the minimum varies depending on the game style? How does a game tell the hub it's full, and do we distinguish between "full for everyone" or "full for some users but not others", and if so how do we handle that on the hub entry page? Do we make the waiting list always available, and if so would we just exclude servers from the alerts that the user has already said they can't join for whatever reason? The issues involved are quite complex, but I welcome any input that could point to a solution.
Lummox JR
#5 Dec 6 2008, 9:37 am (Edited on Dec 6 2008, 10:13 am)
(...)Is there a way to set up a theoretical minimum number of players for a hub entry before people are alerted about it? If so, how do we get the entry to reach that minimum if no one is alerted? What about cases where the minimum varies depending on the game style? How does a game tell the hub it's full, and do we distinguish between "full for everyone" or "full for some users but not others", and if so how do we handle that on the hub entry page? Do we make the waiting list always available, and if so would we just exclude servers from the alerts that the user has already said they can't join for whatever reason? The issues involved are quite complex, but I welcome any input that could point to a solution.
How about a new feature/proc: trigger_queue(msg="[world.host] is hosting [world.name]")
Returns: 1 on success (or 0 on success and the amount of time till the next contingent is available in 1/10s of a second on failure)
The feature can only be used if the hub owner or the host has a BYOND membership. That way it would blend in well with the new incentive for advertising (screenshots) and adds another nice reason to support BYOND.
trigger_queue(msg) alerts everyone in the waiting list with a customizable message and thus places any of these concerns you raised in the hands of the developer to solve and carter for (allowing individual solutions fitted to each game).
A maximum of 3-6(?) messages can be sent within 30 minutes to avoid spamm (a simple counter on the hub for all games hosted under that hub, because there is only one waiting list).
That would only be a solution for new games, or games that still get updated though.
[Edit: The waiting list would stay as is, with just a change that it does not vanish as soon as a game is hosted, but instead stays visible.
"Older/abandoned" games could still use the waiting list, trigger a default "[world.host] is hosting [world.name]" on the first server to appear (like now), but due to the persistent waiting list people would have the chance to manually see and communicate with others willing to play)]
#6 Dec 7 2008, 6:00 am (Edited on Dec 7 2008, 10:16 am)
Is there a way to set up a theoretical minimum number of players for a hub entry before people are alerted about it?
A world.min_players variable which can be set to the minimum amount of players required for other players to be alerted. This is 0 by default, but for games like Incursion this can be set to '1' and it will stop sending out alerts to players from servers with no players on it.
If so, how do we get the entry to reach that minimum if no one is alerted?
In the event that more than one person is on the list, send an alert out to both players when a server goes up that they are now able to play (assuming that the minimum amount necessary joins).
What about cases where the minimum varies depending on the game style?
Allow runtime modification of the world.min_players variable, and update the server record accordingly.
How does a game tell the hub it's full, and do we distinguish between "full for everyone" or "full for some users but not others", and if so how do we handle that on the hub entry page?
Instead of the world.max_players crap I came up with, skip to the better idea by Schnitzel: make a proc such as world/IsFull() which can return 1 or 0 based on if the game is full or not. This is for the actual connection process.
For the hub to be made aware of this, more will have to be done. A world/GameState() proc with a different name (since I don't have a proper name for it right now) could be used to determine the former question. A value of 0 indicates that the server is full, a positive value indicates how many slots are available and a negative value indicates how many slots are available and tells the hub that the server is reserved.
Note that the GameState() function by default returns the magic number '65536'. This number indicates that there is no limit on the amount of players at all. A value of -65536 would say the same, but the game would be unavailable to play for most people (good for alpha testing).
GameState() should not be able to output anything below or above -65536 and 65536. Anything above or below these values should act the same as the above paragraph states.
Furthermore, DreamDaemon should override the GameState() proc with it's friends list: if the friends list is used and GameState() returns a positive value, it will secretly convert it to a negative one.
On the hub entry a small blurb of text can be put on every server indicating if the game is full or not, and if not, how many players are still allowed in. If a negative value was outputted, the server should indicate that it is "restricted".
Do we make the waiting list always available, and if so would we just exclude servers from the alerts that the user has already said they can't join for whatever reason?
The waiting list should be available if:
* no servers are currently running;
* the servers that are running are running in 'restricted mode' or are full;
If a player is on the waiting list and a server pops up which is in 'restricted mode', it should automatically try to connect to the server silently (though perhaps allow an option to turn this off in the Preferences window of the Pager) and call the world/IsFull() proc with their key and IP. If this value returns 0, the player should receive an alert. Otherwise, the pager should be silent.
Is there a way to set up a theoretical minimum number of players for a hub entry before people are alerted about it?
A world.min_players variable which can be set to the minimum amount of players required for other players to be alerted. This is 0 by default, but for games like Incursion this can be set to '1' and it will stop sending out alerts to players from servers with no players on it.
If so, how do we get the entry to reach that minimum if no one is alerted?
In the event that more than one person is on the list, send an alert out to both players when a server goes up that they are now able to play (assuming that the minimum amount necessary joins).
Those answers really contradict each other, which is kind of an inherent problem with figuring out anything along these lines. There are plenty of cases where it makes no sense to alert someone to join a game they can't start, yet if you don't alert them no one will join the server to play the game.
What about cases where the minimum varies depending on the game style?
Allow runtime modification of the world.min_players variable, and update the server record accordingly.
How does a game tell the hub it's full, and do we distinguish between "full for everyone" or "full for some users but not others", and if so how do we handle that on the hub entry page?
Instead of the world.max_players crap I came up with, skip to the better idea by Schnitzel: make a proc such as world/IsFull() which can return 1 or 0 based on if the game is full or not. This is for the actual connection process.
A proc wouldn't work for this; it would need to be a variable so that the hub could be contacted when it changes.
For the hub to be made aware of this, more will have to be done. A world/GameState() proc with a different name (since I don't have a proper name for it right now) could be used to determine the former question. A value of 0 indicates that the server is full, a positive value indicates how many slots are available and a negative value indicates how many slots are available and tells the hub that the server is reserved.
Your idea for the negative numbers sounds awfully specific to only certain kinds of games and "fullness" models, so for that reason it wouldn't make a good basis for hub integration. But again, whatever is done can't be a proc because the idea is to contact the hub about changes in status, not have the hub constantly poll the server with questions about its status.
Furthermore, DreamDaemon should override the GameState() proc with it's friends list: if the friends list is used and GameState() returns a positive value, it will secretly convert it to a negative one.
I can't imagine any case where that would fail to confuse the crap out of people, but again, this whole negative value idea is kind of a dog.
On the hub entry a small blurb of text can be put on every server indicating if the game is full or not, and if not, how many players are still allowed in. If a negative value was outputted, the server should indicate that it is "restricted".
I wouldn't mind adding text for this kind of thing, though probably just using world.status for it is just as good.
The waiting list should be available if:
* no servers are currently running;
* the servers that are running are running in 'restricted mode' or are full;
Bonus question: What if the user is banned from the servers that are running?
If a player is on the waiting list and a server pops up which is in 'restricted mode', it should automatically try to connect to the server silently (though perhaps allow an option to turn this off in the Preferences window of the Pager) and call the world/IsFull() proc with their key and IP. If this value returns 0, the player should receive an alert. Otherwise, the pager should be silent.
Can't be done as a proc. Must be a var. The hub does not contact the server--it's always the other way around. Therefore it is impossible to tell whether a given user will be allowed to join past a ban until after they try; also not all of the info considered in a ban is available to the website.
As for servers hosted for friends/guilds only, that info at least is available, but pulling that info per user has proved to be a bit of a strain on the db in the past and it's not a road I'd be especially quick to go down.
There are plenty of cases where it makes no sense to alert someone to join a game they can't start, yet if you don't alert them no one will join the server to play the game.
What about having two different types of messages:
"[host] is trying to set up a game of [game]!" for when there aren't enough players to begin the game, and "[world.host] is hosting [world.name]!" when the minimum number of players is met?
Also, instead of all these seperate variables, what about a simple flag? Then have the game world decide which state it is in:
world.population WAITING_POPULATION 0 - The server is waiting for more players to join before starting the game RUNNING_POPULATION 1 - There are enough players and the game is in progress RESERVED_POPULATION 2 - The game is full, only certain players will be able to join FULL_POPULATION 3 - The game is completely full, no one will be allowed to join
Then leave it to the game to set world.population to the value that most accurately describes its state, and leave it to the game to reject new connections if full.
Of course, you would have to think of a better name than world.population ;)
Those answers really contradict each other, which is kind of an inherent problem with figuring out anything along these lines. There are plenty of cases where it makes no sense to alert someone to join a game they can't start, yet if you don't alert them no one will join the server to play the game.
In these cases a proc is really the only way to do this, where the proc dictates if one of the players is able to start a game or not.
A proc wouldn't work for this; it would need to be a variable so that the hub could be contacted when it changes.
The IsFull() proc would work because it would not be the hub contacting the server, but the client. The client would contact the server and would alert the player if the server accepts them in.
The GameState() proc would have to go away in this case, then. A whole series of variables would have to be created just to accommodate this: world.max_players, world.min_players, world.allowed_players, world.banned_players... a new datum would probably be best for this.
Your idea for the negative numbers sounds awfully specific to only certain kinds of games and "fullness" models, so for that reason it wouldn't make a good basis for hub integration. But again, whatever is done can't be a proc because the idea is to contact the hub about changes in status, not have the hub constantly poll the server with questions about its status.
Bonus question: What if the user is banned from the servers that are running?
The IsFull() proc would handle this.
Unfortunately, the client would ultimately have to poll the server and initiate the call, so that the hub doesn't waste all that bandwidth.
I don't know this is doable, but could the BYONDStub be used (the browser mechanism currently installed into every BYOND client) to automatically have the client poll servers on hub entries they visit?
Basically, when a client visits the hub entry for Incursion, it would first get the list of servers from the hub as it does normally. The list is then outputted normally.
After the initial page has been loaded, the plugin loads, assuming it is available.
The plugin then contacts the individual servers and it calls their IsFull() proc with the clients' key and IP address, the former taken from the pager.
If IsFull() returns any value above 1, the player is able to join the server and the amount of players that can connect is visible on the hub entry near the world.status text. If it returns 0, the server is declared 'full' and if it's -1 then access has been denied (due to the client being banned from the server or not being on an invite-only list).
(Another train of thought I had was that if a string is sent, it is also rejected but instead of the default message the string is displayed in it's place.)
Since the waiting list feature can't be used without the pager anyway, I think this is a good alternative to letting the hub handle all of it. If you don't have the BYOND client installed, the hub entry is displayed as it is now -- but with a message indicating that features have been disabled since BYOND is not installed or an outdated version is being used.
In order to prevent spam, a server may specify a "timeout" of it's own in which the pager caches the result it gives. Additionally, a client-side timeout can also be specified, which defaults to 5 minutes for 'full' games and 15 minutes for 'available' games.
This could work in the event that the 'BYONDstub' is not available to the player. It would fall back on this routine, but it would not be as reliable since it does not check on a per-client basis.
Those answers really contradict each other, which is kind of an inherent problem with figuring out anything along these lines. There are plenty of cases where it makes no sense to alert someone to join a game they can't start, yet if you don't alert them no one will join the server to play the game.
In these cases a proc is really the only way to do this, where the proc dictates if one of the players is able to start a game or not.
A proc wouldn't work for this; it would need to be a variable so that the hub could be contacted when it changes.
The IsFull() proc would work because it would not be the hub contacting the server, but the client. The client would contact the server and would alert the player if the server accepts them in.
That still doesn't make sense, because the hub never contacts the client. The only time the hub sends outgoing info is when it's sending updates to a pager, and that's only if the pager is capable of receiving them. Otherwise all communication goes out to the hub. This gets around a lot of problems with port forwarding and such.
I don't know this is doable, but could the BYONDStub be used (the browser mechanism currently installed into every BYOND client) to automatically have the client poll servers on hub entries they visit?
The stub plugin would have to be upgraded to do anything but just sit there, but the kind of polling you'd be asking it to do is something it'd be very difficult for BYOND to support. So this IsFull() idea just has no chance of working.
Since the waiting list feature can't be used without the pager anyway, I think this is a good alternative to letting the hub handle all of it. If you don't have the BYOND client installed, the hub entry is displayed as it is now -- but with a message indicating that features have been disabled since BYOND is not installed or an outdated version is being used.
The waiting list feature can be used on the website as well as the pager.
Lummox JR
#12 Dec 7 2008, 11:53 pm (Edited on Dec 8 2008, 12:00 am)
Tom and I have discussed something along these lines before. The trick is, as others have mentioned, figuring out how to tell if a server is actually full.
Why? Let the makers determine that. You guys make enough decisions for us developers. :P
Complicating this further, some servers are full only for regular folks while they keep some provisional slots open for subscribers or BYOND Members.
That's a pro, not a con. The server isn't full if any slots are open, member-only or not. If the player isn't able to access the game, that's another reason for them to get membership/subscribe.
A related problem is that some servers are up, but not ready to play, like a game of Incursion with one person in it. It's helpful to be alerted when it's up, but it's even more helpful to know when multiple players are in it.
That's Incursions' problem, though. Most games outside of strategy don't need multiple players to be playable. And then, how do you expect to get those players if you're not telling them the game is up? :P
As you might imagine, this has caused a lot of back-and-forth discussion that's gotten us nowhere so far.
Yes, I can imagine. Perhaps you should not try to cover all the bases with every feature, especially if you're going to be "guessing" what the developer intended. Please stop that.
Is there a way to set up a theoretical minimum number of players for a hub entry before people are alerted about it?
Irrelevant. You should be alerted when the world goes live, and when it is no longer playable. When the game advertises its live status is up to the developer, so they can defer it to when the game begins if they so choose. No need for you to alert everyone twice.
If so, how do we get the entry to reach that minimum if no one is alerted?
What about cases where the minimum varies depending on the game style?
Exactly. These sorts of questions should make it pretty clear that this isn't your domain. Give us a world.state variable that'll alert when set to some value, and we'll work it out, trust us.
How does a game tell the hub it's full, and do we distinguish between "full for everyone" or "full for some users but not others", and if so how do we handle that on the hub entry page?
var/list/players var/my_max = 25
client New() ..() if(!players) players = new players += src if(players.len >= my_max) world.state = FULL
Do we make the waiting list always available, and if so would we just exclude servers from the alerts that the user has already said they can't join for whatever reason?
Alerts from each server should be taken as a hub-wide alert. Any server, no matter if the individual player can join it or not, that states it should send an alert, should alert all people waiting for said alerts, irregardless of the game/player relationship between each server/client. You can't track everything sanely.
The issues involved are quite complex, but I welcome any input that could point to a solution.
I think you're making it more complex than it needs to be.
(...)You guys make enough decisions for us developers. :P
That is indeed a tricky statement, considering the fact that BYOND is after all an authoring tool and as such has to imply restrictions in order to provide an easy to use developer interface.
These thoughts have to be considered while improving BYOND.
Xooxer wrote:
(...) Most games outside of strategy don't need multiple players to be playable. And then, how do you expect to get those players if you're not telling them the game is up? :P
Actually, if the game does not need multiple payers to be playable, what would be the use for a waiting list?
The sole purpose of such a list is to ease the process of finding others in order to enjoy the multiplayer aspect of a game, or am I wrong?
Xooxer wrote:
Irrelevant. You should be alerted when the world goes live, and when it is no longer playable. When the game advertises its live status is up to the developer, so they can defer it to when the game begins if they so choose. No need for you to alert everyone twice.
Am I misunderstanding you here, or isn't this exactly how it is done right now?
In which case I would say, if this is a perfect solution, why are people complaining?
Xooxer wrote:
(...) Give us a world.state variable that'll alert when set to some value(...).
I however agree with you on this point.
When the developer can set an alert, it is best adjusted to the games specific needs.
Xooxer wrote:
(...)Any server, no matter if the individual player can join it or not, that states it should send an alert, should alert all people waiting for said alerts(...). You can't track everything sanely.
I would suggest one exception though.
Since the hub determines if players can join, games that obviously can't be joined shouldn't send alerts.
That should be a simple boolean condition to check and yet save the average casual player from being alerted by servers noone can join.
Alathon wrote:
I agree. In essence, a game is either accepting players or it isn't.
If it would be this simple, you wouldn't need a waiting list, would you?
(...) Most games outside of strategy don't need multiple players to be playable. And then, how do you expect to get those players if you're not telling them the game is up? :P
Actually, if the game does not need multiple payers to be playable, what would be the use for a waiting list?
The sole purpose of such a list is to ease the process of finding others in order to enjoy the multiplayer aspect of a game, or am I wrong?
You're mostly right on that, although I'd say the secondary purpose (and the one most easily detected when it was first enacted) was to show potential hosts that there was immediate interest in starting a game. To me, both of those are good reasons to have a waiting list available.
One idea that has been emerging on this thread is the concept of a world state var that keeps track of whether a game needs more players, is in progress but is accepting new people, is full, or may be full (the latter being cases where the game is considered full but slots are made available for Members or subscribers). I kinda like that, since it takes all of the design foo off our hands and puts it in the hands of the developer. With that, we'd need some way to allow the waiting list to function without still sending users alerts for servers they know are unavailable, so we'd need some kind of temporary "exclude these servers" list. All doable. When we revisit this feature it'll be worth looking into these kinds of options as ideas for improving things.
That is indeed a tricky statement, considering the fact that BYOND is after all an authoring tool and as such has to imply restrictions in order to provide an easy to use developer interface.
There's a difference between restrictions, and actually doing this to undermine your game while it's running. The feature that called ll the commands for buttons before a client was fully connected was just one example.
These thoughts have to be considered while improving BYOND.
Yes. While improving BYOND, not while my program is running. You know what I mean.
Xooxer wrote:
Actually, if the game does not need multiple payers to be playable, what would be the use for a waiting list?
Um.... it's for the people waiting to play the game? Really, did you just ask that question?
If a multiplayer game requires 2 or more people to play (ie: Incursion), then how does that negate a waiting list? o.0
The sole purpose of such a list is to ease the process of finding others in order to enjoy the multiplayer aspect of a game, or am I wrong?
I don't know, maybe you aren't. I thought they were for the people waiting to play a game, not waiting to play with you. Last I checked, you're name doesn't have a waiting list.
Am I misunderstanding you here, or isn't this exactly how it is done right now?
I think you are.
In which case I would say, if this is a perfect solution, why are people complaining?
See, the thing is, nobody is. It's a feature request to extend the functionality of the waiting list to alert people when a game is playable due to *whatever* factors the developer thinks should be applied. It started as a "Can we have an alert when a server is no longer full", and grew into list of situations the *developer* should concern themselves with, not BYOND, in dertiniming if the game is playable or not.
I however agree with you on this point.
When the developer can set an alert, it is best adjusted to the games specific needs.
Exactly.
Xooxer wrote:
(...)Any server, no matter if the individual player can join it or not, that states it should send an alert, should alert all people waiting for said alerts(...). You can't track everything sanely.
I would suggest one exception though.
Since the hub determines if players can join, games that obviously can't be joined shouldn't send alerts.
That should be a simple boolean condition to check and yet save the average casual player from being alerted by servers noone can join.
If no one can join, nobody is going to be waiting to play for very long. And how would the hub know if you can or can't join the sever?
Alathon wrote:
I agree. In essence, a game is either accepting players or it isn't.
If it would be this simple, you wouldn't need a waiting list, would you?
You're mostly right on that, although I'd say the secondary purpose (and the one most easily detected when it was first enacted) was to show potential hosts that there was immediate interest in starting a game. To me, both of those are good reasons to have a waiting list available.
I had to think about this, so please excuse the late reply.
However I came to the conclusion that a dedicated host is most likely going to host regardless of a waiting list, whereas a temporary one would likely host because she wants to play and spots others to play with, resulting in the same search for multiple players, just with an additional hosting.
The only reason I could see for a dedicated host to wait for a the list to fill with people before hosting is to generate interest and accumulate players because the game needs many of them to be fun.
So, wouldn't it boil down to one purpose with offspring?
Edit:
Xooxer wrote:
(...)
I think you misunderstood me, or I am misunderstanding you again, which is why I'll just step back, unless you want to discuss it on the pager, where I'd be more than happy to.
