Server Processing
We must now configure our server to listen for, receive, and process messages from the clients.
First, create a new object called obj_player.
Create a sprite, a basic circle will do, and assign this sprite to obj_player.
Add the following code to the Step event of obj_player:
Every instance of obj_player runs the above code each Step, checking if their connection is still active, and checking for new messages on their individual socket. If a new message is received, User_Event(0) is executed.
Running User_Event(0) is very important. Within this event, the object determines what the message it received is to be used for, so it can execute the appropriate script.
If no message is received, a negative value is returned and the scripts exits. If the value 0 is returned, the connection has been broken, so the socket is closed and the instance is destroyed.
You should actually be able to run your server, and then run your client, and be able to see the connection now. If you assigned a sprite to obj_player then you should see it created when the client tries to connect. You'll know if the client successfully connected because it won't display the message box asking you to retry the connection.
You can download the full example with some minor additions fit for testing on our downloads page.
Next we'll set up the packet handling.
Running User_Event(0) is very important. Within this event, the object determines what the message it received is to be used for, so it can execute the appropriate script.
If no message is received, a negative value is returned and the scripts exits. If the value 0 is returned, the connection has been broken, so the socket is closed and the instance is destroyed.
You should actually be able to run your server, and then run your client, and be able to see the connection now. If you assigned a sprite to obj_player then you should see it created when the client tries to connect. You'll know if the client successfully connected because it won't display the message box asking you to retry the connection.
You can download the full example with some minor additions fit for testing on our downloads page.
Next we'll set up the packet handling.
Place the following code into User_Event(0):
This code is a little difficult to explain without an understanding of packets. Previously mentioned in our Quick Glossary, packets are the messages which your clients and server send to each other.
A packet, for example, might contain this information for a simple chat message:
[IP, port, protocol information]
CHAT - Unique identifier
"This is my message" - The chat message
A movement packet might look like this:
[IP, port, protocol information]
MOVE - Unique identifier
1024 - X coordinate
512 - Y coordinate
5 - Horizontal speed
0 - Vertical speed
When the server receives a packet, it has already handled the [IP, port, protocol information] section. However, it then needs to know what each individual packet does. To handle this, whenever you write a packet, you must include a unique identifier. In the above examples, this was CHAT for the chat message, and MOVE for the movement message. The unique identifier should be a byte, which is 1 byte of data, allowing a value from 0 to 255, however we have used constants so that these values can be represented as words. Refer to the GM help files for information of constants.
To read sections of a packet, you can use the read functions which are part of 39dll. These will be explained in more detail later. We use the function readbyte() since the unique identifier of a packet is a byte.
The code above performs a switch on the first byte of the packet, the unique identifier. The switch checks the possible cases and if it finds a match, executes the actions under it. We have created an example of this for case EXAMPLE, in the event that EXAMPLE was a unique identifier. If that was the byte read, then scr_case_example() would be executed.
The server processed all receives messages/packets like this. The client does so in much the same way.
A packet, for example, might contain this information for a simple chat message:
[IP, port, protocol information]
CHAT - Unique identifier
"This is my message" - The chat message
A movement packet might look like this:
[IP, port, protocol information]
MOVE - Unique identifier
1024 - X coordinate
512 - Y coordinate
5 - Horizontal speed
0 - Vertical speed
When the server receives a packet, it has already handled the [IP, port, protocol information] section. However, it then needs to know what each individual packet does. To handle this, whenever you write a packet, you must include a unique identifier. In the above examples, this was CHAT for the chat message, and MOVE for the movement message. The unique identifier should be a byte, which is 1 byte of data, allowing a value from 0 to 255, however we have used constants so that these values can be represented as words. Refer to the GM help files for information of constants.
To read sections of a packet, you can use the read functions which are part of 39dll. These will be explained in more detail later. We use the function readbyte() since the unique identifier of a packet is a byte.
The code above performs a switch on the first byte of the packet, the unique identifier. The switch checks the possible cases and if it finds a match, executes the actions under it. We have created an example of this for case EXAMPLE, in the event that EXAMPLE was a unique identifier. If that was the byte read, then scr_case_example() would be executed.
The server processed all receives messages/packets like this. The client does so in much the same way.
 |
 |
How To Make An MMORPG © 2010-2012
Copyright | Privacy Policy
