Jump to content


Photo

Online Multiplayer Lobby Project


  • This topic is locked This topic is locked
44 replies to this topic

#31 Yourself

Yourself

    The Ultimate Pronoun

  • GMC Member
  • 7352 posts
  • Version:Unknown

Posted 05 September 2009 - 06:36 AM

but it also needs to teach them PHP


And nobody should have to learn PHP because it sucks.

As apposed to what alternative? ASP?


Anyhow, there are many server-sides other than making your own: PHP, ASP, CGI, CFM, JSP, Perl, SMX, Python, Ruby, Lasso, even Ansi-C.


  • 0

#32 blue_chu_jelly

blue_chu_jelly

    Shut your FMaj7

  • GMC Member
  • 228 posts

Posted 05 September 2009 - 11:22 AM

but it also needs to teach them PHP


And nobody should have to learn PHP because it sucks.

As apposed to what alternative? ASP?


Anyhow, there are many server-sides other than making your own: PHP, ASP, CGI, CFM, JSP, Perl, SMX, Python, Ruby, Lasso, even Ansi-C.


Although not all basic hosting plans support python scripting, while most at the least support PHP.
  • 0

#33 sabriath

sabriath

    12013

  • GMC Member
  • 3179 posts

Posted 05 September 2009 - 06:27 PM

Although not all basic hosting plans support python scripting, while most at the least support PHP.


almost all free webhosting sites will allow PHP/CGI for serverside scripting, therefore making it in PHP logical, but if you pay for your own hosting (which can be as cheap as 10 a month), you can usually use any server-side service above, even your own homebrew program (that option is usually very expensive though).


  • 0

#34 jsorgeagames

jsorgeagames

    GMC Member

  • GMC Member
  • 710 posts
  • Version:GM:Studio

Posted 06 September 2009 - 02:04 AM

I have a suggestion regarding the voice chat system. Actually, I have two.

Method 1: Recording microphone sounds until finished, then sending them to all players.
This would begin a sound when the sounds the mic is "hearing" reach a certain level of volume. Then, when the volume returned to a lower level, the sound would end and the recorded sound would be sent to the master server as a file.
Pros:
- Solid method of sending voice recordings to other players.
Cons:
- Talking over other players and conversing in real-time will not be possible.
- Sound file may take a long time to get to master server, then to other players as well.

Method 2: Sending individual bytes of the current microphone sound to all players.
This would send sound data (frequency, volume, tone, etc) in real-time to the master server and then to all players. Then the sound could be assembled when it reaches a player's computer.
Pros:
- Allows for real-time conversations between players.
Cons:
- Method may not work well for incoming sounds, they will most likely be choppy or have other imperfections.
- Will be slow if multiple sounds from different players are sent at the same time.

Also, I would suggest not using arrays for the chat system, but ds_lists. I have found that after a certain amount of arrays, the framerate drops to nearly half the room speed (the number of arrays that cause slowdown depend on if they are used in loops or not)
  • 0

#35 safwat1995

safwat1995

    GMC Member

  • New Member
  • 394 posts

Posted 06 September 2009 - 02:47 PM

i'v done a lobby before, I never used it because it was too inefficient, and therefore adding features to the game itself was almost impossible.maybe it's a toy compared to this, but it might help you a bit.
i think i still have the gmk on one of my backup cds, tell if you want to take a look.
  • 0

#36 Tahnok

Tahnok

    Friendly Madman

  • GMC Member
  • 1827 posts
  • Version:Unknown

Posted 09 September 2009 - 08:10 AM

I have a suggestion regarding the voice chat system. Actually, I have two.

Method 1: Recording microphone sounds until finished, then sending them to all players.
[...]

Method 2: Sending individual bytes of the current microphone sound to all players.
[...]

Also, I would suggest not using arrays for the chat system, but ds_lists. I have found that after a certain amount of arrays, the framerate drops to nearly half the room speed (the number of arrays that cause slowdown depend on if they are used in loops or not)


Method 1 Criticisms: I don't think sound thresholds are a good idea for chatting like this. Everyone else doesn't need to hear every bump and bang that occurs behind someone. The game also doesn't need to waste CPU constantly scanning the mic's level. I think the better, and much more standard, route would be to have a "push to talk" system, where the player has to hold a button while they speak. This way players can control when other players hear them speak, and they're free to make noises and such without fear of it being broadcast to all players.

Recording the entire sound into a file and then sending the file is incredibly easy, but it's also incredibly slow. The delay introduced using this method would be unacceptable in pretty much any application, since trying to talk with large delays gets annoying. First it would have to wait for the player to finish talking, which right away introduces a lag equal to the length of whatever they are saying. Next you would have to wait for the transfer of the file to the player, which I would guess would take at least as long as it took to record for most connections. And somewhere in there (either during the transfer or afterward) it would have to check the file to make sure it didn't get corrupted during transfer. Needless to say it probably wouldn't even be worth having in a project.

Method 2 Criticisms: I think you're getting closer with this one, but it's still off. Simply grabbing frequency, volume, tone, and whatnot is either going to leave you with a bunch of unintelligible blips and bloops, or with a flooded network line.

The trick to how most applications do VoIP (voice over IP) is that they use a special streaming protocol (so it can start transferring as soon as the player starts talking) and advanced techniques for dealing with data loss and low bandwidth. I don't entirely understand the actual methods for either, but I know they aren't the simplest things around. I don't imagine that GM could do it without a DLL (besides the obvious lack of mic support).

I don't mean to just shoot down your ideas of course :) . Just pointing out some slight flaws with the logic so we can continue moving forward in the right direction.

I do also recommend against arrays for the chatting too though. Personally I would probably use objects, but that's because I'm used to in-game chatting, not an entire lobby. I also recommend rendering the text to a surface whenever possible, since drawing a bunch of text can be a bit CPU heavy.
  • 0

#37 sabriath

sabriath

    12013

  • GMC Member
  • 3179 posts

Posted 09 September 2009 - 09:00 AM

You can use BOTH methods at the same time *ahem*:

As the mic starts recording, it "buffers" the data into X amount of seconds, after that it buffers into a second stream while the first stream is sent out. Each Y amount of seconds after that point the buffer swaps between each other, while sending out the one it isn't buffering to. The clients will receive these "clips" and store them in a FIFO list. At the same time, the clients will go through the list, popping off the top clip one at a time, and play them in sequence (waiting for the clip to finish before starting the next one). This is how ventrillo works afaik, and is great for gaming because it: doesn't lag your network too much while playing your game, and people hear you in (almost) real time.

X and Y would have to be tweaked to find the right threshold of "real time" and "lag".

The reason you want to swap between buffers is because the one you are about to send would require compression techniques before you actually sent it (otherwise it would bog the network down and you should've just sent a raw datastream at that point). If you use a 2 second latency on the first clip, you can use full huffman on the delta data for best ratio, but if you use less time clips, you will have to resort to other (faster) techniques (lzw, rle, rlh, etc.).
  • 0

#38 Recreate

Recreate

    Furry

  • GMC Member
  • 2986 posts
  • Version:GM:Studio

Posted 24 September 2009 - 09:11 PM

but it also needs to teach them PHP


And nobody should have to learn PHP because it sucks.

How does PHP suck?
What a contradiction, when this forum is Made in PHP.
Besides, I think PHP is so easy, that if you know GML, You Pretty much know PHP too, All you gotta change is your if statements and semicolon's at the end of every line, which they should already know if they Use GML, and the Different Functions.(And isn't ASP a .net language? We all know how you love .net stuff.)
~ReCreate
  • 0

#39 PickleMan

PickleMan

    Programmer

  • New Member
  • 995 posts
  • Version:Unknown

Posted 24 September 2009 - 09:22 PM

I'll "donate" a PHP webserver with mysql...
  • 0

#40 T-Bird

T-Bird

    GMC Member

  • New Member
  • 1326 posts

Posted 25 September 2009 - 06:52 AM

Well. To get back on topic since the scope of this discussion is to create a scalable client-server system using GM, starting with a chat system seems like the wrong start - as someone else suggested.

1 - Establish a foundation
-A - create a client and server with the ability to connect one-on-one and send "hello world" messages
-B - expand server to distinguish separate connections and deal individually with each one
-C - allow server to relay messages from one client to all (messages should be prefixed with client IP or connection time to distinguish them). Continue to use "Hello World" messages.
2 - User system
-A - Allow users to register - likely each user will be a separate text file on the server (more about this below*) - and log in
-B - Instruct server to display an "all users online" list, sending both a name and an ID integer **
3 - Public Chat
-A - Build systems for user input messages
-B - (optional)Allow client-side blacklist filtering to block messages from certain users
4 - Private Chat
-A - Allow chat "sessions" to be established, clearly separated - perhaps a separate chat box - with specific user(s) that this session includes. (more below***)
-B - Allow user to specify one or more users to whom the message should be relayed - add a "to" field to the packet ***
5 - Game
-A - Expand client software to include integrated game server/client systems (assuming the goal is to have separate master and game servers)
--i - allow client to send IP/Port to Master Server
--ii - allow clients to retrieve IP/Port from Master Server
--iii - allow clients to disconnect from Master Server and connect to other client's Game Server
--iv - build gameplay
-B - Instruct server to distinguish users seeking a match
-C - Allow server to relay "invites" to matches from one client to another
6 - Expand User System
-A - Allow users to set preferences: color, nickname
-B - Allow users to (client side) register other users as their friends/rivals
-C - Allow users to (client side) filter public chat as well as user list by friend/rival criteria
-D - Allow users to initiate chat with all friends
7 - Add toys
-A - voice chatting
-B - public/private user profiles
8 - Tutorial

* While, yes, MySQL is the ideal way to store user information, that is outside the scope of this project. So that said, I would recommend the server has a Users folder. In that folder each user has an individual INI/Text file. The file would be arranges something like

USERNAME.INI--------------------------------
|										  |
|Password = //password hash				|
|Color = //player color					|
|Nickname = //players selected nickname	|
|...									   |
--------------------------------------------

This takes advantage of the fact that file-searching is a low-level operation provided by the OS so there is no need to program (and subsequently slow down) a system for finding a user. When a user logs in the program can simply find the INI file that matches the user name. If it cannot find it the user does not exist. If it is found then the hashed password from that file can be compared against that given by the user at login.

** While user names are good for displaying they are annoying to try and program with since you often run into needing to do string comparisons. When the server provides a user list, or any other user information, along with the name it should send a unique ID. Ideally this ID is unique to each user and doesn't change, so that user Yourself is always 1, user Herself is always 2, etc. While it is possible to assign a user a number dynamically when they connect this can lead to problems if, I.E. a user disconnects mid chat - in which case when they reconnect both users can't continue with the current chat session but must establish a new one.

*** Private chats should send a list of user IDs to whom this message should be sent. To limit packet size the number of members in a private chat should be limited to a reasonable number (perhaps 8). When the server receives a message from a client it relays the message - including the "to" header - to all clients in the list, and attaches a "from" header. When a client receives a relayed private message from the server it establishes a "session", that is it makes a new chat box. This chat box will store the "to" header of the received message. When a comment is made in this session the message is sent to all users stored in the session's TO list.

Sorry if this is a bit difficult to understand, I'm quite tired, and when I read this in the morning I will probably firmly plant my hand on my forehead.

@ALL - The discussion is NOT about the virtues of PHP or any other scripting language. It is NOT about whether or not this project should include said languages. The scope of the project isn't about achieving absolute efficiency. It's about the logistics, data handling, and structuring of reasonably efficient Client and Server programs made in GM. Since the end goal is to have a program that is structured and broken down to be turned into a step-by-step tutorial for GM users, use of any language except for GML should be excluded as much as possible for this project.

Edited by T-Bird, 25 September 2009 - 07:03 AM.

  • 0

#41 Tratser

Tratser

    GMC Member

  • New Member
  • 69 posts

Posted 28 September 2009 - 05:00 PM

If you search for the most optimal solution for a sub-problem, you won't get anything done this year.
If we want to get quick results, we should begin by making a simple battle.net-like client. And I won't get in to specifics of how to connect to a game server.
And it would be much easier to make a comprehensive tutorial of a simple system!

I think these are the essential components for the client:
GUI:
General design:
I suggest we aim for making reusable components, and try to display the minimal info the player needs and not more! This can be done by separate screens that can be opened with certain buttons, or drop-down lists with automatic scrollbars.
Making a nice abstraction-layer will make it much easier for others to make a similar system in the future.

-The chat screen. This displays who is in the channel that the screen is displaying, and of course the posts of the users.

-A main chat channel. It's just a channel, and you may set another channel as your main-channel. But once you have logged in, you always start at your chosen main-channel.
In the beginning only the server can add channels.

-A channel screen (for displaying all channels).

-A people screen, where you can see everyone that is online, and everyone that is on your friend list. This list may have sub-categories later, and you may be able to form groups. Navigating to another screen is not necessary, you may just open this screen so that it is covering only half of the screen, and you may chat at the same time.
You may use this screen to send short messages directly (like e-mails), or open a conversation with a person. And you may block people from this screen too, or invite people to a group, and other things.

-A list of all opened channels and conversations.

-A server screen, where you can see all the servers currently running. These may also be categorized and sorted. Perhaps half a screen is enough for this too.

-A settings screen (to change password, and other user info, and to change colors of the application and such).

-"Where is the main screen?" you may wonder, but it is there all the time! It is simply displaying a few icons and buttons that can take you to certain screens or display lists. It may be hidden, and only displayed once the cursor is at the top of the screen or something.

Programming:
-A forum-like chat system. I have already made one that may be extended to show more info about the user who posted the message. And perhaps color-codes and icons.
This system allows several windows of forums to be displayed at once, or hidden, and moved around.

-A dynamic list-showing system. I would like to see things like friend-list in list showed only when the mouse pointer is touching the friend-list icon. I have made a similar menu displaying system, but it is used to show inventories (icons and item name and data). But can be modified with ease.
There must be a function to sort lists by name.

-A simple list system that can be used for displaying the servers, and info of the servers.

-A menu showing system, used to show a few options when you right-click a certain item (what sets this appart from the dynamic list-showing system is that it doesn't have to be opened by it's following icon). So it may really just be a configuration of a more dynamic design.

-An edit-box system for writing messages (it can be scaled, but don't need a scrollbar).

Network:
-Join server script (send info of user, and wait for response)
-Event-handling script (a switch statement to handle all the responses to the messages the server may send/broadcast).



Server components:
Network:
-Handle temporary connections script (to handle users that have just connected, and must be accepted or declined connection)
---Check if the user name exists in an array loaded from a file of all accounts (not separate files! changes made to accounts may be stored into the file at 10 minutes intervals).
---If exists: check password.
---If password is valid: send an accepting message, and add the user to the list of connected users.
---If invalid: tell the user to check his password.
---Remove this temorary connection.

-Handle connected users script (receives messages from users)

GUI:
None! This isn't essential in the beginning, admin toys will come as we make it.

Ok, now a good framework is here, this should bring a greater focus, so what task will you focus at?
I will focus at the GUI, because this is the most important thing for my current project.

As you can see, I didn't specify much about the networking, because it will be clear what kind of messages needs to be sent when you do a certain thing in this interface. It is just a framework.
I may specify things later.

************
Moderator Edit: I removed six off-topic posts. It's OK for a discussion drift a bit. But it's not OK to post totally irrelevant comments, or participate in a separate discussion in someone's topic.

  • 0

#42 True Valhalla

True Valhalla

    ಠ_ಠ

  • GMC Member
  • 5277 posts
  • Version:Unknown

Posted 10 October 2009 - 11:13 AM

First time I've visited this thread; I'm surprised such limited progress has been made, so I'll throw in my 2 cents.

Posted Image

So first the players communicate with the master server and get the list of all the servers that are currently online. Those servers are all elsewhere in the world, being hosted by either players or at dedicated hosting sites. When the player decides what game to join they disconnect from the master server and connect to the server they found.


While I've thought a lot about how to establish a lobby system before, the only one I could come up with is that stated above. I consider it inefficient, for some reason, but at the very least it would work.

This should, voice chat the exception, be a fairly simple online program to code.

I too, as Sabriath repeatedly suggested, would strongly recommend the use of GM for both client and server. Sure, you could go with C++, PHP, and that, but in the end this is meant to be useful to GM users. The likelihood that they are going to be able to make changes to, yet alone interpret these alternate languages, is not high. GM servers can handle a lot more than people make out, and particularly one processing but a basic chat function and friends list.

OP, feel free to PM me at any time if you have troubles with the online coding. I'll happily whip up an example of how to do pretty much anything that doesn't use other languages. I might actually work on this on the side of my game, in a hope to push this project along.

-Tv
  • 0

#43 xshortguy

xshortguy

    GMC Member

  • Global Moderators
  • 4345 posts
  • Version:GM:Studio

Posted 10 October 2009 - 03:05 PM

Such little progress has been made on my part since I've been very busy with my physics classes that I haven't had any time to work on the project. I might not get around to it for awhile. With that being said, don't let my absence in the project hinder all of you from designing prototypes and plans. I'll return to this when I have time.
  • 0

#44 Zappix

Zappix

    GMC Member

  • New Member
  • 54 posts

Posted 17 November 2009 - 09:21 PM

I've built a functioning server lobby for my games, it uses an external webhost for the account system but it can support different games and has working chat.

It can be seen in my game, Spherack Reloaded
http://andrewnatoli....herack-reloaded

(The game no longer uses the chat system in the lobby)

Edited by Zappix, 17 November 2009 - 09:24 PM.

  • 0

#45 Revel

Revel

    ɹǝqɯǝɯ ɔɯƃ

  • GMC Member
  • 4922 posts
  • Version:GM8

Posted 30 December 2009 - 01:33 AM

I'm not sure what the point of this topic is. I'm sure anyone here that knows 39dll could make a lobby system quite easily.

Also, has any progress been done on this since September 2, 2009?


If you want to make something like battle.net, all you need to do is have a central server which stores IP addresses (for individual games) as well as game titles, max players, etc. Then just maintain a connection to the central server to enable things like chatting, etc.

Voice chat would also be quite easy as long as you had enough bandwidth on the central server. You could simply record a clip, save it as a file, optionally compress the data, and send it out. Having a live stream might be a bit harder but having a live stream is not always necessary.

Edited by Revel, 30 December 2009 - 01:42 AM.

  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users