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
|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.