Top Mud Sites Forum - View Single Post

meae · 10-09-2013, 06:30 AM

Wow, didn't expect to start such a lengthy discussion, but I'd be happy to contribute.. from the outset, I've been taking notes on developing both applications. I knew a little bit from reading development guides but mostly I've been banging my head into my keyboard.

Position updates taught me the most major lessons.

First, detecting when a client has tried to move out of bounds in a 2d plane without any obstacles is trivial. Accounting for solid objects on the terrain, and a third coordinate? Not so much.

Second, client software loops very quickly. Many hundreds or even thousands of times per second. Attuning the rate of motion to prevent rubberbanding is a challenge all to itself, and with the client looping that often, you need a substantial amount of packet updates to see entities other than those your client is positioning move smoothly. This amounts to about 15 position updates per second for my client, which also uses prediction to account for momentum. Another 5 are used to provide minimal state information on things that can be affected, like mobs. At the moment, that includes everything that moves.

-This raises even more sub-problems of its own. In the textual version, I didn't have to send everyone a mass of packets every second. In the graphical version I'm having to be far more specific when designing objects, to avoid bandwidth waste, and shorten data in general, since n20 space separated strings per second per player is a gigantic cost.

That's not to say its been all difficult, though. Learning to code for the mud client standards was a serious pain in the ass. Detecting client types, disabling or enabling feature sets, and applying compatibility filters is a lot of work. On top of this, analyzing input was extremely tedious, having to account for many variations of commands and document all of it.
Having control over the client's side of things doesn't mean i can discount the golden rule (never trust the client), but it means i can make a lot more assumptions about the structure of input data and state of the client, and don't have to provide verbose error messages to the client when something is improperly formatted.

I'm having fun expanding my horizons, and though much of the functionality and story are changed, it's infinitely entertaining either way to try and build your own little world from scratch.

10-09-2013, 06:30 AM	#24
meae New Member Join Date: Jul 2013 Posts: 8	Re: Hi, hey, hello Wow, didn't expect to start such a lengthy discussion, but I'd be happy to contribute.. from the outset, I've been taking notes on developing both applications. I knew a little bit from reading development guides but mostly I've been banging my head into my keyboard. Position updates taught me the most major lessons. First, detecting when a client has tried to move out of bounds in a 2d plane without any obstacles is trivial. Accounting for solid objects on the terrain, and a third coordinate? Not so much. Second, client software loops very quickly. Many hundreds or even thousands of times per second. Attuning the rate of motion to prevent rubberbanding is a challenge all to itself, and with the client looping that often, you need a substantial amount of packet updates to see entities other than those your client is positioning move smoothly. This amounts to about 15 position updates per second for my client, which also uses prediction to account for momentum. Another 5 are used to provide minimal state information on things that can be affected, like mobs. At the moment, that includes everything that moves. -This raises even more sub-problems of its own. In the textual version, I didn't have to send everyone a mass of packets every second. In the graphical version I'm having to be far more specific when designing objects, to avoid bandwidth waste, and shorten data in general, since n20 space separated strings per second per player is a gigantic cost. That's not to say its been all difficult, though. Learning to code for the mud client standards was a serious pain in the ass. Detecting client types, disabling or enabling feature sets, and applying compatibility filters is a lot of work. On top of this, analyzing input was extremely tedious, having to account for many variations of commands and document all of it. Having control over the client's side of things doesn't mean i can discount the golden rule (never trust the client), but it means i can make a lot more assumptions about the structure of input data and state of the client, and don't have to provide verbose error messages to the client when something is improperly formatted. I'm having fun expanding my horizons, and though much of the functionality and story are changed, it's infinitely entertaining either way to try and build your own little world from scratch.