|
Pages: 1 2 [3] 4
|
 |
|
Author
|
Topic: Net Play - Lobby (Read 15167 times)
|
Novus
Enlightened
 Offline
Gender: 
Posts: 1938
Fot or not?
|
I already had the start of a protocol written down; perhaps you're interested in seeing it.
Comparing notes would be a very good idea.
As for the "where does my part end?", for a start, the lobby could be a separate program which starts UQM. Then you wouldn't have to touch the UQM code at all (if you want), and we'll add a few command-like options to start the game in Netplay mode. And as I mentioned before, that "separate program" could just be something which communicates between the game and a web server, so that the entire lobby could be done in the browser. (It doesn't have to work like this; this is just one relatively easy way).
I distinctly dislike half measures, and would prefer to construct something with a practical user interface that doesn't compromise the portability of UQM or add unnecessary dependencies. I'm not too familiar with the widget set in UQM, but I believe that, as long as the user interface is kept simple enough, it should be a satisfactory approach.
This is also why I'm eliciting discussion about the user interface here.
As for Java, it would not have been my first choice, but if you're making the lobby, it will be your choice. I'm sure we can install java on uqm.stack.nl.
Considering what I'm comfortable with, the options are (in descending order of preference):
- Java application (note that designing to allow compiling to native code with gcj is an option)
- C application (input validation and memory management is going to require a lot more care)
- PHP with a database backend (I prefer not to write long-running applications in languages with unclear memory management)
Using Java or C makes it easy to implement a protocol based directly on TCP; PHP would integrate nicely with HTTP. The former would minimise the client-end stuff (no need to rely for an HTTP client), the latter would make web integration easier to add.
What was your first choice, Meep-eep?
Using the forum login for authentication is an interesting idea, which I hadn't considered before. But in Open Source spirit, it should be possible for anyone to run a server, and then this method would suddenly be a lot less interesting.
It doesn't work well as a sole authentication mechanism, but it would have the advantage of avoiding confusion between members of the UQM community as seen on the forum and UQM players with the same name.
As for rooms; star/planet names might be a nice default for room names, but it would be better to make them user-definable. If you have a contest, a room named "Kohr-Ah Cup" beats "Beta Copernicus IV".
Obviously.
|
|
|
|
|
Logged
|
|
|
|
Cedric6014
Enlightened
Offline
Gender:
Posts: 701
|
If we have large amounts of users, splitting them up will become necessary, in which case dividing them up into channels or arenas or realms or planets or whatever becomes necessary (and the "planet" theme actually sounds kind of cool).
Wild idea: use the starmap to select a planet when creating a new arena.
I think my lobby system below might address your first point. The star map to select an arena sounds very funky
Novus, it sounds to me like you are the man. I have expanded out my initial ideas below:
The Basics
I envisaged the structure to look as follows:
PoNaF
Netplay website
Rules/FAQ
Stats/results archive
Hall of fame/Melee profiles
Lobby system
Lobby 1
Arena 1 (Beta Copernicus IV)
Arena 2 (Pluto)
Arena 3 (Beta Leporis II)
Arena 4 (Alpha Squidii VI)
...Arena 50
Lobby 2
Arena 1 (Gamma Ceti IA)
Arena 2 etc
Any more than one lobby would only be required if this became amazingly popular. Currently there’s a maximum of 5 games going on at once uqm-arena. I foresee one lobby managing up to around 50 battle arenas. So jumping up to multiple lobbies assumes a ten-fold increase in popularity. Not likely any time soon, but would be good to have capacity for this. Or it may be that initially this extra layer will be cumbersome and not required.
Hopefully the uqm-forum log-in can be used to get into NetPlay lobby. This would keep identities consistent. People already do this but it would be nice to validate it and have forum avatars for NetPlay.
Chat could take place inside lobbies OR arenas. Arenas would feature the host and guest combatants plus any spectators. I am quite excited about the possibility of having crowd atmosphere at melees. Not so fussed on voice chat as it may disturb the combatants. There’s no reason they have to look at the text chat window though.
Host combatants are responsible for establishing battle rules:
- Official/unofficial game (rated or not)
- Max points
- Max ships per type (dupes)
- Max time limit (is a timer possible?)
I would say that an official game must have no duplicates and between 150 and 225 points. Official game results would be recorded in the results archive.
The results archive would record the following:
- Players (winner/loser)
- Date
- Tournament/stage (if applicable)
- Margin of victory
- Fleets used/ships left
The above would generate some pretty interesting stats on players (How often does Galactus use an Orz?). Anyone think of any other things to include?
Okay, so it’s sounding like a pretty involved database already but I’m sure it’s doable. I’m happy to take responsibility for this part of it.
Tournaments
Okay, this is where it gets fanciful.
I want people to be able to create their own tournaments. Level one tournaments will be ones agreed by the community to be premier – created by a Lobby Administrator. Level two will be those casually created by users (can still contain official melees).
Once you’ve selected this you choose the following:
- Type
League: Select number of round robins (any more than one is unwieldy really). Select number that go through to playoffs.
KO: Tennis style (1 plays 32, 2 plays 31 etc). Seeding based on player rating
Hybrid: think Soccer world Cup (pool play then KO). Could be tricky to implement if a nice number of participants is not registered - Maximum participants (max 16 for league, 64 for KO)
- Dates/times on which tournament takes place – uh oh, this will require a calendar system! First date is set in concrete – other dates provisional on number of entries. Clearly if you get only 4 entries for your KO tournament only one day is required. However, if you get 16 entering your league they you will need round 6 dates. After entries close, the provisional dates become concrete. You cannot schedule a tournament to clash with someone elses.
- Registration: Default open - immediately. Default close - 10 min before first melee
- Rating restriction (e.g. only accept entries from those below a certain rating for a newby-friendly tournament)
Novus, I will write a proper document up for this with even more detail.
My biggest reservation is latency. I know nothing of solving/improving this probem how the above ideas will make it worse.
|
|
|
|
« Last Edit: June 17, 2007, 05:13:27 am by Cedric6014 »
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
BTW, any news on the netplay lobby?
That's pretty much been on hold since we last discussed it; I don't think you ever answered my question about what language you'd intended to implement the server in. I didn't want to start implementing anything before hearing your ideas.
I didn't have any plans to implement the server myself at all. As I mentioned before, it is the perfect occasion for someone else to contribute, as it doesn't require knowledge of the UQM code, or of C even, and I had enough on my plate already.
I had thought about it a bit, and my thoughts would go to something light-weight, web-based. You would get a lot for free that way, as the layout could be done entirely in HTML, and not much interaction with UQM itself would be needed (only to start the game). I thought it would be a lot more likely to get finished that way.
But a client built into UQM, with a non-web-based server would be nicer. If I were to do that myself, I'd probably either make the server in C, based on the network stuff I wrote for UQM, or in Pike, which I'm rather partial to. The reason that I said Java wouldn't be my first choice is that I still think of Java as rather resource-heavy, and the computer serving uqm.stack.nl serves many other sites. But I guess that idea is outdated, especially if you compile to native code. And uqm.stack.nl is a decent machine nowadays, which can spare a few MB.
As the lobby would be full of activity (chat mainly), it's probably not such a good idea to start a new process for each command, which makes a CGI script a bad solution. So for a web-based solution, I'd be thinking of putting the static data on the uqm.stack.nl webserver, and letting the dynamic stuff be handled by a dedicated process with a minimal webserver built in, to which a persistent connection is maintained. I guess something like Java EE might be used, but I have zero experience with that myself.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
I had thought about it a bit, and my thoughts would go to something light-weight, web-based. You would get a lot for free that way, as the layout could be done entirely in HTML, and not much interaction with UQM itself would be needed (only to start the game). I thought it would be a lot more likely to get finished that way.
How would the web browser communicate with UQM in a way that wouldn't become a tech support nightmare? Most web browsers are set up specifically so that web sites can't start external programs without the user setting up file associations. Building the UI into UQM is the way to go, simply because problems getting the web thingy (which we don't control) and UQM to work together don't exist.
But a client built into UQM, with a non-web-based server would be nicer. If I were to do that myself, I'd probably either make the server in C, based on the network stuff I wrote for UQM, or in Pike, which I'm rather partial to. The reason that I said Java wouldn't be my first choice is that I still think of Java as rather resource-heavy, and the computer serving uqm.stack.nl serves many other sites. But I guess that idea is outdated, especially if you compile to native code. And uqm.stack.nl is a decent machine nowadays, which can spare a few MB.
Even when using Sun's VM (with the usual just-in-time compilation), the overhead is pretty much just a second or two at startup and about 20 MB of memory for VM and libraries; once the system is running, it's quite efficient. I'm not familiar enough with Pike to comment on it or write anything in it.
As the lobby would be full of activity (chat mainly), it's probably not such a good idea to start a new process for each command, which makes a CGI script a bad solution. So for a web-based solution, I'd be thinking of putting the static data on the uqm.stack.nl webserver, and letting the dynamic stuff be handled by a dedicated process with a minimal webserver built in, to which a persistent connection is maintained. I guess something like Java EE might be used, but I have zero experience with that myself.
Well, we agree on the basic design; one single server process is definitely the way to go. One major question is data storage. While chat messages are in through one ear (or network connection) and out through the other(s), some sort of persistent data storage (maybe a database) would probably be nice for things like league states (although just keeping everything in memory would be very fast and easy to implement, I'd hate to be the one to explain that, due to power failure, all active leagues have been reset). Putting stuff like that in a database would probably be a good idea in the long run (you already have one for the forum, right?).
The easiest way to group things would be to divide the lobby into rooms, each of which would have a chat channel and rules determining who you can play against and how the server tracks the results (free-for-all: challenge anyone, no tracking of games; various types of leagues and tournaments: results tracked by server and only opponents allowed by league/tournament type shown, registration allowed as determined by tournament type and organiser and independent of which room you are in at the time (i.e. you can be entered in several leagues at the same time and play one-off games without losing your place in the cup)).
The minimum client functionality is then: login/logout, select room (getting list of possible opponents), receive chat (and private) messages and opponent status updates and exit room, and, of course, start a game against an opponent (reporting status back when game over, if necessary).
The lobby UI would be split into a room/opponent list and a chat window, essentially replacing (or working as an alternative to) the current netplay connect dialog (in other words, you could set up your fleet before or after entering the lobby).
|
|
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
How would the web browser communicate with UQM in a way that wouldn't become a tech support nightmare? Most web browsers are set up specifically so that web sites can't start external programs without the user setting up file associations. A simple way to do this is running a mini-webserver in UQM itself, and then in the web page send a request to some port on localhost.
Even when using Sun's VM (with the usual just-in-time compilation), the overhead is pretty much just a second or two at startup and about 20 MB of memory for VM and libraries; once the system is running, it's quite efficient. I'm not familiar enough with Pike to comment on it or write anything in it. I think 20 MB is still quite a lot of overhead. Still, it is acceptable.
Pike is just my interpreted language of choice. You can substitute Python or Ruby or *shudder* Perl or something else.
Well, we agree on the basic design; one single server process is definitely the way to go. One major question is data storage. While chat messages are in through one ear (or network connection) and out through the other(s), some sort of persistent data storage (maybe a database) would probably be nice for things like league states (although just keeping everything in memory would be very fast and easy to implement, I'd hate to be the one to explain that, due to power failure, all active leagues have been reset). Putting stuff like that in a database would probably be a good idea in the long run (you already have one for the forum, right?). I think you should focus on chat and initiating games first. But a MySQL database on uqm.stack.nl is not a problem.
The easiest way to group things would be to divide the lobby into rooms, I was thinking along those lines too. A bit like IRC, but without making the same mistakes that they did: a specified character encoding (UTF-8), allowing spaces in various places where it is not allowed in IRC, extensible design, no lost messages, and no combination commands (like adding a message to "/leave"; if you want to say something, say it before you leave; it's just used for spamming now).
I have two unfinished documents regarding the protocol I had in mind. But feel free to do it your own way. Files: protocol and rationale.
I tried to keep it simple; the client is always in control. It decides when to check for remote events; the server doesn't send anything on its own. But no polling; a client can initiate a "wait for updates" state. Also, each confirmation of a command is accompanied by a result code that includes whether there are events waiting, for increased responsiveness.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
I think 20 MB is still quite a lot of overhead. Still, it is acceptable.
Pike is just my interpreted language of choice. You can substitute Python or Ruby or *shudder* Perl or something else.
While these have a lower start-up memory overhead, I'm not sure how well they handle long-running processes. A few years back at least, Python had issues with freeing memory; this may have been fixed already.
I think you should focus on chat and initiating games first.
Agreed.
I was thinking along those lines too. A bit like IRC, but without making the same mistakes that they did: a specified character encoding (UTF-8), allowing spaces in various places where it is not allowed in IRC, extensible design, no lost messages, and no combination commands (like adding a message to "/leave"; if you want to say something, say it before you leave; it's just used for spamming now).
No arguments here.
I have two unfinished documents regarding the protocol I had in mind. But feel free to do it your own way. Files: protocol and rationale. I tried to keep it simple; the client is always in control. It decides when to check for remote events; the server doesn't send anything on its own. But no polling; a client can initiate a "wait for updates" state. Also, each confirmation of a command is accompanied by a result code that includes whether there are events waiting, for increased responsiveness. |
|
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
I think 20 MB is still quite a lot of overhead. Still, it is acceptable.
Pike is just my interpreted language of choice. You can substitute Python or Ruby or *shudder* Perl or something else.
While these have a lower start-up memory overhead, I'm not sure how well they handle long-running processes. A few years back at least, Python had issues with freeing memory; this may have been fixed already.
I have two unfinished documents regarding the protocol I had in mind. But feel free to do it your own way. Files: protocol and rationale. I tried to keep it simple; the client is always in control. It decides when to check for remote events; the server doesn't send anything on its own. But no polling; a client can initiate a "wait for updates" state. Also, each confirmation of a command is accompanied by a result code that includes whether there are events waiting, for increased responsiveness. I was thinking pretty much on the same lines, except that I'd intended the connection to be in event listen mode all the time (i.e. the server can send an event any time after authentication except in the middle of a response to a command). In fact, my way is roughly what you get by wrapping almost every command in an ABORT and a (repeated) LISTEN. You might get a few unnecessary chat messages before leaving a room (for example) instead of a simple "messages available", but there's a lot less flow control messages going back and forth adding extra states to the protocol
And yes, it adds a few extra messages to the protocol, but only at a time when there's nothing to report. As every reply includes a status of whether there are more messages available, you don't even have to LISTEN if you know there are events available.
Though maybe adding a "count" argument to the POP command (or add a POPN command) to get multiple events at once would be useful, to do away with the repeated POPs (although you can safely queue POPs).
(and forcing the server to buffer events possibly indefinitely instead of until it has finished responding to a command). I'd prefer to design the protocol so that the server doesn't suffer if the client is behaving badly. Yes, eventually you have to start discarding events, if they aren't POPped. But this approach is also an advantage, as it allows for clients that have been momentarilly disconnected to catch up on messages they would otherwise have missed, something which I wish IRC had.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
Cedric6014
Enlightened
Offline
Gender:
Posts: 701
|
Here's something for you to look at
http://homepages.paradise.net.nz/~ejrh/uqm/lobby.png
Just before you all go "oh my god he's gone ahead and built a fully functioning netplay lobby!", there is no substance behind that image at all.
|
|
|
|
« Last Edit: July 26, 2007, 12:39:32 pm by Cedric6014 »
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
Memory leaks are bugs, and one interpreted language is not another. And even if these bugs are not fixed yet they might not even show up under our usage, or may be easilly worked around.
My point was that little-known languages have been subjected to less testing and are thus more likely to have bugs in their implementations. Java, for example, is too widespread to have (many) major problems in core functionality.
My protocol only has two states, sending, and listening. All the state information you have to keep is in which one you are. And in return this gives you the ability to know exactly what kind of information to expect, which makes the client very easy to write. It also allows the client to determine the rate that the messages come in, and even tell the server ad hoc to discard specific messages without having them sent over to the client.
I'm not saying that having a send/receive distinction is a bad idea, I'm just saying that I didn't think of having one at first, because it isn't necessary. It may be desirable, however, and I understand your reasoning for having it.
And yes, it adds a few extra messages to the protocol, but only at a time when there's nothing to report. As every reply includes a status of whether there are more messages available, you don't even have to LISTEN if you know there are events available.
Though maybe adding a "count" argument to the POP command (or add a POPN command) to get multiple events at once would be useful, to do away with the repeated POPs (although you can safely queue POPs).
The overhead may be small in practice; TCP has to send acknowledgement packets anyway; if I remember TCP correctly, they are often delayed to allow applications to add data to them.
Yes, eventually you have to start discarding events, if they aren't POPped. But this approach is also an advantage, as it allows for clients that have been momentarilly disconnected to catch up on messages they would otherwise have missed, something which I wish IRC had.
Assuming the protocol is built on TCP, having the server transmit events freely means that TCP on the server is going to have to buffer the remaining events (or the server performs a blocking write or a failure to write without blocking). If events are requested one by one (and event sizes are limited to less than the TCP implementation buffer), guaranteeing non-blocking writes (from the server app's point of view) becomes possible, which is a useful property in the server (at the expense of having to buffer messages in the server).
Hmm. I think you've convinced me.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
Nice mockup. Not quite what I was thinking of though. - Naming rooms after planets is confusing. Just let the creator of the room decide on the name.
- I would make it tabbed, with a tab for each room the player is in.
- There would be a list of challenges, with challenges to you specifically on top, and challenges to an entire channel below that.
Generally speaking, I think Cedric's solution is a bit too cluttered, although this is because I've approached this from an ingame UI point of view (the 320x240 screen forces you to keep the UI very simple, but has the advantages of being portable to consoles and handhelds and maintaining a consistent appearance; the downside is that manipulating large amounts of information gets really painful).
|
|
|
|
|
Logged
|
|
|
|
AngusThermopyle
*Smell* controller
Offline
Gender:
Posts: 304
A paranoid android.
|
Haha...The chat there is especially amusing.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
Pages: 1 2 [3] 4
|
|
|
|
|
