aidancheddar
Active Member
Which, I just made a thread about that like not too long ago: anyone can contribute, so quit dictating the developers, bigl2369 or anyone else. Suggestions are welcome, if you can't code.
I hope this project works out well.
- Thread starter bigl2369
- Start date
Even sending deltas of the last gamestate will be very intensive. The idea is that without any user intervention, all the simulators will run in exactly the same way on all systems, so we will only need to sync these interventions when they happen, like events.
For example, when a client chooses to "sit" on a chair, the server is notified that this interaction has been called. This is then scheduled to send to all clients - scheduled on a specific future frame so that this user interaction will happen at the same time on all simulators, therefore the initial state will be the same so the interaction and its aftermath should play out exactly the same way on all clients. Random numbers have been set up to be deterministic, so that will work correctly too.
bigl2369
Member
I don't think that's how it works. Your implying that the client has to be told to do everything. I think its a common misconception that clients simulate whats on the server. The client is actually playing on the server. What you see on your screen is exactly the same thing that is on the server. There is about fifty milliseconds of lag.
The data stream makes it so the client and server code communicate. The server communicates with a database too. Theres more to client server connections than data streams though. Theres a lot of things that make it so games can be played online in multiplayer.
The data stream makes it so the client and server code communicate. The server communicates with a database too. Theres more to client server connections than data streams though. Theres a lot of things that make it so games can be played online in multiplayer.
Well... you have any valid source for confirming what you say is true and to prove it ?...
or do you just say a lot of shit without even knowing of what are you talking about ?...
aidancheddar
Active Member
Last edited:
You don't seem to understand. The clients have individual simulations, eg Lot VMs, eg game states, eg what is directly displayed on the clients' screens that are synced with the master state on the server. Each client requests changes to this master state from them, and all clients are updated accordingly with these changes once they are verified. There is no magic switch to make things run on the same game state.
These game states can also be loosely linked, eg. all of the physics simulation for your car in a racing game is done on your system and just your position is uploaded. We cannot do this for syncing an intricate virtual machine which relies on correct order of execution.
Way to state the obvious! One of those things also includes actually knowing what you're talking about.
I'm not even sure what to say... You might make a better case for yourself if you didn't do things like this.
bigl2369
Member
Physics is a combination of matter, geometry, and math. The physics is all very realistic and done on the server. If anything else was the case it would be impossible for you to play a match of halo or call of duty. There aren't any physics in the sims games but that doesn't mean that groundwork for any game engine doesn't rely on it. Computers are very scientific and they are governed by many different forces.
Your making it seem like computers can't do what they can do. And that is deliver a streaming multiplayer experience. Once again multiplayer streaming is more than just data streams. And I think streaming and your use of the word syncing are two very different things. Can we agree to disagree that there would be no reason to "sync" a "simulation" on the "client" to the "server" if you could "stream" at a speed no slower than 50 ms?
The client doesn't need a variable generated by the server to tell it what to do. Think about it. Does the server need to generate a position variable to tell itself what to do? I don't think so. Variables are important for adding gameplay. I have found no evidence suggesting that my players position needs to be updated with a variable.
Furthermore animation and physics is what makes a character move around the screen. And there is no reason for the physics and animation on your screen to be any different from that of which is on everyones screen.
Your making it seem like computers can't do what they can do. And that is deliver a streaming multiplayer experience. Once again multiplayer streaming is more than just data streams. And I think streaming and your use of the word syncing are two very different things. Can we agree to disagree that there would be no reason to "sync" a "simulation" on the "client" to the "server" if you could "stream" at a speed no slower than 50 ms?
The client doesn't need a variable generated by the server to tell it what to do. Think about it. Does the server need to generate a position variable to tell itself what to do? I don't think so. Variables are important for adding gameplay. I have found no evidence suggesting that my players position needs to be updated with a variable.
Furthermore animation and physics is what makes a character move around the screen. And there is no reason for the physics and animation on your screen to be any different from that of which is on everyones screen.
Last edited:
aidancheddar
Active Member
Lemme ask you a question. Are you a programmer? Can you back up your claims? Can you provide sample code?
This is coming from the person who called us faggots.
Correct. Although when we use floating point math, computers are not quite as procedural because they do not generate the same output consistently on different hardware.
The questions are:
- Should we ensure that all clients simulate all of the lot's player inputs at the correct times (which implies in the correct orders)? Perhaps we should do what TSO did (regardless if it's the best choice), and Rhys's guess and my own guess is that TSO did this. If so, then we have to answer two more questions:
- (1) How much does spurious pausing->fast-forwarding to the current time, or rewinding->resimulating->fast-forwarding to the current time, bother the player?
- (2) How much does latency bother the player?
Imagine that a client submits the player's action to the server, and the server tells all connected clients that "in 1000ms from now, Player A will perform this action". 1000ms is fairly generous, so most of the time (all of the time for long stretches of the time), all of the clients will always receive the message in time and never have to wonder "what do I do? what do I do?" with the players' inputs.
A 1000ms latency means there will *always* be a (1000 + single-trip-client-to-server-latency) ms latency between the time a player clicks to perform an action and the time the sim actually begins the action on anyone's computer.
We can reduce the latency, but we will increase the probability that a client will miss some input messages from the server by the deadline. When that happens, the client has to either make a guess (the guess is almost always "Nobody has performed an action" in this game) or pause the simulation entirely until it receives the message from the server. Once the message arrives, if the guess that the client made was correct, then the client doesn't have to do anything. But if the guess that the client made was wrong, it has to rewind the simulation, apply the change, and fast-forward back to the current time; this will appear to the player as a stutter on the screen unless we can interpolate and subtly alter the speed of the simulation (or whatever else works) to manage it unnoticeably. If the client made no guess and decided to wait for the server's message to arrive, it will also appear as a stutter on the screen unless we manage it through the same techniques.
It is possible for the latency to be 0. In that case we are just always guessing "There is no player input", and rewinding->resimulating->fast-forwarding once any player on the lot makes an input.
So I'm glad that you brought this issue up, bigl2369. (Even if your question was just "Why can't we just do this: ___?")
Last edited:
bigl2369
Member
Computers aren't as procedural when they use floating point math because of hardware. What does that even mean? As long as you have a 400 dollar computer with a good install, then your golden. Define procedural. And what do floating decimals have to do with a computers performance?
I assure you everyone was enjoying a streaming multiplayer experience in TSO, because there were no stutters.
Your theory is this: You want the client to tell the server it performed an action. I'm assuming you want the server to save a list of everything that happens. You want the server to perform the action 1000ms later. Then you want to tell all the clients they need to sync up to the server every time something happens. And you said that the client will be checking to see if it messed up every so often.
When did you come up with the idea that multiplayer games do this? Why do you like this idea?
I assure you everyone was enjoying a streaming multiplayer experience in TSO, because there were no stutters.
Your theory is this: You want the client to tell the server it performed an action. I'm assuming you want the server to save a list of everything that happens. You want the server to perform the action 1000ms later. Then you want to tell all the clients they need to sync up to the server every time something happens. And you said that the client will be checking to see if it messed up every so often.
When did you come up with the idea that multiplayer games do this? Why do you like this idea?
Last edited:
bigl2369
Member
I'm no expert and I've never made a game myself but my understanding is this: The clients takes player input. The server executes the input. Everyone sees whats happening on the server. The server makes a database of things that happen involving inventory, money, experience etc. When he logs out or gets disconnected the database gets a player position.
Last edited:
Streaming multiplayer solutions work by streaming all sensitive data that has changed since the last "tick". For TSO, here's a taste of what that would be:
http://simantics.wikidot.com/wiki:object-data
Each object has 80 2 byte data fields for various properties in the object, as well as simantics state. On the average lot, there are 150 of these objects. Many objects use idle loops to perform operations even when they are not involved in an interaction, so just for object data the size per tick is:
150 * 80 * 2
24,000 bytes (not even counting vm thread information!!)
This game ran on a dial up modem, so that surely is too much:
56kbps = 7 KB/s = 7000 bytes per second
I don't remember the lot only squeezing out an update every 4 seconds, so this can't be right at all. Not to mention that with a solution like this, if both systems ran asynchronously until this point and someone else started using an object at second 1, they've already moved a good distance by second 4, so they will be "teleported" there and certain other actions in progress could even be altered as well. Say for instance that the object a sim uses generates a random number. Because you have attempted to use an object, the random number seed has changed and the sim gets the jackpot on your system. But on their system, they get rolled a bad number! Who is right? Either way it will need to be hastily corrected for all clients and at least one of them will be confused.
With an input synced solution, we only have to send a short description of any player actions performed since the last server tick. These will be less than 50 bytes always (we need obj id, interaction number and maybe a few more things), and does not scale with the number of objects on the lot. There will be no stuttering with this solution, only a small input delay not noticable with a game like TSO. Please try out PJ64K or Dolphin Netplay to see how reliable this is in action. Keep in mind that split screen games like those you play online with these netplay emulators have been designed to assume that all information on the other players and the game state is 100% correct, on the same system and that both players are using the same system.
http://simantics.wikidot.com/wiki:object-data
Each object has 80 2 byte data fields for various properties in the object, as well as simantics state. On the average lot, there are 150 of these objects. Many objects use idle loops to perform operations even when they are not involved in an interaction, so just for object data the size per tick is:
150 * 80 * 2
24,000 bytes (not even counting vm thread information!!)
This game ran on a dial up modem, so that surely is too much:
56kbps = 7 KB/s = 7000 bytes per second
I don't remember the lot only squeezing out an update every 4 seconds, so this can't be right at all. Not to mention that with a solution like this, if both systems ran asynchronously until this point and someone else started using an object at second 1, they've already moved a good distance by second 4, so they will be "teleported" there and certain other actions in progress could even be altered as well. Say for instance that the object a sim uses generates a random number. Because you have attempted to use an object, the random number seed has changed and the sim gets the jackpot on your system. But on their system, they get rolled a bad number! Who is right? Either way it will need to be hastily corrected for all clients and at least one of them will be confused.
With an input synced solution, we only have to send a short description of any player actions performed since the last server tick. These will be less than 50 bytes always (we need obj id, interaction number and maybe a few more things), and does not scale with the number of objects on the lot. There will be no stuttering with this solution, only a small input delay not noticable with a game like TSO. Please try out PJ64K or Dolphin Netplay to see how reliable this is in action. Keep in mind that split screen games like those you play online with these netplay emulators have been designed to assume that all information on the other players and the game state is 100% correct, on the same system and that both players are using the same system.
bigl2369
Member
I suppose it is possible that there are various ways for servers to sync a streaming multiplayer experience with all of their clients. When people start talking about ticks and bytes and workload it doesn't make sense to me.
I barely even have a concept of how games are made. Theres physics, rigging, and scripting that I will never be smart enough to understand, but may someday still be able to implement.
I've never tried to emulate a server. I've never tried to build my own game and run it on a server. Theres still a lot I have to learn before I can create a game. Whether it be single player, tcp/ip, or server based.
I want to learn more graphic design techniques, html, and scripting.
I also know how to produce music.
I barely even have a concept of how games are made. Theres physics, rigging, and scripting that I will never be smart enough to understand, but may someday still be able to implement.
I've never tried to emulate a server. I've never tried to build my own game and run it on a server. Theres still a lot I have to learn before I can create a game. Whether it be single player, tcp/ip, or server based.
I want to learn more graphic design techniques, html, and scripting.
I also know how to produce music.
Last edited:
If you never tried to build a game or anything, what was the point of this discussion anyway?
aidancheddar
Active Member
That just nullified most
Now, as consequence for my lack of networking knowledge, I am a bit short cited on what could be useful question to answer. I will admit that . Since Fatbag mentioned that you brought up a good question on something. So, you may have something. But, just blabbering out actions that we should be doing, not to mention expressing knowledge over something you don't have a full understanding of, then call us the faggots for questioning your knowledge, not to mention authority, is just plain childish.
Last edited:
It was only a good question because it warrants an interesting explanation why we can't do it any other way.
I don't like what this is trying to imply. We coded our entire engine from scratch, including the UI, entire Simantics + HIT Virtual Machines and resource providers. Nobody else has ever done anything like this for TS1/TSO.
If you haven't made a game yourself and barely have a concept of how a game is made, why did you bother arguing with us over how it should work?
For this situation I have only three words to say, f*ck the logic... ._.
bigl2369 is still wondering: what if the server streams just the *essential* information about what's going on on the lot (the positions/rotations, animations, and current positions within the animations of all the players, the playing sounds, and the current sprite animations) to the client, without the client performing the SimAntics simulation itself? Then we would be answering no to the above question, "Should we ensure that all clients simulate all of the lot's player inputs at the correct times (which implies in the correct orders)? Perhaps we should do what TSO did (regardless if it's the best choice), and Rhys's guess and my own guess is that TSO did this."
It would be pretty damn weird to be actually seeing all of the SimAntics code in TSO's objectdata folder, then, since TSO is just the client... And it's not just the The Sims 1 objects that have the SimAntics code, but the TSO objects too like the pizzamaker. So that's why we don't think that's what TSO did. But it *can* work, and it will then work more like most online games today.
The latency between when a client makes an action and the action is accepted into the common simulation will then be simply the client->server latency (ping/2), the latency between when the server simulates the next tick and a client receives it will be the server->client latency (also ping/2), and the resulting "average framerate" that the client gets will be the average latency between two consecutive simulation ticks (or tick bursts) received from the server. But if the connection drops out for 1/5 of a second (which will be happening often), then the simulation frames will be dropped for 1/5 of a second, which you'll see as a stutter, unless you either buffer up simulation data for >= 1/5 of a second all of the time, which will increase server->client latency by that amount, or guess and interpolate when you're wrong
In my opinion, the best option is to interpolate with a 100ms latency. Sometimes we will miss information from the server (either simulation data or player input data) by the 100ms deadline, so we make a prediction about what the server will send next, and when we're wrong, we can interpolate between the wrong and the right values over the course of a few seconds.
I don't know why we're *arguing* about this. Why can't we just *evaluate* this?
It would be pretty damn weird to be actually seeing all of the SimAntics code in TSO's objectdata folder, then, since TSO is just the client... And it's not just the The Sims 1 objects that have the SimAntics code, but the TSO objects too like the pizzamaker. So that's why we don't think that's what TSO did. But it *can* work, and it will then work more like most online games today.
The latency between when a client makes an action and the action is accepted into the common simulation will then be simply the client->server latency (ping/2), the latency between when the server simulates the next tick and a client receives it will be the server->client latency (also ping/2), and the resulting "average framerate" that the client gets will be the average latency between two consecutive simulation ticks (or tick bursts) received from the server. But if the connection drops out for 1/5 of a second (which will be happening often), then the simulation frames will be dropped for 1/5 of a second, which you'll see as a stutter, unless you either buffer up simulation data for >= 1/5 of a second all of the time, which will increase server->client latency by that amount, or guess and interpolate when you're wrong
In my opinion, the best option is to interpolate with a 100ms latency. Sometimes we will miss information from the server (either simulation data or player input data) by the 100ms deadline, so we make a prediction about what the server will send next, and when we're wrong, we can interpolate between the wrong and the right values over the course of a few seconds.
I don't know why we're *arguing* about this. Why can't we just *evaluate* this?
Last edited:
There are a few more problems with just streaming this information. For example, each object has a variety of test functions which it uses to determine if certain interactions can be called by the user. Without an accurate VM state, we cannot run these in real time without making a call to the server and back, causing a delay (bad hci!!). We can't possibly make any predictions about future frames at all with this solution either (because that requires an accurate vm state!), so that's completely out of the window. However this could possibly work, but it was not what I was seeing in anything bigl was saying, I just thought he was talking about using a mystery switch to just stream everything seamlessly, where the real challenge is streaming as little as possible. I hadn't previously thought about a thin client style solution, and it could actually help for cross platform implementations! (lot viewer instead of lot simulator (jaaavascrippttt!), less chance of floating point desync if we accidentally leave the VM dependant on one)
The problem is, since this wasn't done for TSO there might be a problem with this solution that we're overlooking, for instance it may be in a bad format for an MMO (network and packet process heavy). But it has got me curious...
Conversely, for streaming VM objects, streaming just the inputs to a deterministic state machine and checking a simple hash to detect accidental desyncs is much more efficient than any solution involving streaming 150 live VM threads over the internet. If anything is incorrect/out of time/forgotten, things can go very differently, and that backlash of fixing it will make the whole experience seem hacky and confusing. Fixing it will require resyncing all VMs, or an incredibly advanced system for registering what exactly each thread changed since the last server data.
Ideally there should be no prediction - the client should hold a small buffer of inputs to protect against jitter (~100ms of data should be enough, maybe more if connection is unstable (dynamically adjust the buffer size to fit the user's connection)) which it continues through until it catches up. This will cause some extra lag, but again it doesn't matter for a slow paced game like TSO. If the game reaches the end of the buffer, it will stop until it receives more info, then simulate at a faster rate (with threshold 2x buffer size?) until it catches up to the ideal buffer size. If connection is lost for an extended period of time we'll have to resync everything. That should create the smoothest gameplay experience for any of the solutions.