|
Pages: [1] 2 3 4
|
 |
|
Author
|
Topic: Net Play - Lobby (Read 15132 times)
|
Amiga_Nut
*Many bubbles*
 Offline
Gender: 
Posts: 208
|
I know many people out there are willing and ready to play net matches… Of course that means we need to start some sort of list. Like
–LightwaveArtist_71.163.81.133 3:00pm-6:00pm EST
Perhaps the sys-admins could set something like this up? The “UQM Net Players List” 
Unless someone has a software solution in the works.
|
|
|
|
« Last Edit: July 26, 2007, 09:54:07 pm by Amiga_Nut »
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
The current solution is to look for likely opponents on #uqm-arena on the Freenode IRC network. A list of times is not going to be much help for people with irregular schedules.
|
|
|
|
|
Logged
|
|
|
|
Captain_Smith
Guest
|
I think that the current big issue really is not a meeting place more than finding times when people are actually awake and are there willing to play net-uqm.
|
|
|
|
|
Logged
|
|
|
|
Amiga_Nut
*Many bubbles*
Offline
Gender:
Posts: 208
|
So how about a software solution built in the game? Could a subroutine be written to detect ready players and manage connection? Anyone thinking about it?
Although I know what IRC is, I have never been on it before.  It all seems like too much trouble.
|
|
|
|
|
Logged
|
|
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
There are plans to implement some sort of multiplayer "lobby" or metaserver. This would probably consist of a server or set of servers to which players connect to get information on active players. From here, UQM would allow players to talk to each other and start games against each other.
This is mostly at the ideas stage right now, so a lot of things may change or simply not pan out. This also means that it's a good time to make suggestions.
|
|
|
|
|
Logged
|
|
|
|
|
|
Culture20
Enlightened
Offline
Posts: 917
Thraddash Flower Child
|
You'd still need a server for the IRC channel. Unless you're going to have a ultra-packet-spammy protocol (WINS, NetBeui, Appletalk, anyone? usually non-routable), you can't have a serverless auto-connection/detection technique. Even if you house your own server (in this case, running UQM on your machine), without a meta-server (same example, the irc daemon), no one would know where your server was...
|
|
|
|
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
Adding an IRC client to UQM would be unnecessarily complex, since IRC contains a lot of features that aren't relevant to UQM (e.g. DCC, multiple servers for a single channel, much of the administration and a bunch of minor features like MOTD), which would have to be supported even though they are not required by UQM. Integrating an existing IRC client is likely to be messy and non-portable (and not much easier on the devs); this is the reason for the current "bring your own IRC client" policy.
In contrast, a custom protocol can easily be extended to transmit custom information (e.g. fleet setup) relevant to UQM netplay, in order to make it easier to find opponents.
From a bandwidth point of view, it makes sense to transmit player-to-player communications (messages, gameplay) directly between players and use the server only to find players and for global messages (administration, general chat). This should keep metaserver traffic quite low. Load balancing between multiple servers can also be built into the protocol, if needed.
From a security and legal perspective, a simple and specialised metaserver is likely to be less of a problem than e.g. a public web-based discussion forum; the UQM metaserver does not need to retain non-admin messages at all nor accept large amounts of traffic; this makes copyright violation difficult and abusive messages should disappear quickly (unless archived by the client, of course). Similarly, it is usually easier to ensure the security of a simple system than a complex one. This makes the UQM metaserver quite resilient against most threats on the Net.
Based on the above, running a UQM metaserver on the server providing this forum does not seem unrealistic, although load considerations may make a seperate machine advisable.
|
|
|
|
|
Logged
|
|
|
|
|
|
youBastrd
Frungy champion
Offline
Gender:
Posts: 67
It's real velour, just let yourself go.
|
So I've been tossing around ideas about how to code a reasonably good "master server" + client code for publishing and finding UQM net games. Here are the notes so far:
Right. So what's the required feature set?
Assumptions (please correct if any are wrong!):
* UQM's netplay uses a peer-to-peer model with two peers, rather than a client-server model. Thus player A needs to know B's IP and port, and B needs to know player A's IP and port.
* Moreover, currently A needs to be waiting for B to connect, and B needs to be waiting for A to connect. (is this correct?)
** This is kinda strange. A suggestion is to have A wait for a connection, then when B connects, we're done. A and B talk via the same port, at this point they know each other's IP address. If for some reason A needs to know B's port, it can be the first item sent. This means only A needs to have it's port open for incoming connections: usually firewalls can talk freely once an outbound connection has been made. (is this correct?)
* Also there's currently a bit of quirkiness in that you have to determine who is the top player and who is the bottom player (is this correct?). I recommend that in the future this gets phased out in some way. Since it's peer-to-peer though, there has to be some way to distinguish between player slots. My first instinct is for one side to just force the issue:
* There is currently no way to host a game server where you are not playing but others can join (ie a "dedicated server" so two other players can play; is this correct?).
* I'm also assuming here that even though you must currently specify all these details on the command line, in the future it will be possible to change these parameters at run-time, and they will change many times in one program run to play complete games on different servers.
* An integrated solution for finding games online would be cleaner than using some outside tool to launch the game via commandline parameters. For example, GameSpy had such a tool. Writing (or using) an outside tool could work as an intermediate measure. From my experience, temporary solutions end up being permanent more often than not. Google "lazy as a virture." 
* This solution requires the creation of master server software. This also requires a dedicated server box set up someplace. If money's an issue, I recommend a "Slug" running on someone's dedicated home, business or school network and using a free dns service. Or paying for an actual DNS entry. Note that sourceforge, berlios etc are not candidates for running such a server.
* This solution should not require any other external software or service. As in, you don't need a seperate ping daemon / web server / etc running.
Required:
* (REQ 1000) Players can start a game server to host a game with themselves as a player.
** Starting such a game server advertises its availabilty to a master server.
** By virtue of sending this message the sender's external IP address is revealed
** The sender may also have to specify which port to use.
** This request also specifies which player positions are in use and which are available.
** For future use, "max players" might be better than available player positions.
** For future use, we might specify the "map", "gametype", existing players in the game (enumerated by their names). Console games typically have a "matchmaking service" whereby they don't show a list of servers in the UI; instead it picks a server that matches the player's chosen criteria. Here is where such clues are given.
** This master server may also return some info from the request.
*** For example, a generated unique public game server ID. This is useful for distinguishing between multiple servers behind the same network, using the same external IP and port. May also be used for updating the server's stats.
* (REQ 1001) Players can get a list of available game servers by querying the master server.
** Players can send in a request to the master server. For now, it doesn't look like there's much to specify in this outbound request. The master server doesn't really care about the player's IP, port, player position etc.
** Should Filters be done on the requester's end or the master server's end? So if the player specified in a UI someplace that they do not want to hear about full servers or something, do we make that part of this outbound request (at the expense of the master server's CPU time) or do we do that on the
** The return from this request is a list of servers. For each, we have:
*** Public IP and port
*** Number of players currently in the game
*** Number of available slots, and for each, their "position." This position should be phased out at some point.
** Curiously, the server's ping is *not* returned here. The master server has no idea about the ping time between anything; instead it's up to the player's software to ping the game servers.
* (REQ 1002) Game servers can update their stats on the master server.
** Same as REQ 1000. The main reason this exists is to prevent the server from reporting multiple instances of the same server (by using that unique server ID).
* (REQ 1003) Ping from one game server to another.
** Useful for weeding out bad game candidates. Presumably the UI can sort a game list by ascending ping time.
** This should be done by UQM code.
* (REQ 1004) UI update for finding online games.
** Think Quake 3's browser list. You can sort and filter results.
* (REQ 1005) UI update for creating / hosting an online game.
** Presently there's not much to adjust: your port is about it.
** For future expansion, this should be made a seperate UI page. There may be things like choosing maps, gametypes, specifying max players, etc.
Sounds Great! Now what technology is appropriate here?
Raknet. This is a network library, which includes among other features, a fairly quick and easy way of implementing a master server and client code.
This lib used to be available as GPL code; now it's an "Attribution-NonCommercial 2.5" creative commons license. This is GPL-compatible, but it adds the additional restriction that the resulting binaries must be non-commercial. Now it might just be possible to work something out with the author such that we pay for the commercial license, but we still end up with a GPL-compatible license... I dunno.. this kinda licensing makes my head spin. Or maybe it was the Sambuka.
Anyhow: great tech, but licensing will have to get sorted out.
Use SOAP calls. Simply put all the stuff talked about above into neat XSD-formatted SOAP requests, use some GPL-compatible lib to generate your code from the XSDs, and Bob's your uncle. Or Toy.
This is actually a fairly clean solution. It means adding a build target to generate this code, plus adding the XML parser libs etc, but once that's out of the way this is really cheap maintenance, even if we add crazy features like easy matchmaking services like XBox etc have. I was actually going to try doing this using a Java client front-end that just calls the commandline + a Java server, just because it happens to be familiar.
Note that we are *not* going to hand-roll our own XML parsers etc. *sigh* many a programmer has gotten overzealous and coded such solutions, only to pull out their hair when the spec changes...
Hand-roll our own code. Nope, not a good idea. Aside from the idea of which slots are available and the fact that the two players must know each other's IP addresses, this is definitely not a unique problem. Someone's bound to have code for this, and this is what open source is for!
Go find someone else's code that already does something similar and use it. Someone want to spend a few minutes doing a google "site:sourceforge.net ..." so see if there's something already out there? There has to be an open source "gamespy" equivalent.
Ok, so are those assumptions even slightly right? Is this the required feature set?
|
|
|
|
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
* UQM's netplay uses a peer-to-peer model with two peers, rather than a client-server model. Thus player A needs to know B's IP and port, and B needs to know player A's IP and port.
Not entirely true. Hosting player works as a server and gets opponent's IP and port from the incoming TCP connection.
* Moreover, currently A needs to be waiting for B to connect, and B needs to be waiting for A to connect. (is this correct?)
No. See above.
** This is kinda strange. A suggestion is to have A wait for a connection, then when B connects, we're done. A and B talk via the same port, at this point they know each other's IP address. If for some reason A needs to know B's port, it can be the first item sent. This means only A needs to have it's port open for incoming connections: usually firewalls can talk freely once an outbound connection has been made. (is this correct?)
This is essentially how it works, except TCP keeps track of the client's IP address and port on the server, so UQM doesn't need to know that.
* Also there's currently a bit of quirkiness in that you have to determine who is the top player and who is the bottom player (is this correct?). I recommend that in the future this gets phased out in some way. Since it's peer-to-peer though, there has to be some way to distinguish between player slots.
Right now the game works fine irrespective of who's top and who's bottom; the top player on one machine can be bottom on the other and vice versa with no ill effects.
My first instinct is for one side to just force the issue:
* There is currently no way to host a game server where you are not playing but others can join (ie a "dedicated server" so two other players can play; is this correct?).
I haven't tested this recently, but it should be possible.
* I'm also assuming here that even though you must currently specify all these details on the command line, in the future it will be possible to change these parameters at run-time, and they will change many times in one program run to play complete games on different servers.
Hello? UQM already has full in-game netplay configuration as you describe. What version are you using?
* An integrated solution for finding games online would be cleaner than using some outside tool to launch the game via commandline parameters. For example, GameSpy had such a tool. Writing (or using) an outside tool could work as an intermediate measure. From my experience, temporary solutions end up being permanent more often than not. Google "lazy as a virture." * This solution requires the creation of master server software. This also requires a dedicated server box set up someplace. If money's an issue, I recommend a " Slug" running on someone's dedicated home, business or school network and using a free dns service. Or paying for an actual DNS entry. Note that sourceforge, berlios etc are not candidates for running such a server. * This solution should not require any other external software or service. As in, you don't need a seperate ping daemon / web server / etc running.
Required:
* (REQ 1000) Players can start a game server to host a game with themselves as a player.
** Starting such a game server advertises its availabilty to a master server.
** By virtue of sending this message the sender's external IP address is revealed
** The sender may also have to specify which port to use.
This matches my conceptions so far.
** This request also specifies which player positions are in use and which are available.
This makes sense.
** For future use, "max players" might be better than available player positions.
** For future use, we might specify the "map", "gametype", existing players in the game (enumerated by their names). Console games typically have a "matchmaking service" whereby they don't show a list of servers in the UI; instead it picks a server that matches the player's chosen criteria. Here is where such clues are given.
I don't think designing options for possible future use is a good idea. Better to either force everyone to use the latest version (easy but annoying; current design) or make the protocol backwards compatible so that unrecognised messages can be ignored (trickier).
** This master server may also return some info from the request.
*** For example, a generated unique public game server ID. This is useful for distinguishing between multiple servers behind the same network, using the same external IP and port. May also be used for updating the server's stats.
While having multiple servers on the same port would be possible (as long as their clients use different IP addresses and/or ports), making this work properly would require some major changes to how UQM handles network games. There is no particular reason to do this, either, apart from trying to circumvent firewalls.
* (REQ 1001) Players can get a list of available game servers by querying the master server.
** Players can send in a request to the master server. For now, it doesn't look like there's much to specify in this outbound request. The master server doesn't really care about the player's IP, port, player position etc.
Of course it cares. How can it sends lists of these to people otherwise?
** Should Filters be done on the requester's end or the master server's end? So if the player specified in a UI someplace that they do not want to hear about full servers or something, do we make that part of this outbound request (at the expense of the master server's CPU time) or do we do that on the
For large data sets, filtering on the server is going to be a lot faster than transmitting everything, from a CPU and especially a bandwidth point of view.
** The return from this request is a list of servers. For each, we have:
*** Public IP and port
*** Number of players currently in the game
*** Number of available slots, and for each, their "position." This position should be phased out at some point.
** Curiously, the server's ping is *not* returned here. The master server has no idea about the ping time between anything; instead it's up to the player's software to ping the game servers.
While it's kind of pointless to calculate ping from the metaserver to the players, I'm a bit concerned about generating an amount of pings proportional to the square of the amount of players. Based on the behaviour of similar software like BitTorrent, contacting 100 servers should be OK.
Also, instead of using ICMP ping, it would be a good idea to connect to the server and then measure round-trip time for a message through this connection.
Furthermore, I think it would be a good idea for the metaserver to track stuff like names of each server or defined fleet.
* (REQ 1002) Game servers can update their stats on the master server.
** Same as REQ 1000. The main reason this exists is to prevent the server from reporting multiple instances of the same server (by using that unique server ID).
Is this necessary? I'd just leave a TCP connection open between the server and metaserver; when it's gone, the server is gone.
* (REQ 1003) Ping from one game server to another.
** Useful for weeding out bad game candidates. Presumably the UI can sort a game list by ascending ping time.
** This should be done by UQM code.
See my comments above.
* (REQ 1004) UI update for finding online games.
** Think Quake 3's browser list. You can sort and filter results.
Sounds good, but what do we want to filter and sort on? Fleet size/points and "ping" spring to mind. Searching for a specific player/fleet name sounds useful, too. Anything else?
* (REQ 1005) UI update for creating / hosting an online game.
** Presently there's not much to adjust: your port is about it.
** For future expansion, this should be made a seperate UI page. There may be things like choosing maps, gametypes, specifying max players, etc.
Already done, more or less. Again, the "future expansion" part makes little sense in the context of UQM (although some minor rule changes have been discussed).
Sounds Great! Now what technology is appropriate here?Raknet. This is a network library, which includes among other features, a fairly quick and easy way of implementing a master server and client code. This lib used to be available as GPL code; now it's an "Attribution-NonCommercial 2.5" creative commons license. This is GPL-compatible, but it adds the additional restriction that the resulting binaries must be non-commercial. Now it might just be possible to work something out with the author such that we pay for the commercial license, but we still end up with a GPL-compatible license... I dunno.. this kinda licensing makes my head spin. Or maybe it was the Sambuka. Anyhow: great tech, but licensing will have to get sorted out. Looks to me like a bunch of wrappers and frameworks that don't really do anything for a lot of stuff that we mostly don't need (although the connection security bit sounds impressive, assuming it works). The way UQM's designed, most of the useful stuff that RakNet does (object replication, remote function calls, compression, routing, et.c.) is simply not relevant. Adapting something like this is not necessarily easier than rolling your own code.
Use SOAP calls. Simply put all the stuff talked about above into neat XSD-formatted SOAP requests, use some GPL-compatible lib to generate your code from the XSDs, and Bob's your uncle. Or Toy.
This is actually a fairly clean solution. It means adding a build target to generate this code, plus adding the XML parser libs etc, but once that's out of the way this is really cheap maintenance, even if we add crazy features like easy matchmaking services like XBox etc have. I was actually going to try doing this using a Java client front-end that just calls the commandline + a Java server, just because it happens to be familiar.
Note that we are *not* going to hand-roll our own XML parsers etc. *sigh* many a programmer has gotten overzealous and coded such solutions, only to pull out their hair when the spec changes...
Considering that we have little reason to attempt to integrate with anything else that uses SOAP, I'd classify this as a no-go; you're just adding complexity to the communications protocol for no good reason.
Hand-roll our own code. Nope, not a good idea. Aside from the idea of which slots are available and the fact that the two players must know each other's IP addresses, this is definitely not a unique problem. Someone's bound to have code for this, and this is what open source is for! True, but is this problem so complex on the inside and simple on the outside that we can easily reuse someone else's code written for similar, but not the same, requirements? I doubt it.
Most of this stuff is pretty simple to implement, really. It's designing it that's the hard part; once you have an unambiguous and sufficiently detailed specification I don't think it'll take many days to get the whole thing running.
Go find someone else's code that already does something similar and use it. Someone want to spend a few minutes doing a google "site:sourceforge.net ..." so see if there's something already out there? There has to be an open source "gamespy" equivalent. Checking that someone else's solution does what you need and adapting it to fit your needs can easily be time-consuming. Finding it in the first place is also kind of hard. There are tons of open source games that have code to co-ordinate multiplayer games, but they all have different requirements and thus do different things.
|
|
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
Before I respond to your remarks, I first want to say that I'm a bit irritated that you go ask questions without doing your home work first. Had you started just a single net game in the released version of UQM, you would have known that top/bottom position does not matter, that one side awaits a connection while the other side tries to connect to it, and that the network parameters can be set from inside the game.
You seem to be guided in your design by the possibility of having fights involving more than 2 players. This is something which is not likely to happen. But if it woud happen at some point, the amount of work that would be "wasted" by not supporting it from the beginning would be small compared to the work needed to be done to support more than 2 players.
And doing things incrementally would hugely increase the chances of anything getting completed at all.
So let's throw out the server-client design for now. What's left for the "meta"-server (you can leave out the "meta", as there wouldn't be any other level servers anymore) is to pair up players.
What I am thinking of, to start with, is a simple list of players, and a list of "challenges". A player could challenge another player, or do an "open" challenge, to which anyone can respond. Some info about the type of challenge ("100 points no doubles") would be included. Some chat ability would be nice too.
Then it's up to the two players themselves to configure their game. A post-connect, pre-fleet-setup game configuration would come in handy there.
More to follow later, I've got to go now.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
JonoPorter
Enlightened
Offline
Gender:
Posts: 656
Don't mess with the US.
|
If you want to look at GPL code that already has a lobby, chat and such you can take a look at TA-Spring for ideas.
|
|
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
 |
Re: Net Play
« Reply #14 on: January 09, 2007, 12:17:25 am » |
|
Continuing my note from earlier.
The pre-game configuration and the lobby would be two separate issues, which can be implemented individually.
One approach to doing the lobby is to have it done almost entirely web-based. Finding an opponent and even negotiating the game type can would be done in the browser. When the players are ready to start the game, the necessary information is sent to the player's UQM program. This could either be done through a minimal webserver built into UQM (using existing libs), or (less portably) by registering an "uqm://" url with the desktop environment. For an example of this method, you can look at The Bub's Brothers (or "Bub-n-Bros" or "Bub & Bob Brothers" depending where on the site you are looking).
This method has a number of big advantages:
- The web part would have no dependance on UQM code. This means that whoever implements it does not have to know anything about the UQM code, and can implement this in any language he/she chooses, which in turn means that there might be more people interested in creating this, and I could spend my time on other things (like the long-expected resource system).
- It's very easy to make the gui, as it would be done entirely using standard web languages.
Disadvantages:
- When something on the server end changes (e.g. someone says something in the chat) it would have to be reported back to the clients, which is tricky using javascript. The easiest solution would probably be to have the client continuously polling for changes. But it should be noted that I am no expert in web development.
- You would be doing your setup in an external program (your browser). This is not very slick. And it would complicate things for those who want to have netmelee support on mobiles.
Hosting the server would not be a problem. uqm.stack.nl can handle it.
Determining the network latency between clients should not be a problem as long as we have few players. If it ever gets really big we can split up the players into "rooms".
When there is a lobby, you don't want to pick your opponent from a list of network names, so there would have to be player names. You could use any available name at any time, but it should also be possible to register a name so that others can't misrepresent you.
If there are additional options introduced that affect the gameplay, you can retain backwards compatibility by -- instead of checking for the opponent's version -- having UQM reject any option it doesn't recognise (like telnet options, for those to whom that means anything).
There would still be required UQM updates, but at least their number could be minimised this way.
I agree with Novus that sometimes reinventing the wheel can be the easiest solution, but it may not be necessary, and it isn't an all-or-nothing thing.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
|
Pages: [1] 2 3 4
|
|
|
|
|
