What changed
0 fixes1 addition0 changes0 removals
addedUpdate 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
Samphi changes
addedUpdate 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
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
