The FAQ has several links to ways of thinking about this, including the "Gaffer" networked character physics article, the "Source" networking/lag compensation article, and the "Quake III" article by Brian Hook.

In general, if you let the player move ahead on the local client, you may end up with situations where, on machine 1, player 1 is first to a particular goal, but on machine 2, player 2 is first to a particular goal, and you'll have to figure out how to hide this discrepancy and let the server decide.

Ok I will look at the FAQ thank you, the first to a particular goal does not concern me so I suppose I should implement that.

Also, if you're trying to send the updates for 2,000 players, to 2,000 players, that will probably scale pretty poorly. It's important to design the game such that it doesn't generate n-squared interaction situations among all players.

Yes, I'm going to try design it so that each player has a (artificial) screen width of, say for example, (1920 + 200) × (1080 + 200), from the center of the player position (since this is a side scroller) therefore if there are any players outside of these bounds they will not receive any updates of the players that are outside of these bounds, in fact the client computer wont even know someone exists there. Of course though, if there are many people packed into one area there will be a problem you are talking about.

How well do you think this will scale? I honestly have no previous experience in this area.

Messages being sent/received will only be send/received when necessary, and even when messages do get sent (i.e. player used this ability) the server will only send a message size of 9 bytes! in total e.g.
2-byte ushort to indicate the message size
1-byte to represent the type of message (in this example using a ability)
4-byte player id so the receiving client knows who actually used the ability.
2-byte ushort to indicate the type of ability used
total: 9 bytes.

Say if 500 players are connected to one server, and each of the players are in the EXACT same area (which the possibility is extremely low anyway) id see the following:
1. 20 messages per second per client (assuming the maximum - this will probably be much smaller)
2. messages are 12 bytes in size (average - might even be smaller if I'm smart about it)
Results in 20 * 12 * 500 (all messages received from all clients) * 500 (messages relayed by the server back to client) which equals...
58593.75 kilobytes per second (upload and download) for the server.
but only 117.1875 kilobytes per second for each connected client.
Id say that gives me a happy face but I may be completely wrong in either my calculation or overestimating what is actually capable, but I feel strong this is extremely capable for hardware these days.

Another thing to note is that each client has a upload/download buffer of 131072 bytes (too large? i did this so the server can support full 65536 byte message sizes in the upload/download buffers without having to redo the download algorithm and prevent going over the buffer limit).

Do you have any bad thoughts on what I have mentioned?

Replies are appreciated, thanks.

I would expect a large chunk of users on the internet to not be able to reliably sustain receiving 117 kilobytes of payload data per second. I would aim at one-tenth of that, at most.

Also, experience with users shows that they *love* being where other users are. Clumping is, unfortunately, the normal behavior, rather than the uncommon behavior. Thus, game design affordances that can mitigate that would be important. Anything from limited-capacity buildings, to instanced fighting arenas, should be used where appropriate, to reduce number of users in any one single clump.

Finally, 58+ megabytes per second of payload means one gigabit per second of network bandwidth from your server -- it will *not* fit on a 100 Mbit Ethernet port. The cost of a 1 Gbit connection will run something like $4,000-$10,000 per month, depending on specifics. If your 500 players will each pay you $20 per month, that will pay for itself, but I have a sneaking suspicion they won't ;-)
(Then again, the online:offline ratio of players on any game is usually 10:1 or more -- but still, it's a real cost.)

2) Uses NoDelay TCP using .net Sockets (WinSock) therefore I am not using a network library.

I highly suggest you rework your packet-handling code to utilize UDP, as it is much, much, much. much, much. much, much faster (and should be used if programming anything that is meant to receive and send packets quickly).

4) Data is only sent when someone actually DOES something

Ehh... This is generally frowned upon, but if you can get away with doing it in your game; sweet!

Say if 500 players are connected to one server, and each of the players are in the EXACT same area (which the possibility is extremely low anyway) id see the following:
1. 20 messages per second per client (assuming the maximum - this will probably be much smaller)
2. messages are 12 bytes in size (average - might even be smaller if I'm smart about it)
Results in 20 * 12 * 500 (all messages received from all clients) * 500 (messages relayed by the server back to client) which equals...
58593.75 kilobytes per second (upload and download) for the server.
but only 117.1875 kilobytes per second for each connected client.
Id say that gives me a happy face but I may be completely wrong in either my calculation or overestimating what is actually capable, but I feel strong this is extremely capable for hardware these days.

Why do you multiply by 500 twice? If you think about it, this is what happens (at least, it should) when someone broadcasts a message to other players:
1) The packet to be sent to the server is composed like so:
00 - Packet-type : LEN = 1
01 - Absolute-length of data : LEN = 1
02 - Data (presumably text in this case) : LEN = 10

Let's pretend that you distinguish chat-packets with the byte 0x63 (99 numerically, and "c" for chat if interpreted as text). Now let's also go with the fact that you said the packet is 12 bytes long, that means the byte at position 01 in our packet will be readable as 10 (12 - (01+1)) by the server and connected clients, so that leaves us with 0x0a (which is numerical byte 10 in hexadecimal).

So far your packet will be:

63 0a __ __ __ __ __ __ __ __ __ __

Now you just replace the empty spaces with some text, I chose "ThisIsEasy" Now we have our packet of:

63 0a 54 68 69 73 49 73 45 61 73 79 <----- Actual packet
-------------------------------------------------
00 01 02 03 04 05 06 07 08 09 10 11 <----- Byte-position

By looking at the byte-position array just above; you can see that it's really just counting out a packet with a size of 12 bytes, yeah?

2) This packet is then sent to the server...
3) The server reads the first two bytes from the packet, which should be 99 (or "c" for chat) and 10 (the length of the data following the header, i.e. directly after the second byte).
4) (OPTIONAL) Since the packet is of the "c"-type (or 99); the server checks the data for inappropriate words, or perhaps admin-commands such as "/ban," etc[sup][1][/sup].
5) Since the packet is of the "c"-type (still 99), we know that it is a local area chat-packet; this means that the server then (at least, it should!) determines the area which the player is in, and sends the (optionally censored) packet out to all other players in the vicinity.
6) No additional processing is needed for this chat-packet, i.e; you're finished, and it's time to move onto the next packet in the queue[sup][2][/sup].

So according to your scenario; if twenty people sent these 12-byte length packets to the server, you will be receiving only 240 bytes. Your server will then know to dispense these chat-packets to the people in the area, and since there are 500: your server will only need to send out 240 * 500 bytes of information. That is 120,000 bytes, and only 117.1875 KB that must be sent out, so you really just multiplied by 500 an extra, unnecessary time

In addition, if you are extra perceptive you will notice that although there are 500 people in the area (which is absurd!), twenty of them are sending messages, and since they are creating the message they already know about it; which means that the server should not send their packet back to them, see it now? So the server only has to send out 240 * 480 bytes of data, or 112.5 KB, this isn't really to reduce the amount of data sent, but rather reduce the amount of processing-time by a very small fraction, as well as prevent them from receiving what they just said (which is pointless and annoying).

Side-notes:
1. If your game implements such administrator-commands; I would hope that you check if the player possesses necessary privileges before actually executing them.
2. The computer which you are hosting such a game on should be powerful enough to almost entirely (if not entirely) avoid having to place packets in a queue. Of course, if the server is programmed inefficiently (or for weaker systems); the way it handles things will be different. The way in which you implement your networking will also result in performance gain/loss.

The side-notes below are not directly attached to text above, so don't try to find them (they are, however; extremely important).

3. The chat-packet used in the example above does not contain the player name, as I reasoned the server should index players by their IPs and accordingly determine the name of the sender from that. You may wish to include the player-name, or other data in the packet, for simplicity, bloat, etc.
4. The scenario which you proposed does not seem very likely, as on very popular side-scroller MMORPGs (MapleStory, Dungeon-fighter Online, etc.) five-hundred players in one area is not a likely occurrence, and to have twenty of them sending messages within one second is also unlikely. This is mainly thanks to the implementation of multiple playable servers and channels (which further separate the servers, but can be played through entirely on one character, whereas that character cannot travel to a separate server).
5. Another option to reduce packet-size is to compress the data before sending it to the server, then decompress and process it there, when (if) sending the final packet out to other players; compress it before doing so. By compressing the string below:

"Hi, I like spamming in online games ;D LALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALALA ;D Happy!"

You could easily end up splitting the size of the needed packet in half, of course, with compression comes the need for a lot more processing (on both the user, and server-end), so you might only want to compress certain types of packets, or just avoid compressing them altogether.

In my opinion; I do not think packet-compression should be used, as transmitting a mere 112 KB per-second is no big deal, even with a 10 Megabit/sec (1.25 Megabyte/sec) upload speed. Popular and high-demand MMORPGs obviously go higher than that, but easily make their money back (plus more) with massive quantities of users.

I do believe that if you want to avoid hackers; it would be best to do a simple XOR over your packets (in case you didn't know; XOR = fast-as-hell), with a certain pattern determined at log-in/whenever.

Sure, id love to use UDP but all the data that is send/received NEEDS to be sent/received and not lost in the process. I don't understand the point of adding a reliability layer to UDP? May as well go for the optimized TCP solution instead like some other MMO's have done. Also I times by 500 again because I am retransmitting data received from all clients back to all clients (so 1 data received is sent to all other 500 clients in this example). If 500 clients are sending data to the server then 500 * 500 is going to be retransmitted back to all connected clients, does that make sence? if not maybe I have calculated wrong.

Spr33 could you please explain to me what XOR is? I heard preventing hackers is basically impossible (and thinking about it, I wouldn't argue against it either, anything is possible and quickly I understood this in a previous thread I made), the best you can do is by making the server check which messages are legit and which are not? That is why I am making the same server-based. Look at games such as LoL - no hackers at ALL and when there is something looking like a hack its just a exploit which can be hot-fixed.

hplus you are right they wont be paying monthly, and I wouldn't even want that sort of system in the first place.

Thinking deeply about this now, I was basically aiming for an indie 2D side-scroller MMO, I somewhat feel like I am completely overestimating myself but at the same time feel like this is completely viable as well, and the prototype I have developed is a example of that.

I seriously doubt 500 players will be in the same area at the same time. Not to mention that sending 20 messages per second seems like a overkill in my calculation as only data is sent when actions occur, I was just stating what the absolute maximum may be and if anything most connected clients in that area would be AFK doing nothing at all. Another thing is that not every type of message will be relayed back to all other clients (i.e. trading with another player does not need to be known by everyone).

Thank you for the replies and continued discussion, it really helps
Any further ideas/thoughts are appreciated,
Xanather.

I highly suggest you rework your packet-handling code to utilize UDP, as it is much, much, much. much, much. much, much faster (and should be used if programming anything that is meant to receive and send packets quickly).

I disagree. There is no *speed* difference between TCP and UDP. The only difference is that, with TCP, if packets are dropped, you have to wait for a re-send before other, received, packets can be delivered, because TCP guarantees in-order delivery.
UDP should be used when low receive latency is more important than ordering, which is the case for internet telephony, and *some* kinds of games.

4) Data is only sent when someone actually DOES something

Ehh... This is generally frowned upon
[/quote]

Generally frowned upon by whom, and why? Not sending data you don't have to send is generally approved by all network programmers I know.

Why do you multiply by 500 twice?
[/quote]

Because, as he said, he's broadcasting messages from 500 players, to 500 players. This is the basic n-squared growth of traffic that's the core of all MMO systems.

I do believe that if you want to avoid hackers; it would be best to do a simple XOR over your packets (in case you didn't know; XOR = fast-as-hell), with a certain pattern determined at log-in/whenever.
[/quote]

First, the speed of XOR scrambling versus a real cypher doesn't matter much. The available bandwidth on a computer limits how many bytes need to be encrypted per second, which in turn means that the overhead of the encryption is very small compared to available CPU power.

Second, scrambling with XOR instead of using a real cypher is a really bad idea. If your data needs encryption, you should encrypt it, not just cover it in the thinnest of layers of paint.

Third, you cannot really protect against hackers by encrypting your data anyway, because the hacker has full control of the client machine.

I would try to keep the amount of data you send out to less than 5kiB/s per connection. Many badly designed multiplayer games achieve that, well-designed games often run with 1/2 as much. 117kiB/s is insane, if for no other reason then because at a typical "average" home user internet speed of 2-3Mib/s it takes upwards of half a second to transmit this bulk (and, as hplus0603 pointed out, bandwidth is not free -- you do get a gigabit link for as little as 69€ additional setup in some places, but if you send out terabytes of data every month you will still need pay for that). Half a second of lag added "for nothing" is a lot.

About XOR-encryption as suggested by Spr33, this is OK for making the data stream look random to the casual eye, but no more. It doesn't cost significantly more to add a "real" encryption, any readily available well-known and tested implementation will do (which, again, probably doesn't perform much better because most likely you'll do the key exchange in an insecure manner (few people do this right), but still it's silly to try and economize on the encryption).

UDP is no viable alternative to TCP in "making stuff faster" here. UDP is "faster" because it sends independent datagrams without something like Nagle's algorithm and does not guarantee reliable in-order delivery. You've already disabled Nagle, so 90% of TCP's slowness is already gone. The problem here is that 117kiB have to go down the wire, and UDP still has to do that too. The actual speed is exactly the same.

Yes samoth I completely agree with you, my calculation was probably a overkill anyway. Just to say though, 99% of that 117kilobytes per second is download bandwidth while 1% is upload bandwidth. There is no way id make a client upload anywhere near 10kb/sec in any circumstances.

with samoth and hplus description of XOR it looks like XOR is a waste of time to implement tbh lol.

you do get a gigabit link for as little as 69€ additional setup in some places

Just to be clear: the $4k-$10k price range per month is for committed bandwidth -- you can use that gigabit 24/7 without paying additional pricing. That's over 300 terabytes per month of traffic. (You should compare this price to ISPs that charge a thousand bucks for a single terabyte of overage, and then realize that overages for ISPs are like overdraft fees for banks -- where lots of money is made!)
Any "set-up" costs are probably amortized over several years, and thus don't contribute significantly to the balance sheet (but still needs cash flow or financing, of course.)

I disagree. There is no *speed* difference between TCP and UDP. The only difference is that, with TCP, if packets are dropped, you have to wait for a re-send before other, received, packets can be delivered, because TCP guarantees in-order delivery.
UDP should be used when low receive latency is more important than ordering, which is the case for internet telephony, and *some* kinds of games.

From my personal tests; UDP can be a tiny bit faster, but as I said, it's not worth reworking if you favour your current implementation (for simplicity/whatever). Of course, after reading through the first bit of his post again, I've noticed that he's actually setting NoDelay to true, disabling Nagle, which really helps a great deal (personally; I have it disabled system-wide).

[quote name='Xanather' timestamp='1344139765' post='4966256']
4) Data is only sent when someone actually DOES something

Ehh... This is generally frowned upon
[/quote]

Generally frowned upon by whom, and why? Not sending data you don't have to send is generally approved by all network programmers I know.[/quote]I said this because I figured the game would follow typical MMORPG mechanics, was I incorrect in doing so? Is he not designing an MMORPG?

You see; in an MMORPG at least one of the things on the list below would be considered typical (but who am I to make such a statement?):
1) Health, mana, etc-regeneration: sending a small packet when this is meant to occur is a good idea, especially with varying rates of regeneration. This is not necessary, but otherwise the client and server will have to constantly keep track of the player's health on an elapsed-time basis, even while idling, and who's to say the client isn't modifying that value? Or skipping ahead/behind?[sup][1][/sup]
2) General client keep-alive, so that the server always knows whether or not to include players in the area-list after they disconnect. The alternative would be to check that every sent packet is received, but there would be an issue with that, considering the fact that "Data is only sent when someone actually DOES something." Consider the following scenario:
[color=#ffffff]___1. Bob logs in to the game and goes to "Map 1."
[color=#ffffff]___2. John logs in and goes to "Map 1," as well.
[color=#ffffff]___3. Bob's internet goes out, so he can't tell the server: "HEY! I've just left the game! Don't show me on the map!!!"
[color=#ffffff]___4. John will endlessly see Bob on the map, as he has not done anything[sup][2][/sup] and therefore; will not be updated.
[color=#ffffff]___(5.) John tries to talk to Bob, but he doesn't reply (since he is NOT online) D: John now hates Bob for ignoring him D:
3) Environments that the players can interact with are pretty much a given in MMORPGs. Will the monsters just drop movement if people idle in a certain area, because "Data is only sent when someone actually DOES something." According to what you are saying, I could do the following:
[color=#ffffff]___1. Go to some sort of unpopulated dungeon-map.
[color=#ffffff]___2. Fight my way through it, all the way up until the big-boss/whatever.
[color=#ffffff]___3. I then look at my clock; "Oh, it's lunch-time!" I say.
[color=#ffffff]___4. So I just stop pressing any keys, go totally idle, and leave for lunch.
[color=#ffffff]___5. I come back an hour later, start moving (which in turn, re-activates the boss, because I would be doing something) and kill that boss.
The system which you seem to be proposing can be compared to implementing a pause-button in an online-game! Such a "freeze-area-until-interaction" system would only be ideal for entirely turn-based environments.
4) Skills with cool-downs are commonly implemented to prevent users from spamming-skills and reaping the benefits from doing so. There are multiple ways of implementing such a cool-down system:
[color=#ffffff]___1. You could use an entirely client-sided cool-down system, which enables skills based on the amount of time elapsed since last using it. This is a horrible idea and would make any game susceptible to hackers, through either placing a JMP to the skill-reset address directly over the cool-down procedure, or hooking GetTickCount/timeGetTime/QueryPerformaceCounter and returning invalid time-values which would accelerate (either positive or negatively) the speed of anything based on the client-computer's time.
[color=#ffffff]___2. You could have fully server-sided cool-downs which are checked immediately as the skill is attempted, the server would then report the skill's availability back to the client. This method is brilliant for preventing hackers (though, not anymore than method 3), but it lacks compensation for lag which might be experienced by players with poor connections, as skill usage would require a send, then recv, and then, optionally; another sent-packet.
[color=#ffffff]___3. The server could send a small packet to the client anytime a certain skill became available after cool-down. Of course the client would also be measuring the cool-down based on the client-computer-time. allowing for lag-compensation and smooth gameplay. With the client also measuring and executing the skill, the server could do a check to ensure it has executed properly, if not a roll-back packet should be sent, and the player's position/status/etc. would be rolled-back to the proper time. This method only requires a single packet to be sent (Client --> Server) upon using a skill, though your current server-design (freeze-area-until-input), would rule this method out, because cool-downs should still be processed even while the player is idle.

Why do you multiply by 500 twice?

Because, as he said, he's broadcasting messages from 500 players, to 500 players. This is the basic n-squared growth of traffic that's the core of all MMO systems.[/quote]Haha, I apparently misread the original post, and thought that only 20 of the 500 players were broadcasting 12-byte chat messages, when, it is actually a rather different case.

I do believe that if you want to

avoid hackers; it would be best to do a simple XOR over your packets (in case you didn't know; XOR = fast-as-hell), with a certain pattern determined at log-in/whenever.

First, the speed of XOR scrambling versus a real cypher doesn't matter much. The available bandwidth on a computer limits how many bytes need to be encrypted per second, which in turn means that the overhead of the encryption is very small compared to available CPU power.

Second, scrambling with XOR instead of using a real cypher is a really bad idea. If your data needs encryption, you should encrypt it, not just cover it in the thinnest of layers of paint.

Third, you cannot really protect against hackers by encrypting your data anyway, because the hacker has full control of the client machine.
[/quote]You seem to believe I am not well-versed on the subject. I did not claim that XORing through the packets would provide some sort of magical, and unbreakable cypher-scheme. It will, however, make the packets appear meaningless to those peering in with packet-loggers/etc, especially if used with a random key. In order to prevent disassembly of the client-executable, I would use Themida, or another form of protection, and then top it with something similar to GameGuard/HackShield (which pretty much rule out the use of injectable packet-editors).

The main reason that I mentioned XORing, is because doing so is considerably fast (making it ideal for operating on a server), almost 116 times faster than a simple Rot13, and about 126 times faster than AES/Rijndael (using ten cycles and a 128-bit key)[sup][3][/sup].

Side-notes:
1. Generally; I wouldn't even go with this, as with a great deal of players it can become annoying having to iterate through a huge array of players, and send an update-health/etc-packet every x seconds. I would simply program the client to update HP/MP/Whatever according to time-passed on the client computer. The server would always hold the true values, which should be synchronized with the clients, therefore allowing it to make accurate calculation for skill-requirements, death, etc.
2. The character representing Bob literally will not be updated as a forced disconnection can be unpredictable, meaning that no logout-packet could possibly be sent. Since the server doesn't know that Bob is offline, it will assume that he is idle and nothing will happen with his character. Of course, the scenario proposed might not be accurate, since I do not know how your server handles errors, and it might just as well notice that Bob is offline due to him not receiving the packet which notifies his client of John appearing/speaking in his area. Regardless; if John weren't there to make Bob error-out (if such a thing were to occur as a result of John's actions) and be removed from the player-list, Bob would endlessly remain online, this might present a problem if he were to try and log-in after restoring his connection.
3. All tests were performed on a string of 64-bytes in length, with the elapsed-time being calculated using QueryPerformanceCounter. Using XOR-based encryption, I was able to encrypt the string 1,000,000 times in 13 milliseconds. It should be noted that the reason for me using ten cycles and a 128-bit key with AES, is because those are the minimum requirements for it to be classified as such.

Packets should only be sent when something happens that both sides need to know about. There is only one exception I can think of that, for 2).

1) Health regen does not need to be sent every update, as the client and server are both capable of figuring out what it should be based on what they know. The server should only sync this periodically when something happens to cause it to be different (i.e. getting attacked or healed).

2) The heartbeat should be the only packet transmitted without any event requirements. This solves the sudden logout problem, as if the server sends a heartbeat and doesn't get a response in say 15 seconds it considers the client DCed.

3) The server will transmit AI events to the players that it would be reasonable to (i.e. don't send it to player F that's 100 game-miles away). The AI is considered a "someone" for the purposes of packet transmission. Anyone who has done any kind of online game work (and even intelligent people who haven't) should know this.

4) For cooldowns, option 3 is probably the best, and I'll give you this one on not being obvious.

For a MMO, there's no reason to send everyone the entire game state every frame. There's not even a reason to send them their own entire state every frame. The client should only be notified of changes to the game state that it can't figure out on it's own. Don't send the AI's position every frame. Send a path that the AI will take, and let the client figure out where on the path the AI is. If the client hacks the game so that the AI is "rooted" in a specific place on their client, it doesn't matter because the server says the AI's here, not there. At worst, the server just has to sync the occasional object every now and then.

1) Health regen does not need to be sent every update, as the client and server are both capable of figuring out what it should be based on what they know. The server should only sync this periodically when something happens to cause it to be different (i.e. getting attacked or healed).

Did you read the side-notes? I pretty much covered the health regeneration part down there, saying that it would only need to be updated by the server when necessary (when damaged to check for death, or upon skill usage to check for sufficient MP)... In fact; the main reason I brought up having health solely updated via packet from the server is because he seems to be stressing on security, for this specific game.

In case you've mistaken what I said in the side-note; when I say that HP/MP/Etc. "should be synchronized with the client," I mean that the client and server should increment the player's HP at the same rate, I didn't mean to imply that it was a good idea for the server to constantly send the player's HP value, as that would be ridiculously unnecessary (the whole purpose of the side-note was to make a statement going against what #1 said!).

2) The heartbeat should be the only packet transmitted without any event requirements. This solves the sudden logout problem, as if the server sends a heartbeat and doesn't get a response in say 15 seconds it considers the client DCed.

That's a given, I was just picking out the flaws in his system based on exactly what he has said, so I had to bring that up

3) The server will transmit AI events to the players that it would be reasonable to (i.e. don't send it to player F that's 100 game-miles away). The AI is considered a "someone" for the purposes of packet transmission. Anyone who has done any kind of online game work (and even intelligent people who haven't) should know this.

I am perfectly aware of the applications of AI in online games, though I think you should read over exactly what he said, perhaps then you might see why I'm picking on this little detail (again, I am taking what he said literally).

4) For cooldowns, option 3 is probably the best, and I'll give you this one on not being obvious.

That's exactly what I was getting at. Too bad it won't entirely work with his server, as it doesn't seem to have a scheduler D:

For a MMO, there's no reason to send everyone the entire game state every frame. There's not even a reason to send them their own entire state every frame. The client should only be notified of changes to the game state that it can't figure out on it's own. Don't send the AI's position every frame. Send a path that the AI will take, and let the client figure out where on the path the AI is. If the client hacks the game so that the AI is "rooted" in a specific place on their client, it doesn't matter because the server says the AI's here, not there. At worst, the server just has to sync the occasional object every now and then.

You really haven't told me anything new here. Honestly, a client with an intelligently designed path-finding system would only require x, y(, z) coordinates to be sent, the generated path should obviously match the one generated by the server, but this shouldn't be an issue since the sources would be the same.

Of course, just sending the coordinates would be solely for the purpose of cutting back on packet-size, the server would still have to generate the NPCs path (storing the sort-of movement-history, which should match what the client will generate, in an array).

3) Environments that the players can interact with are pretty much a given in MMORPGs. Will the monsters just drop movement if people idle in a certain area, because "Data is only sent when someone actually DOES something." According to what you are saying, I could do the following:
[color=#ffffff]___1. Go to some sort of unpopulated dungeon-map.
[color=#ffffff]___2. Fight my way through it, all the way up until the big-boss/whatever.
[color=#ffffff]___3. I then look at my clock; "Oh, it's lunch-time!" I say.
[color=#ffffff]___4. So I just stop pressing any keys, go totally idle, and leave for lunch.
[color=#ffffff]___5. I come back an hour later, start moving (which in turn, re-activates the boss, because I would be doing something) and kill that boss.

Sorry I was supposed to say client data is sent to the server only when the client does something, my bad. I do completely understand what u are saying though xD, no way id implement that

[quote name='Spr33' timestamp='1344451349' post='4967478']
3) Environments that the players can interact with are pretty much a given in MMORPGs. Will the monsters just drop movement if people idle in a certain area, because "Data is only sent when someone actually DOES something." According to what you are saying, I could do the following:
[color=#ffffff]___1. Go to some sort of unpopulated dungeon-map.
[color=#ffffff]___2. Fight my way through it, all the way up until the big-boss/whatever.
[color=#ffffff]___3. I then look at my clock; "Oh, it's lunch-time!" I say.
[color=#ffffff]___4. So I just stop pressing any keys, go totally idle, and leave for lunch.
[color=#ffffff]___5. I come back an hour later, start moving (which in turn, re-activates the boss, because I would be doing something) and kill that boss.

Sorry I was supposed to say client data is sent to the server only when the client does something, my bad. I do completely understand what u are saying though xD, no way id implement that
[/quote]

Presumably, the boss himself would also be "someone" (as in "an actor that can affect game state") and would send messages when he finds the player and starts attacking.

Did you read the side-notes? I pretty much covered the health regeneration part down there, saying that it would only need to be updated by the server when necessary (when damaged to check for death, or upon skill usage to check for sufficient MP)... In fact; the main reason I brought up having health solely updated via packet from the server is because he seems to be stressing on security, for this specific game.

In case you've mistaken what I said in the side-note; when I say that HP/MP/Etc. "should be synchronized with the client," I mean that the client and server should increment the player's HP at the same rate, I didn't mean to imply that it was a good idea for the server to constantly send the player's HP value, as that would be ridiculously unnecessary (the whole purpose of the side-note was to make a statement going against what #1 said!).

There were side notes? Why are there side notes? Why do they directly conflict with what you said? If you want to say something, don't confuse people by saying something and then later on going "oh by the way that one thing yeah I meant the exact opposite."

That's a given, I was just picking out the flaws in his system based on exactly what he has said, so I had to bring that up

So you're being a pedantic dickweed?

I am perfectly aware of the applications of AI in online games, though I think you should read over exactly what he said, perhaps then you might see why I'm picking on this little detail (again, I am taking what he said literally).

More pedantic dickweedery. All that's needed to be said is "don't forget to treat the AI as a somebody."

That's exactly what I was getting at. Too bad it won't entirely work with his server, as it doesn't seem to have a scheduler D:

Why does it need a scheduler? And even then, why are you assuming he doesn't have one? Just store that the user started the cooldown for ability X at time T, and that it will last for Y seconds. When the user tries to use ability X again, the server checks the player's cooldowns for ability X, and if the current time is >= T+Y let the user do it. If not, send that the user still has Z cooldown remaining for that ability. Ideally it would remove expired cooldowns every now and then as well to cut down on the data to search through.

You really haven't told me anything new here. Honestly, a client with an intelligently designed path-finding system would only require x, y(, z) coordinates to be sent, the generated path should obviously match the one generated by the server, but this shouldn't be an issue since the sources would be the same.

Of course, just sending the coordinates would be solely for the purpose of cutting back on packet-size, the server would still have to generate the NPCs path (storing the sort-of movement-history, which should match what the client will generate, in an array).

Of course. This is what I was trying to say. I was thinking non-lockstep for sending the whole path, but since the client state and server state should be the same just sending the final destination should be enough.

I think you could have been much more clear with your communication by leaving out all of the little jabs and just getting to the point. Humor is okay but must be used to supplant the point being made, not obscure it. I will say that this thread is good for me because it's making me think how to implement my own multiplayer system, albeit not MMO (While there will only be 4 players in a match in the current iteration of the game, I want to stuff as many matches as possible onto a server and possibly allow people to watch a match, so I need to keep in mind some of the same optimization techniques).

[quote name='Spr33' timestamp='1344451349' post='4967478']
3) Environments that the players can interact with are pretty much a given in MMORPGs. Will the monsters just drop movement if people idle in a certain area, because "Data is only sent when someone actually DOES something." According to what you are saying, I could do the following:
[color=#ffffff]___1. Go to some sort of unpopulated dungeon-map.
[color=#ffffff]___2. Fight my way through it, all the way up until the big-boss/whatever.
[color=#ffffff]___3. I then look at my clock; "Oh, it's lunch-time!" I say.
[color=#ffffff]___4. So I just stop pressing any keys, go totally idle, and leave for lunch.
[color=#ffffff]___5. I come back an hour later, start moving (which in turn, re-activates the boss, because I would be doing something) and kill that boss.

Sorry I was supposed to say client data is sent to the server only when the client does something, my bad. I do completely understand what u are saying though xD, no way id implement that
[/quote]That makes a lot more sense I just think it would suck if you designed the entire system around what I assumed you were talking about, but then had to rework some of it since certain things wouldn't be possible.

There were side notes? Why are there side notes? Why do they directly conflict with what you said? If you want to say something, don't confuse people by saying something and then later on going "oh by the way that one thing yeah I meant the exact opposite."

The main reason I suggested the HP-regeneration-packet was because some try-to-be-secure games go that route, and I thought it fit his needs as he does want to make the game rather secure. I added the side-note so I could express my opinion on the fact, saying that I personally wouldn't do that, but it's totally fine. The other side-notes didn't really contradict anything I had said before, and were used to confirm tests/scenarios, without embedding them into the body of the post.

So you're being a pedantic dickweed?
...
More pedantic dickweedery. All that's needed to be said is "don't forget to treat the AI as a somebody."

It wasn't my intention to be a "dickweed," I was simply stressing on the fact that what he had literally stated would make many things, which are typical in an MMO; quite impossible (or perhaps, difficult to implement).

I think you could have been much more clear with your communication by leaving out all of the little jabs and just getting to the point. Humor is okay but must be used to supplant the point being made, not obscure it.

That is true, but in the end, my main point was made.

Reading through the replies I was wondering if this sounds possible:
If I were to make health-regeneration a message that is only sent once and contains:
1) the current value of the health
2) the regenerating value
How accurate would the values on each other computers be in the foreseeable future? Won't they go off track a little?