Update time. Day later than usual. Sorry about that! Things to show are still thin as the multiplayer job is just so massive, but I have made some visual progress on the server and implemented a big part of the core multiplayer protocol. I’ll try not bore you too much with low-level networking stuff, but since that’s all I’m doing right now it’s that or nothing! Here goes …
*Okay, so I’ve just written this and it got into much more depth that I had originally intended. For those into this stuff you might like it. For normal humans, you may want to just stop after the first section. :D
Let’s just start with the server client application itself. Here’s how it looks now:
As we can see it’s looking a lot better than what it did last time you saw it! Then it was just a green box! The buttons are hooked up and ready to do their thing, the background is in and the cursor and things are set. The next job is re-creating the console and handling input correctly.
This is obviously only for the graphical version of the server client, the one that will be hosted personally. There will also be a non-GUI version that will be used for hosting on remote machines, but I plan on not even starting that until the GUI version is complete. I’ll just strip all the graphics code out of it.
If I don’t get into the details I won’t have anything to show for a while! So, here’s a little bit of background on how Samphi multiplayer works. This may or may not be the best way to do this by the way! I’ve never coded a multiplayer server before, so this just the way it made sense for me. It worked in my previous test so I’m going with it again.
It’s actually pretty simple. Each time a player connected to the server performs an action that the other players need to know about, such as moves, places a block, or destroys a block, that action is recorded. Sending information across the internet is expensive, so that action is encoded into a small code.
For example, here’s a packet of information that the server might receive*:
*There loads of other information that packets carry, but this is the information I add and am interested in!
That looks like a random number but it actually contains a complete update with quite a bit of information. Let’s break it down:
1 – This is the id of the originating client. This is used so everyone knows where the update came from
4 – This is the type of command that has been received. There are different codes for connecting to the server, updating the terrain, updating the player etc. Each one is assigned a value so I know how to read the remaining information. In this case 4 means it was a terrain update!
3 – Since we know we’re working with a terrain update event, the next number is the ID of the block that was updated. In this case 3 mean sit was a dirt block.
1 – This next value determines if a block was placed or destroyed. A 1 means it was created.
16 – This is the x position of the block. Since our game world is a 32 * 32 grid however, this number is its actual position/32. This is to send less information. I’d rather a few CPU cycles to get this number back to its original value that increase packet size. This is due to being able to use a smaller data type with this method, but this article is already tech heavy without getting into data types and their sizes. :D
12 – This is the y position of the block in the same format as the x position.
SO! What this all means is that that simple number, 14311612, actually means the following:
“This packet came from client with id 1 and contains a terrain update. A dirt block was placed at position 512, 384.”
Our small number is much lighter to send than that big verbose description! That’s what’s happening under the hood in Samphi. Certain commands get turned into numbers like that and then sent off to the server.
With the packet now built it’s ready to be distributed to all other players to keep their worlds in sync. This process is simple. The packet is sent to the server, the packet type is checked, and if it’s something that all players need to know about it simply broadcasts it to all connected players. That means that each player connected to the server gets the packet sent to them, and then they can process that information.
I’ve just finished this ability to broadcast! Now a test client I’m building in GameMaker can connect to the server, it gets given its id correctly, sends a packet to the server, and that packet is broadcast to all other connected clients. That’s really the core of the server. Now it’s fleshing this out and hooking it backup to Samphi instead of this test application I’m working with. But things are going well!
The image above shows the test client writing a message to the console each time it receives a broadcast packet. This is working reliably with great speed so it’s looking good!
Well I know the next job is working on allowing the server client to read from files. The server needs to be able to load its configuration, read/write level data etc. so that’s the system that needs to be put in place next.
Hopefully this update wasn’t too boring. Most of what I’m doing right now I just writing code so there’s not much to show. Hopefully this little bit of an insight into the work I’m doing gives you all more of an idea as to the state of multiplayer currently.
Many thanks for reading and I’ll see you back here next week! Ciao!
As always you can show your support and keep up to date with development by following me here:
Visit my websites
▶ Greeny Games Website
▶ Samphi Website
Follow me on Twitter
▶ Greeny Games Twitter
▶ Samphi Twitter