I hope this project works out well.

[bigl2369]

At first you said you thought that you thought TSO made the client simulate the server. Now your saying that they probably didn't. You also said it would be weird to see all the object scripts built on the client server. I don't see any harm or benefit to it myself.

I promise you that the character controller(or whatever you effectively want to call it) is not making variables that are editable or understandable. Pathing scripts are beyond average human intelligience. While you could create a variable for its position or its rotation in relation to other objects or itself... you won't be able to figure anything else out.

Are you doing this just for fun and experimentation?

It sounds like RHY thinks its impossible.

 

[bigl2369]

The only other project I know about where they emulated a server was Star Wars Galaxies. Its actually very successful swgemu is. Their big thing was sniffing packets of information. They never said any crap about requiring the client to run a simulation and having the server perform client actions 100ms late and telling each client to synchronize to it. They always were talking about how they were systematically eliminating bugs and how the servers were running better and better. What features were working and which weren't. Possibilities of custom content(which they never got around to.) Why don't you ask those guys?

 

[Clonest]

The only other project I know about where they emulated a server was Star Wars Galaxies. Its actually very successful swgemu is. Their big thing was sniffing packets of information. They never said any crap about requiring the client to run a simulation and having the server perform client actions 100ms late and telling each client to synchronize to it. They always were talking about how they were systematically eliminating bugs and how the servers were running better and better. What features were working and which weren't. Possibilities of custom content(which they never got around to.) Why don't you ask those guys?

Maybe because this game ISN'T your tradition MMORPG??? Now I can't speak for the developers here but if I understand correctly this game has quite a few other elements that need emulated for the game to function correctly. There's no direct client-to-server operations to be emulated here like other games where all they had to do what sniff out enough packets during and after the official shutdown. Thus why you see mostly working emulators for those games, was easier to do. THIS GAME on the other hand seems to have a separate server emulator piece needed to run the login procedures or character select, the city view, the lots/houses in-game and from what i've seen a fourth piece that buffers and synchronizes all sim interactions with objects and other players.

 

[Rhys]

For a start, nobody said either of those things! The original TSO client contains all object scripts (which i have been saying the whole time!), suggesting they used the synced inputs solution because of its low bandwidth requirements. Nobody went back on this.

I never said this is impossible for us, just that it's impossible if you blindly try to hold the game together over the network using the grace of god. Synced inputs or Fatbag's thin client idea are completely feasible.

PD is not a server emulator, it is a complete recreation of the game client and protocol. You cannot possibly compare us to a server emulator, as we are designing a new protocol, not hijacking an existing one. Did the Star Wars MMO run a complex, game driving VM thread for each and every object on a map?

I've repeated a lot of things more often than I would have liked to. I'm giving you the benefit of the doubt right now but if you keep dismissing my arguments with unrelated points, babble about how you think networking works (latency?? that totally doesnt matter at all right??) and comparisons to server emulators I don't think there's any help I can provide.

 

[bigl2369]

Maybe you guys are geniuses who will develop a good new revolutionary server protocol or whatever I don't know. Or maybe you think that your trying to mimmick something that's occasionally or frequently done. I don't understand your intentions. Maybe its a faster/better system. Maybe you think your trying to recreate what TSO did. Maybe you think your idea is unique. I'm trying to figure it out.

I know one thing. Its best to try to mod an engine rather than write your own.

And I don't want help. And I'm sorry I disrespected you guys. Its nice that you guys are letting me post and not calling me a troll. No matter where I go and post people think I'm just wasting space on their forum talking about shit I don't understand. I just understand a little bit about modeling/coding/animation and know of some other things that go into making a game like special scripting, character controllers, physics, UI, input, and network and databasing.

 

[Rhys]

For this game, due to the complex nature of the server hosting one of these Simantics VMs per lot it's actually harder to make a server emulator, since we'll still need to implement a large portion of the game as well as reverse engineer the existing protocol.

 

[Fatbag]

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.

The server can just stream the available actions too. (And it can just stream which available actions have changed, which is more efficient than streaming all available actions all of the time.)

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.

The prediction is that animations will continue running (if they reach the end, they can switch to the idle animation), sprites will continue their current animations, players will continue moving towards their destinations, etc.

But since we *can* run the simulation on each computer, and we can get *more* things to predict (what will this object do next? etc.) by doing that, and the server does not have to stream as much (the server just streams the player actions and a hash of the current state to ensure that the client has not desynced; and if the client does desync, the server sends over the entire VM, or if the VM is really large, maybe we can use the method that torrents use: both the client and server generate a Merkle tree, and the server sends over just the blocks that the client needs), I'd prefer running the simulation on each computer.

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.

Like I said in my previous post, the server could just stream the essential non-Simantics information. But this probably does use more bandwidth.

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.

This works.

 

[Fatbag]

The only other project I know about where they emulated a server was Star Wars Galaxies. Its actually very successful swgemu is. Their big thing was sniffing packets of information. They never said any crap about requiring the client to run a simulation and having the server perform client actions 100ms late and telling each client to synchronize to it. They always were talking about how they were systematically eliminating bugs and how the servers were running better and better. What features were working and which weren't. Possibilities of custom content(which they never got around to.) Why don't you ask those guys?

If they're being *that technical* in their update news, it's still possible they put a single bullet point "Improved player movement prediction; player movement is now noticeably smoother in unstable connections" in one of the updates and you missed it.

 

[francot514]

A simple and noob question, will be tso-se cannot be used for the server emulation requiered for PD???

 

[Afr0]

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

Sigh, don't even get me started on reconnections. I've disabled them for now by having the city server disconnect and remove any client that causes an exception when trying to send data. But the server should ideally test if the connection really has been dropped, and then it should probably wait (?) for a reconnection for a set amount of time. IIRC, The Sims Online actually didn't bother with reconnections at all. As soon as the connection was lost, a player would disappear from the lot.
This obviously isn't an "ideal" solution, but it is the easiest one.
I think the initial implementation will just be like this - to give you an idea of how difficult this is, WoW until very recently would pretty much use the TSO solution, albeit with a timeout. Recently they've managed to find some kind of system for reconnecting players - I know this because where I live is plagued by a horrible wireless connection that drops out all the time.

 

[aidancheddar]

Maybe you guys are geniuses who will develop a good new revolutionary server protocol or whatever I don't know. Or maybe you think that your trying to mimmick something that's occasionally or frequently done. I don't understand your intentions. Maybe its a faster/better system. Maybe you think your trying to recreate what TSO did. Maybe you think your idea is unique. I'm trying to figure it out.

I know one thing. Its best to try to mod an engine rather than write your own.

OpenTTD. It started out as a mod for Transport Tycoon Deluxe. As it developed, they eventually realized it'd be better to rewrite the entire engine.

 

[bigl2369]

I just don't think you should be trying to implement anything different than what was done in the original game. I loved the entire experience and so did a whole bunch of other people. It doesn't need to be improved upon. Your making it seem like you think TSO servers weren't any good. Or like you just want to experiment and waste the peoples time who are waiting for this project to complete. All of the objects, sim interactions, city mode stuff, build/buy mode stuff, skills, needs, chat, pets, jobs... everything in the original game... everything worked and there was no lag. So why do you think you need a new better server protocol?

 

[Afr0]

We need a new protocol because we don't know the specifics of the original - if we did we could just emulate the server rather than recreate the game from scratch.
Also, please just stop making assumptions. For every single algorithm used by the original game and our reimplementation, there are at least ten different possible implementations, depending on the language used and platform(s) targeted. So thinking that there's one "correct" way to do something is just plain stupid.
There's an old problem that has plagued programmers for centuries: Is it an art or a science? In this regard it is most definitely the former - for every ten programmers in a room, you'll find nine different approaches to implementing an algorithm, just like you'll find ten different approaches to painting the Mona Lisa for every ten painters.

 

[bigl2369]

You weren't even making things clear. You've just now provided an explanation that you can't emulate the server because you don't know how to, so instead have to recreate it from scratch. I was under the impression you were trying to improve on a system that didn't need improvement. I was also trying to draw conclusions as to whether or not you thought TSO was "syncing" like you've described or not.

The title of this thread was "I hope this project works out well." It should be "I wish this project would work out well."

Also you should make it very clear that "We don't know how to re-emulate the server. We're trying to use a syncing system that TSO used."

Also, you have no proof that TSO used a syncing system like you've described. Just like I have no proof that they didn't.

 

[Rhys]

If I'm not allowed to make assumptions what else am I supposed to do? Come on bro I'm just reading and drawing conclusions. That's how people discuss things. You weren't even making things clear. You've just now provided an explanation that you can't emulate the server but instead have to recreate it from scratch. I was under the impression you were trying to improve on a system that didn't need improvement. That's why I thought it was gay.

You usually can't tell someone that they're wrong if most of your argument is an assumption. If you had enough prior knowledge, what we've said so far should be clear enough to explain and justify why we're doing things the way we are. This isn't something you can just understand off of the bat, eg. Xezno thought he could recreate TSO on his own with no prior programming experience using Visual Basic + Windows forms, not even a game engine. Look where that got him...

We're discussing how it was done, and ALREADY said that we are planning to implement the same synced VM system that the original game used. Because we are not making a server emulator though, we still have to make our own protocol to implement it this way.

 

[bigl2369]

So when can I tell someone their wrong? When I know everything there is to know in the industry and can emulate servers or develop my own single player, tcp/ip, or server based games? Or when I can mod games? Or when I can model/animate? Or when I can develop applications and web pages? Maybe... and maybe I should get to work on that.

And what exactly is an assumption? Its taking whats been said and drawing conclusions. I don't think theres anything wrong with that. If I *knew* instead of *assumed* that would be better. But I don't and I still want to express myself.

 

[aidancheddar]

Your making it seem like you think TSO servers weren't any good.

They were. Just because we love the game, doesn't mean we can't criticize it.

 

[bigl2369]

You guys seem to think that there was some sort of special syncing in TSO and I don't.

You provide no proof that you know what your doing because you have yet to deliver a product. You also claim that you don't "know how to emulate a server". Whatever that means. Whether you will be successful in your endeavors is obviously in question. And I don't think you will.

I was just saying that I enjoyed this argument, so I'm glad you didn't just ban me and my little doggy here from your forums.

I think I have said everything I wanted to say, and that you understand where I'm coming from. And I think you have spelled out your main points. Which are that you cant emulate a server and that you believe TSO used some special syncing protocol.

 

[Fatbag]

Sigh, don't even get me started on reconnections. I've disabled them for now by having the city server disconnect and remove any client that causes an exception when trying to send data. But the server should ideally test if the connection really has been dropped, and then it should probably wait (?) for a reconnection for a set amount of time. IIRC, The Sims Online actually didn't bother with reconnections at all. As soon as the connection was lost, a player would disappear from the lot.
This obviously isn't an "ideal" solution, but it is the easiest one.
I think the initial implementation will just be like this - to give you an idea of how difficult this is, WoW until very recently would pretty much use the TSO solution, albeit with a timeout. Recently they've managed to find some kind of system for reconnecting players - I know this because where I live is plagued by a horrible wireless connection that drops out all the time.

Sorry, by "connection drops out" I meant the steady stream of packets from the server to the client pausing for 1/5 of a second, not the TCP connection closing and re-opening for 1/5 of a second.

Afr0: Thanks for not shouting in this thread.

 

[bigl2369]

LOL I'm done too. This shouldn't turn into a bickering match. And I've redited my posts several times to eliminate harshness. Theres no further it can go because you guys believe what you believe and I believe what I believe. And I don't think we're changing our minds.