Jump to content


Photo

Online Multiplayer Lobby Project


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

#1 xshortguy

xshortguy

    GMC Member

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

Posted 02 September 2009 - 07:26 PM

Multiplayer Lobby Project



The Goals:
  • Learn to create a lobby and in-game environment with the following features:
    • Server / Client system that stores user names and passwords.
    • Users can set display names other than their user name.
    • Users can maintain profiles and friends lists.
    • Users can create and join both public and private chat rooms.
    • Displays the number of users in a chat room and the maximum number of users.
    • Users can send messages to other members.
    • Users can connect to instances of the game that this lobby service is created for.
    • Voice Chat Capabilities, if feasible. (Low Priority)
  • After all that is learned, then a tutorial will be created to help other users design such lobbies.
Overview

This is a project that I will be working on during my spare time. I am expecting assistance from the community as a whole as I work on this endeavor. I never really (successfully) tried to do any multiplayer applications using Game Maker, so this task is quite the undertaking. In a nut shell, this project is designed to help players design a small service such as battle.net to connect players into their multiplayer game.

There are two reasons why I am starting this project. The first is that I really wish to gain some knowledge in working large multiplayer systems such as this. Second, there is no tutorial or underlying framework for this type of connection setting. Being able to help people create such systems will move game maker forward in the multiplayer department.

Finally, it may come to the event where I stop working on this project. Fortunately, this is primarily going to be an open source project aimed at community involvement. While it is not a major task such as the GMCG, it is still one that users can have fun with.

Tools

Currently, the two primary tools for this task other than Game Maker are the following:
  • 39DLL: This is to be used for transmitting data between computers.
  • Icuurd12b42's FMOD DLL: This hopefully can be used to handle voice chat through game maker.
Other tools may be added as the project continues.
Current Progress

September 2, 2009: This is when the project started. The topic has been created to help start the project. No programming has been started. Planning stage has begun.

Notes
  • It is my understanding that such features described here must be integrated into the game from the start. Hence the goal of this project should include providing a sample game to be included with the project. The game I have decided on is a knock off of Hasbro's Connect 4.
Contributors
Any person who contributes to the project will be added here.
GMC Name (Real Name--optional)
XShortGuy (James Pedid)
  • 0
Check out my Profile's About Me Page for some useful links.

#2 xshortguy

xshortguy

    GMC Member

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

Posted 02 September 2009 - 07:29 PM

The first focus of this topic is to develop a single player engine to display texts that scale automatically to the window. The goal here is to display a simple chat environment that will accept text as input and display it on the screen. Here is the starting point of such an engine, to be refined and later rebuilt with the idea of sending messages in mind.

I will periodically update this post with updates to our basic chat engine. Post improvements or alternate solutions to the problem here.

mp_chat
Create Event
key_chat = vk_enter;
sv_chatmode = 0;
sv_chat_array_max = 22;
var i;
for (i = 0; i < sv_chat_array_max; i += 1)
{
	sv_chat_array[i] = ""
}

Any Key Press Event
if (keyboard_check(key_chat) == true)
{
	if (sv_chatmode == 0)
	{
		sv_chatmode = 1;
		keyboard_string = "";
	}
	else
	{
		sv_chatmode = 0;
		if (keyboard_string == "") exit;
		for (i = 1; i < sv_chat_array_max; i += 1)
			sv_chat_array[i-1] = sv_chat_array[i];
		sv_chat_array[sv_chat_array_max - 1] = keyboard_string;
		keyboard_string = "";
	}
}

Draw Event
draw_set_color(c_white);
draw_rectangle(16, 16, room_width - 16, room_height - 16, 0);
draw_set_color(c_black);
draw_rectangle(16, 16, room_width - 16, room_height - 16, 1);
draw_rectangle(16, room_height - 16, room_width - 16, room_height - 48, 1);
if (sv_chatmode == 1)
	draw_text(24, room_height - 40, keyboard_string + "|");
var ypos, i, j;
ypos = 24
for (i = 0; i < sv_chat_array_max; i += 1)
{
	draw_text(24, ypos, sv_chat_array[i]);
	if (sv_chat_array[i] != "")
		ypos += string_height(sv_chat_array[i]);
}

  • 0
Check out my Profile's About Me Page for some useful links.

#3 databot

databot

    admin of moonlight games

  • New Member
  • 309 posts

Posted 02 September 2009 - 08:25 PM

With regards to coding of the server side application, have you decided on a programming language? Perhaps PHP/MYSQL or java mabye?
PHP/MYSQL would seem the best comprimise for ease of use and functionality as well as ease of deployment.
PHP Would provide all the needed functionality for a login system, along with display names, bio, firneds list and messaging. It could also hold server lists.

As for a chatroom system PHP would be inneffective due to large amounts of overhead.
GMsock came with a java based Proxy (GmProx 1.0) that would provide a basic way to run chatrooms, both public and private. Or it could be used as a model for your own code.

I would like to express my interest in this project, particuarly your idea for voice chat.
  • 0
Completed:
Scrip - Command line engine in the palm of your hands Get it Here
XML - XML simplified

#4 xshortguy

xshortguy

    GMC Member

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

Posted 02 September 2009 - 08:42 PM

The idea is to actually use Game Maker for all of it. (At least, initially, using only the two dlls listed as of now. That can change.) Game Maker can certainly create programs to handle data maintenance by storing information in local files. However, I am always open to suggestions and will always accept codes or concepts to perform a task. In fact, I encourage people to come up with solutions that will help meet this goal. I most likely won't finish this project if I do it all by myself. I'm looking for assistance from others.

I'm already rewriting the basic chat mechanisms to scale to the room size. I'll edit the second post when that arises.
  • 0
Check out my Profile's About Me Page for some useful links.

#5 cooldudetb

cooldudetb

    GMC Member

  • New Member
  • 190 posts

Posted 02 September 2009 - 08:45 PM

The idea is to actually use Game Maker for all of it. (At least, initially.) Game Maker can certainly create programs to handle data maintenance by storing information in local files. However, I am always open to suggestions and will always accept codes or concepts to perform a task. In fact, I encourage people to come up with solutions that will help meet this goal. I most likely won't finish this project if I do it all by myself. I'm looking for assistance from others.



I would highly suggest not using game maker for the server, and instead using php with MYSQL. Game maker was not built to handle the large amounts of data the server will have to send, receive and save. It also means you would have to have the GM server program running 24/7.

However, I'm interested to see how you would implement an effective voice chat system, as in my experience they normally are very laggy, and can go horridly wrong if the ping gets too low.

I too am very interested in this project, and would like to contribute towards it's success in any way possible.
  • 0



#6 xshortguy

xshortguy

    GMC Member

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

Posted 03 September 2009 - 12:16 AM

I'm still tinkering with a chat module and creating a set of functions for it. However, I feel like I should lay out an outline for this project:
  • Develop Messaging Module
    • Establish User Name System
    • Determine Message Aesthetics
    • Program Text Display
    • Program Text Entry
    • Develop Functions to Send Messages Between Users
  • Develop Chat Environment
    • Develop Chat Room Aesthetics
    • Program Creation of Chat Rooms
    • Program Connection to Chat Rooms
    • Program Chat Room Functionality
    • Develop Lobby System to Connect Chat Rooms
  • Develop Friends List Functionality
  • Develop Example Game Connection Environment
    • Develop Game (Connect 4)
    • Program Multiplayer Component
  • Delve into Voice Chat
  • Create Tutorial (this will be done periodically)

  • 0
Check out my Profile's About Me Page for some useful links.

#7 brett14

brett14

    GMC Member

  • GMC Member
  • 1151 posts
  • Version:GM8

Posted 03 September 2009 - 05:03 AM

not sure if you want to do this or not, but an easy way to add a serverlist to your application would be to use this.
http://gmc.yoyogames...howtopic=442985
It uses a ftp server to store data, so the players could host a game, and the games will be put up on that server, and when the client request to "find" games he can find the ones currently being hosted on the server.
  • 0

P3DC V6.00 | Editor14 | Large 3D Terrain

GML programmer since 2005, C/C++ programmer since 2009, Java programmer since 2012


#8 cooldudetb

cooldudetb

    GMC Member

  • New Member
  • 190 posts

Posted 03 September 2009 - 07:03 AM

not sure if you want to do this or not, but an easy way to add a serverlist to your application would be to use this.
http://gmc.yoyogames...howtopic=442985
It uses a ftp server to store data, so the players could host a game, and the games will be put up on that server, and when the client request to "find" games he can find the ones currently being hosted on the server.


There are some issues with that idea.
FTP is:
1. Insecure
2. Quite slow

Plus the fact that as a lobby this program's main function is a server list, I think using a slow and insecure transfer protocol for the main function of the application is not a good idea.

I'm still tinkering with a chat module and creating a set of functions for it. However, I feel like I should lay out an outline for this project:


I feel we should lay out this project with the main engine more in mind, as you seem to have missed it out completely in your plan:

1. Develop Basic Client - Server connection
a. Develop server base
b. Develop client base
2. Develop Basic Account system
a. Develop serverside account database
b. Develop clientside login/logout
3. Develop Chat System
a. Develop Chat room functionality
b. Develop Basic chat relay system
c. Design Chat UI
d. Design chat lobby
4. Develop Game server connection system
a. Design game server lobby
b. Program test game
c. Implement multiplayer component
5. Design extended account system
a. Develop Friends list
5. Have a look at voice chat
6. Do large amounts of testing and bug-checking
7. Create Tutorial

That is just my idea of the plan, if you don't like it stick with yours.

Edited by cooldudetb, 03 September 2009 - 07:04 AM.

  • 0



#9 brett14

brett14

    GMC Member

  • GMC Member
  • 1151 posts
  • Version:GM8

Posted 03 September 2009 - 07:14 AM

I'm just putting suggestions out there. It'd be great if this would work, but would somebody be willing to host a 24/7 server that has a serverlist for multiple games? If not then you might want to use an online database (or a php page or something of the sort). If some one is willing to, then just ignore my suggestion and use the faster better more secure method.

However just against your arguments, it's not like your communicating via FTP, your just downloading a very small text file that contains server info. You read the info and connect to the server (I see what you mean insecure though, somebody could give you the ip to connect to a virus download site)

Edited by brett14, 03 September 2009 - 07:16 AM.

  • 0

P3DC V6.00 | Editor14 | Large 3D Terrain

GML programmer since 2005, C/C++ programmer since 2009, Java programmer since 2012


#10 xshortguy

xshortguy

    GMC Member

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

Posted 03 September 2009 - 07:20 AM

I'm certainly open for discussion, since I have never embarked on this endeavor before. If you know more than me, then I'd be happy if you provided a better goal list.
  • 0
Check out my Profile's About Me Page for some useful links.

#11 brett14

brett14

    GMC Member

  • GMC Member
  • 1151 posts
  • Version:GM8

Posted 03 September 2009 - 07:36 AM

I'm just thinking, but wouldn't it be better to program most of the data handling in c++? The bulk of the program could be programmed in GML (easier, good for users to integrate into their games) but the slower[speed] part could be written in C++. I know it'd be faster [speed], but I do not know how hard it is - simply because I don't program in c++. Also for this to work, you'd need a few people who know c++ to help you develop the program.
  • 0

P3DC V6.00 | Editor14 | Large 3D Terrain

GML programmer since 2005, C/C++ programmer since 2009, Java programmer since 2012


#12 sabriath

sabriath

    12013

  • GMC Member
  • 3197 posts

Posted 03 September 2009 - 07:40 AM

I see nothing wrong in writing the entire chat program in GML....both server and client. Good luck xshortguy on your endeaver, don't listen to these guys saying "don't do it, use php/sql".

p.s. *cough* where's my creds? :whistle: lol
  • 0

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#13 brett14

brett14

    GMC Member

  • GMC Member
  • 1151 posts
  • Version:GM8

Posted 03 September 2009 - 07:48 AM

I'm not saying don't do it, I'm saying it'd be multiple times faster if you used those instead of gml.
  • 0

P3DC V6.00 | Editor14 | Large 3D Terrain

GML programmer since 2005, C/C++ programmer since 2009, Java programmer since 2012


#14 cooldudetb

cooldudetb

    GMC Member

  • New Member
  • 190 posts

Posted 03 September 2009 - 06:53 PM

The reasons I am highly recommending php & MYSQL over game maker is simple. Performance and practicality.

As I said earlier, Gm was not built to manage large amounts of data in short spaces of time. The server would be constantly swamped with messages from all the client connected to it, asking it to retrieve, store and send data. A php server, with MYSQL, can efficiently read and write large amounts of data and send information to clients.

A GM based server would have to be running on someone's computer 24/7, and would have to be restarted manually if it crashed.
A php server can be up 24/7 running on a web server, and is almost impossible to crash in any way. The most that could happen is that the script simply returns an error.

However, if you feel for any reason that a Gm server would be better than a php one, go ahead. I'm not going to stop you. :whistle:
  • 0



#15 sabriath

sabriath

    12013

  • GMC Member
  • 3197 posts

Posted 04 September 2009 - 12:24 AM

*sighs* It is rediculous how many people in this community would turn to php/sql faster than they can bat an eye when it comes to online. I thought this community dealt with GM....and since GM can handle online things, why would you instantly turn somewhere else? PHP/SQL are interpretive as well, albeit programmed with much better wrapping than GM, it is still interpretive. It also needs to be 24/7 NO MATTER WHAT YOU USE! If the webserver is down, you're SOL because more than likely you got a free webserver and it's not like you can just walk up to their main office and say "hey, can you stop running maintenance, I need my chatserver to work." Not to mention that if they decide to stop running services for sql or server-side at any time, you are also SOL on that too.

This is a GM community, if you want to speak PHP/SQL, then go find one of those communities. As far as I'm concerned, everything we do here is 100% GM, or linked through DLL into GM.

Plus SQL is slow when all you are saving is name/password lists, that is an easy lookup table database, you don't need a relational one for it. That's like saying "I need to crack this egg open" and instead of using the side of the counter or a backend of a utensil, no...let's go grab a forklift, a bulldozer, maybe a treecutter, dumptruck and a crew of 12. Sure you won't get the file protection that sql offers, but you can always use md5 or other hashing techniques to obscure the passwords for your clients....which, incendentally, 39dll comes with...OH MY GOD WHAT?

There is no harm in at least trying to make it 100% GM....you people don't even understand the reasoning behind making this project. The code created here can help others in learning how to make small chat sessions inside their games, or did you want them to run their RTS/MMORPG against a webserver too? *laughs*
  • 0

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#16 dimitri

dimitri

    GMC Member

  • GMC Member
  • 248 posts

Posted 04 September 2009 - 01:40 AM

If you were making a game which would be running in realtime, I'd say create the Server program in C++. However, since there is pretty much no massive amount of physics/graphics calculations going on every second, I'm going to agree with sabriath and say GM would be a good idea for creating both the Server and Client programs. This is coming from a person who has created multiplayer games with the GM 39DLL using the Server/Client system.

The only problem I see here is that someone is going to have to host this Server program and leave their computer on 24/7, which is pretty impractical.
  • 0

#17 xshortguy

xshortguy

    GMC Member

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

Posted 04 September 2009 - 03:04 AM

The point of this project is learn how to develop these types of systems and create a tutorial in doing so, and not to have a long-running server that's always online. As far as I'm concerned, details that regard to actually acquiring and maintaining the server is beyond the scope of what this project aims to do.

Instead of bickering about whether or not we should outsource things to external languages (excluding the 39DLL and FMOD if voice chat is deemed feasible), if anything we should cover each alternative in this tutorial.

For participation in this project, in addition to looking for suggestions on which way to begin creating such code are the codes (or pseudocodes) themselves. I'm not entirely familiar how to send more than a few basic concepts, and for me this is half of the challenge. Creating multiplayer environments such as lobbies, or even the games themselves, has a steep learning curve. The point of this project is to help alleviate the difficulty in developing these systems by providing an easy to use tutorial on how to develop these types of things.
  • 0
Check out my Profile's About Me Page for some useful links.

#18 Tahnok

Tahnok

    Friendly Madman

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

Posted 04 September 2009 - 06:24 AM

Scanning through this topic I see a bit of confusion (or maybe it's only me that's confused). People seem to be confusing the master server listing server with the actual game servers. They are two different things and need to be treated as such. The master server listing server is the one that tracks the user accounts and logins, and keeps a list of all the servers for players to connect to. The game servers are the ones that players connect to in-game to actually play, and they handle the actual gameplay message handling. Trying to mesh the two into a single program or idea is just asking for trouble.

So now that that's cleared up, here's my opinion on how the two should be handled.

The master server (responsible for player accounts, the server listing, the main lobby system, etc):
Without one of these for your game players are required to manually find and enter the IPs of any online game server. Needless to say, that get's really old really fast. Therefore it also needs to be online 24/7, since when it goes down every single game server gets lost in the big wide open internet and players have no way of finding each other. As far as what language to write this in, yes you could write it in C++ or in GM, but that would require a dedicated server computer (which most of us can't afford). That's why I recommend the PHP/SQL combination that has been mentioned. With a bit of ingenuity you can use a basic online database to track servers and such in real time. ReflectGames.com does exactly this. I'll leave it up to Fred whether or not he want to reveal some of the inner workings of that though.

The game server (responsible for net traffic for the actual gameplay):
Of course, once in-game there's no point if you can't actually play, so you need a solid and fast game server. Fast is the keyword there, so there's no way PHP/SQL will work. I recommend C++ if you can handle it (since it's extremely fast and doesn't have the high overhead that GM games do). Of course though GM is a lot easier, and there are actually a few cases where it may be prefered. For example, in The Havoc Agency I used GM for the server program because I wanted it to be running a copy of the game logic under the hood, so I could make things like server-sided collisions and better anti-hack.

Now as far as the chat ability, that's a bit tricky design-wise. If you want system-wide chat capability you need a master server that can handle that amount of traffic in a reasonable time. Of course, PHP/SQL is right out for that. So if you want that kind of ability you're again looking at a C++ or GML master server program running on a PC somewhere 24/7. The alternative is to only allow chat within the actual servers, which is trivial if you've already gotten the gameplay communications going.

Likewise with voice chat. Does the application need voice chat system-wide, or only in-game? Neither one is easy, but in-game requires less resources as far as a master server.

The point of this project is learn how to develop these types of systems and create a tutorial in doing so, and not to have a long-running server that's always online. As far as I'm concerned, details that regard to actually acquiring and maintaining the server is beyond the scope of what this project aims to do.
[...]

If you're not thinking for the long run then the tutorial will be pointless. Real online games need their master server on 24/7 to be successful, so why design and practice anything less? Learning how to make a partially working system isn't going to help anyone make a successful online game.
  • 0

gmc_signature.png


#19 xshortguy

xshortguy

    GMC Member

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

Posted 04 September 2009 - 06:48 AM

If you're not thinking for the long run then the tutorial will be pointless. Real online games need their master server on 24/7 to be successful, so why design and practice anything less? Learning how to make a partially working system isn't going to help anyone make a successful online game.


The tutorial is meant to discuss how to program such a server, not set one up. If you or anyone else would like to have such a tutorial as an appendix to what is to be considered, then go ahead and do so. The goal of this tutorial is to create a lobby system (as a separate program) that will connect players to instances of a built-in game, which is one program. Think of it as being the client-side visuals of a game such as Starcraft, Diablo, or Warcraft III--the early battle.net. The actual game servers run off of different programs, or even off of user computers, but the matchmaking programs run directly through the executable. This can be more or less desirable, depending on the game. The technique for doing it either way should be trivial.
  • 0
Check out my Profile's About Me Page for some useful links.

#20 sabriath

sabriath

    12013

  • GMC Member
  • 3197 posts

Posted 04 September 2009 - 06:56 AM

{snipped some crap}


Ok, I'm going to make it very clear to everyone in pictures, since people tend to not read very well.

Posted Image

There's nothing wrong with that set up....chatserve can handle logins as well as relay. I have said many MANY times, you CANNOT have more than 1 packet on an electrical line between devices at the SAME TIME....I feel like I'm talking to myself for real. Because of this rule of electronics, the socket and network card are not just gonna ignore data, they see it all....the lag would be in the congestion between the internet and the router. The socket will buffer the data if the server program is lagging reading the information...but it's not going anywhere. Sure if thousands of people suddenly tried to connect AT THE SAME TIME...there might be a few seconds of lag to send chat messages...but that's like saying there is a backup at the sewage plant at half-time at the super bowl because everyone flushes their toilet.....it doesn't.

I will show you what WILL lag the system though:

Posted Image

That is what you are suggesting, have 1 program do the logins, and another program do the chat relaying. The place marked "here" is the location you are now lagging information, although as I stated before no information is lost, but you push the lag from the router-internet location to INSIDE your own network.

If you use a webserver to login and have a separate network to do the "game" or chat program, that would be somewhat ok, but how would you possibly transfer a socket from one computer to the other after accepting a login? (you can't, it's rhetorical). Which means you would need yet ANOTHER accepting listening device and ANOTHER check authentication...which makes your webserver useless.

Debate it all you want, I think I've made my point clear. Do the chat program in GM, all of it, you'll be fine.
  • 0

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#21 Tahnok

Tahnok

    Friendly Madman

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

Posted 04 September 2009 - 08:52 AM

@xshortguy: Sorry, I'm not much of an MMO person so I don't know those examples. But from what I understand it sounds like we're thinking along very similar lines.

My point about the tutorial was that if you're teaching people how to program a server listing/lobby program in GM it's of little use to them in the real world, since that would require running the program 24/7, which most people can't do. A PHP/SQL solution would be much more helpful since it can be run on most standard web hosts, which people do have access to. I'm just thinking about it from a practical application standpoint and what will actually work for people in the end.

@sabriath: It's not crap, you've just misunderstood (or maybe I failed to completely explain what I meant). I'm not suggesting that the two programs be run on the same computer, behind the same router. That wouldn't make any sense since that would suggest that there's only one game server, which would eliminate the need for a server listing/lobby. I was suggesting that there would have to be a central method for keeping track of servers being run from other locations. Example:

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.

Again, it's a similar method to what ReflectGames.com uses, along with bigger names like all the Valve titles.
  • 0

gmc_signature.png


#22 sabriath

sabriath

    12013

  • GMC Member
  • 3197 posts

Posted 04 September 2009 - 09:12 AM

@xshortguy: Sorry, I'm not much of an MMO person so I don't know those examples. But from what I understand it sounds like we're thinking along very similar lines.

My point about the tutorial was that if you're teaching people how to program a server listing/lobby program in GM it's of little use to them in the real world, since that would require running the program 24/7, which most people can't do. A PHP/SQL solution would be much more helpful since it can be run on most standard web hosts, which people do have access to. I'm just thinking about it from a practical application standpoint and what will actually work for people in the end.

@sabriath: It's not crap, you've just misunderstood (or maybe I failed to completely explain what I meant). I'm not suggesting that the two programs be run on the same computer, behind the same router. That wouldn't make any sense since that would suggest that there's only one game server, which would eliminate the need for a server listing/lobby. I was suggesting that there would have to be a central method for keeping track of servers being run from other locations. Example:

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.

Again, it's a similar method to what ReflectGames.com uses, along with bigger names like all the Valve titles.


OMFG!! *shoots self in head with a dull pencil*

*lies dying wondering why people think this is some sort of game, rather than a chatserver*

Your way suggests this:

(a) client connects to a webserver to get a listing of the servers currently online
(b ) client chooses one of those servers and connects to them using the webserver for authentication, even though it will require a double authentication because of a movement in sockets
(c ) when a client wants to send a message to someone else that is NOT connected to that same server, the communication now has to hop from 1 server in the listing to all the servers in the listing...hogging bandwidth. at the point, the server that actually contains the person you want to talk to, will relay that information
(d) same with playing a "match game" with that person, IDs would have to be passed between servers

however, if you plan to segragate the logins to the subservers, which means you cannot talk to people not in that server, then you reduce the amount of people you can play and talk to to save on server lag. but still have to do double authentications, and storage of character information separately.

My method is simple, 1 server program that handles all chat:

(a) client connets to server
(b ) server accepts and authenticates
(c ) client can talk to anyone and start a "match game"

what is NOT mentioned by me is the "game" part of this....I have been speaking merely on the chatserver. A match game would be handled similar to how yahoo messenger does gaming:

(a) player "a" sends request to play pool to player "b" (through chat server)
(b ) player "b" chooses to accept it, gets the IP address of player "a" from server and opens up a listening socket
(c ) server tells player "a" that it was accepted and gives him player "b"'s IP address
(d) player "b" connects to player "a"
(e) player "a" accepts the connection and verifies the IP address as the one the server gave it
(f) match is played between player "a" and player "b" WITHOUT INVOLVING THE CHAT SERVER ANY FURTHER for game relay information.

You could have a secondary server to handle "match watching" to ensure no cheating, but it is not necessary in games like "chess" and "checkers" since anybody can just say "oh my god, you're cheating! I'm not playing you anymore *clicks ignore and quit*".

Did a light bulb go off yet? Is there something that you might be missing? You could have multiple servers STILL in my diagram for clustering and tiering if you happen to get more people than you can handle in the lobby, but it's GM, it's for tutorial reasons and a learning experience for both xshortguy and the community.

{edit} and to add a final note: if your master server is down, then there is no way for more servers to add to the list, nor any player connect because it does not effectively know any servers are on.....which wastes costs and power (since the subservers may be on without the master on). In my example, the master server IS the only thing, so if it goes down (usually for maintenance), you don't lose any costs other than customers. You could make it a ring server so maintenance would run alongside a backup unit. Think AIM, Think Yahoo Messenger....don't think World of Warcraft right now.

Edited by sabriath, 04 September 2009 - 09:19 AM.

  • 0

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#23 Tahnok

Tahnok

    Friendly Madman

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

Posted 04 September 2009 - 10:53 AM

OMFG!! *shoots self in head with a dull pencil*

*lies dying wondering why people think this is some sort of game, rather than a chatserver*

Chill out already. This is the experts forum; we're working together here to find the best possible solution. So get off your soap box and speak to me in a civil manner.

Now reread my original post. I first stated the difference between game servers and the chat server/lobby server (since people seemed to be getting that confused). At no point did I suggest that if you're going to go for central chatting (where anybody logged in can talk to anybody else logged in) that it should be handled by more than one central server (I in fact pointed out that it would have to be handled in a central server and that it has certain complications). The only time multiple servers would work for chatting is when you only want to be able to chat with players within the game server (which is rather common, especially in indie games). So your suggestion on what you think I was suggesting is off.

Seeing as the genre for this idea has not been clearly defined you can't assume that you're dealing with simple 2 player games like chess and checkers. The moment it gets into more complicated games than that the system you're proposing will fall flat on it's face. Furthermore, point F is especially flawed. Communication between players without a server is just asking for router/firewall/port forwarding issues. You're essentially asking any player, regardless of their internet setup, to act as a server. Plus, you're basically recreating my system but with the before mentioned downfall. Basically you're just having your players create servers as needed and then piping them off to those. Absolutely no different than what I already explained, except that my idea had the servers already running and players coming and going as needed.

As for your final note, did you notice that there's absolutely no difference between those two scenarios? In either case the user still can't access the server. And the fail safe method you mentioned can be setup using either idea. Therefore there's no real advantage or disadvantage to either method in that regard. As I stated in my original post, if your central server goes down and you have no backup plan then you have problems no matter whether you're running multiple servers or a single large server behind the scenes.

As for the scope of the tutorial, of course I realize that this is supposed to be a simple tutorial to educate people who are new to this sort of thing. On the other hand though it will be of little use to them if the methods we teach them don't scale well. Online game development is all about scalability, no matter the genre (or non-genre, in the case of a pure chat program). The method I'm suggesting isn't especially complicated either, it just allows for the necessary complications of bigger games. Therefore I propose that this project be given clearer guidelines as far as what precisely is required, especially the genre (since the standard for this sort of thing varies greatly between genres), a target player amount (so we know how much traffic the system should be able to handle), and the chatting requirements fine tuned (whether chatting has to occur as part of a main lobby or only within games). Of course, those should be xshortguy's call, since he's the topic creator.
  • 0

gmc_signature.png


#24 sabriath

sabriath

    12013

  • GMC Member
  • 3197 posts

Posted 04 September 2009 - 11:03 AM

Well, my apologies then. it's late, should've gone to bed hours ago. I'm still having problems finding a proper textbox clone (gm widgets comes close and i JUST found maxwinapi but it is a bypass into the commons control), I need it to properly create a good chat program.

Any suggestions? I would like the richtext to be similar to how this forum is set up with bracket coding. I'd hate to have to program it myself from scratch. Otherwise I'll have to go with widgets for the time being.

{edit} I'm off to bed now before I say more stupidity.

{edit2}

The game I have decided on is a knock off of Hasbro's Connect 4.

That was the OP, and it was my assumption the chats were going to be set up in "lobbies" where you can play this game against other people. And you're right about portforwarding, I always forget that part...although if both people have the other IP, you can punch a hole in for a connection sweep, or resort to having a second server relay game stuff (not on same network as chat server). Ok, for real, going to bed now, good night

Edited by sabriath, 04 September 2009 - 11:12 AM.

  • 0

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#25 Tahnok

Tahnok

    Friendly Madman

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

Posted 04 September 2009 - 11:35 AM

Thank you. No worries :whistle: .

Hmm, I'm unaware of any richtext ones. The best plain text one I know of off the top of my head is Gamepad by IsmAvatar. It's a pure GML solution and quite nice. You can also check out Game Widgets by B&B_Gaming which uses the before mentioned Gamepad code but adds on more controls. WinApi is a powerful DLL, but it's not without it's flaws (I seem to remember it acting funny sometimes when I start switching between windows and shrinking/maximizing things).
  • 0

gmc_signature.png


#26 cooldudetb

cooldudetb

    GMC Member

  • New Member
  • 190 posts

Posted 04 September 2009 - 03:02 PM

*Snip*

Irrelevant because it took so long to post.

Edited by cooldudetb, 04 September 2009 - 03:04 PM.

  • 0



#27 NakedPaulToast

NakedPaulToast

    GM Studio/Mac/Win

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

Posted 04 September 2009 - 06:16 PM

This topic is not about creating the most efficient server model.

This topic is an exercise in learning how to write a client/server component. It's target audience is the GMC, the only assumption that can be made, is that the audience should have a fairly strong understanding of GML.

To create a tutorial that incorporates PHP/SQL or anything other than GML on the server side will reduce the value of the tutorial. The value it adds will be minimal.

If one does not know PHP, then not only does this tutorial have to teach them multi-programming concepts and techniques, but it also needs to teach them PHP. This is probably beyond the mandate of the learning exercise and tutorial. It also reduces the target audience considerably.

However, if one already knows PHP, then porting the server side component to PHP, using the concepts and techniques presented shouldn't be a problem. I'd suggest that those of you promoting a PHP or other server-side solution quit hijacking this topic.

If you are so adamant about the benefits of your solution then create a co-topic implementing your solution in place of the GM based solution, presented in this topic and eventual tutorial.

I have said many MANY times, you CANNOT have more than 1 packet on an electrical line between devices at the SAME TIME....I feel like I'm talking to myself for real.


So as not to further hijack this topic, I'll just refer you research broadband technologies. Broadband over glass, the air and copper certainly does allow more than one packet on the same medium, at the same time.
  • 0

keep_crap_150_zpsd7af69c5.png


#28 Yourself

Yourself

    The Ultimate Pronoun

  • GMC Elder
  • 7352 posts
  • Version:Unknown

Posted 04 September 2009 - 09:15 PM

but it also needs to teach them PHP


And nobody should have to learn PHP because it sucks.
  • 0

#29 BBGaming

BBGaming

    Programmer

  • GMC Member
  • 2478 posts
  • Version:GM7

Posted 04 September 2009 - 09:26 PM

but it also needs to teach them PHP


And nobody should have to learn PHP because it sucks.

As apposed to what alternative? ASP?

Edited by B&B_Gaming, 04 September 2009 - 09:32 PM.

  • 0

Posted Image
Game Widgets
- Your pure-GML solution to API DLLs. Featured in Markup Magazine!

My Portfolio - All my good games and resources
Moved away from the forum - e-mail me if you need quick contact (hi_146@hotmail.com).


#30 sabriath

sabriath

    12013

  • GMC Member
  • 3197 posts

Posted 04 September 2009 - 09:42 PM

but it also needs to teach them PHP


And nobody should have to learn PHP because it sucks.

As apposed to what alternative? ASP?

Actually, you can create your own server-side scripting in almost any language, if you're good enough. I made one in QB once, and vb2005. The QB one was very difficult, had to write the sockets in C++ and create a link manually in QB to use it, just as a challenge for myself to create somewhat of a "dll" for QB. Good times, good times. Anyhow, there are many server-sides other than making your own: PHP, ASP, CGI, CFM, JSP, Perl, SMX, Python, Ruby, Lasso, even Ansi-C.

{edit} 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).

Edited by sabriath, 04 September 2009 - 09:45 PM.

  • 0

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#31 Yourself

Yourself

    The Ultimate Pronoun

  • GMC Elder
  • 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
  • 3197 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

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#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
  • 1854 posts
  • Version:GM:Studio

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

gmc_signature.png


#37 sabriath

sabriath

    12013

  • GMC Member
  • 3197 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

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#38 Recreate

Recreate

    Furry

  • GMC Member
  • 2992 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

If the post that you are reading was created prior to 2011. For the safety of the general public, It is not to be regarded under any circumstances.
Please don't ask me to join your group at anything.


#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

book_forum.png


#43 xshortguy

xshortguy

    GMC Member

  • Global Moderators
  • 4353 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
Check out my Profile's About Me Page for some useful links.

#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
Enormous signature removed by moderator.

READ and follow the Signature Rules, or your account may be closed.

#45 Revel

Revel

    ɹǝqɯǝɯ ɔɯƃ

  • GMC Member
  • 4935 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