Question, Server / Client seperation, can you ?

#61

Quote:
encryption doesn't prevent cheating

I would have to second that one. Even if you think you are fully and/or strongly protecting you data (which isn't how to prevent cheating anyway), coming from a naval (CRT) Cryptologic Technician background I know first-hand just how easy it would be to break any encryption scheme that would retain any in-game usability.

#62 EDIT: double post, that was weird!

#63 @Pat

As i said, i understand why you have your internal networking, just not "why" in the matter its not useful for ALL games, mm let me correct that one, its not always required like that for all games.

Of course, i can spend alot of time sitting down, digging deep into torque networking code, and then be using that, or i could do what i always do when it comes to networking (and actually already know).

And encryption dont prevent cheating.. no, maybe not by itself, but it prevents alot of it.

Also, we use weekly rotating opcodes to prevent bots (update in the dll each week at maintenance), but i dont want to sit here and tell all our trix incase ofcourse this once gets public :).

things like run-hacks via animation-speed

Yeah, but if you read my earlier post, with our system we know where they are, supposed to be, and runspeed, and gets verified automaticly each time the user runs, so thats unlikely to happen, and we aint building counter-strike :).

but you have not even examined the Torque networking, nor made any effort to understand how it works. Your misconceptions about it's operation, and the data it uses makes that obvious.

Oh wow, why the *beep* do you think i ask, and while you say i havent examined the torque networking, sure, maybe not deep, but i woudnt ask you if i didnt know it was there, and while i do know WHY it was there, not just WHY it HAVE to be there.

There are several people on these forums (More than have replied to this thread, even) who have done exactly what you are trying to do...and shipped it, and you are telling them they are wrong.

You telling me its the only right way ?, i never said it was wrong, i just said its not how we do it, and thats why i asked for some help, geez.

#64

Quote:
I have been working on an MMO for over a year now and use a similar architecture as many here has suggested. We use TGEA (soon to be T3D) as the "game server" which is used for character movement, interaction with the "physical" world, and receiving input from the client. We then stream data via local tcp/ip to a back end C# server. We used a service-oriented architecture (SOA) so the C# servers can talk to other remote or local servers as necessary. The overall design is pretty simplistic: torque client talks to torque server, torque server talks to C# "area server" and C# area server interfaces with what we call the "world server" (mainly used for requesting players and sending data out for long term persistence).

Object creation in Torque is controlled by our C# back end -- when a player logs in, for example, the C# server gets the player data and then sends a command to Torque to create a torque player. When the player is created we get the torque object id for that player and link it back to the C# player object in a dictionary. This way when we receive a torque object id from the torque server we can look up what object it is associated with in the C# side. So far this implementation has worked extremely well.

Interestingly, this is very close to the three tier (Model-View-Controler) architectures that are very popular in developing web applications. The popularity stems from the scalability, and the ability to separate the view of the data from the processing and management of that data. In this case, the client is the 'view', responsible for representing data and taking input from the user. The back end server is the 'model', which manages persistent data and its interactions with users, and the Torque server is the 'controller' which ties the two together and translates between their views of the world.

#65 I don't understand why Torque networking is so sacred.

Authoritative game state management and object replication can be implemented many ways and I don't understand why the Garage Games employees seem to think that Torque's implementation is always the best solution for every game.

It's not.

The question is, why would Bo want to replace it? Simple... it doesn't fit Bo's architecture.

If it doesn't fit then it doesn't fit. There's no reason to try to forcibly fit a square peg into a round hole. I don't care how many awards or popularity contests Torque has won.

@Bo - I've done what you're attempting and I'll dig up my implementation and give you a few pointers.

Some things to keep in mind:

Torque does do quite a few things that you shouldn't discard, such as having different packet types based on how dropped packets should be handled: ignored, resent or replaced with updated info.

Another thing you should do is use UDP instead of TCP. TCP does not allow you to implement the previous paragraph.

You should use the server as the authority on game object states, and your clients should send "move requests" to the server and assume that they'll be filled, but be ready to interpolate game object states in case the move request packet is dropped. Even Torque "rubber bands" in extreme cases here, but with an MMO game then you can make it appear more smooth thanks to the lower fidelity simulation requirements.

One of the things you can do with MMO games that FPS games cannot do (which you're doing with your "bytecode" style implementation) is to replicate the move requests to other clients and skip some of the periodic object synchronization.

But, you cannot completely discard the periodic object synchronization. With an MMO game, you can send the sync packets less frequently, but the synchronization is still required.

One of the things I did with Fractured Universe is to time the object synchronization based on previous "packet loss" history and based on the fidelity requirements of the game object being synchronized.

For an avatar in the middle of nowhere that cannot agro any mobs you can get away with an extremely low fidelity simulation and thus you can get away with fewer synchronization packets.

On the other hand, an avatar that's fairly close to an agro-able mob will need higher fidelity and thus require more frequent synchronization packets.

You shouldn't spend too much CPU time determining the fidelity requirements of a game object... if you can't do it by simply using very simple AABB queries in an octree then you should use a default fidelity setting.

You can also play some tricks with "scoping" avatars to other players where you lower the fidelity of an avatar the further out of view it goes, until the fidelity requirement reaches "zero" at which point you cause the avatar to fade away.

For FracU, I created a simple scoring algorithm that recomputed the score of an avatar to a player based on proximity among other things. It was highly optimized and "interpolated" quite a bit of the data, so it was inexact, but you didn't really notice it when you're playing.

That's the key... implement the network layer so that your players don't notice it's there.

Torque implements a lot of this too, but not in such a way as to allow you to easily change how it works, which is why I replaced it... and there are probably many other reasons too.

Just remember... Torque's only purpose is to save you time. If you encounter a suitable reason to ditch part of it, feel free to do so without looking back, up to and including ditching 100% of it.

As a software developer, one should never be afraid of throwing code away.

#66 @Tony

Thank you, i could not have said it better myself, infact, its probably how i should have said in the first place :)

And thanks for the pointers, i surely give you right in what you say, while i could discuss the TCP vs UDP, as my system already have "ranked" packets in TCP based on importance (que system), so some packets have higher priority for transmission, i ofcourse can see the point in posibly using UDP for some things (though my system at this point wasnt created in that mind).

In all cases, awesome post, good strong pointers, and ill surely take it to me, so thanks again.

#67 There's a lot of discussion here on protocol advantages and disadvantages. There are a lot of opinions.. I personally like Torque's UDP implementation, others may have different preferences.

I wanted to get back to what your server actually does, because it sounds to me like everyone's making things way too complicated for the desired functionality.

Your server, as I understand it, keeps track of player stats (health, inventory, etc) as well as keeping track of all of the static objects in the environment. It also keeps track of player positions for authoritative purposes.

Torque was designed specifically to handle the things you designed your server interface to do. Torque's server-authoritative network design makes any kind of cheating aside from aimbotting (which is an issue you won't care about in your game) impossible, because the only data it allows the clients to handle is rendering and input. Clients also do physics sim to keep the prediction up to date, but their sims are never the authority on object states.

If you need a server that extends beyond the scale of a Torque server (64 players is the current limit, I believe, but I think you can get that higher) then you should connect your server to the Torque server itself and use it as a super-authority to keep account data, player inventory and stats, etc. for when you need to change Torque servers or store things long-term.

I'm not saying there's anything wrong with your system, it sounds like a design that's working for your game style, but it would be a huge waste to throw away the existing Torque networking, which I should mention was designed for commercial game use and has been heavily tested over the years. You're right, not every game needs that level of network integration and many engines don't have anything even close to it. Its deep integration into the code is a result of the fact that the engine was mostly built on top of this networking system. The advantage is that every object type in the engine already handles networking out of the box.

It basically just doesn't sound like your server does anything you couldn't get running in Torque in a day. The truth is, you wouldn't need to study or understand the networking code to do any of this.

An inventory system could be built into the Player class pretty easily, and you just transmit the data the clients need in the packUpdate() function. You read it in the unpackUpdate() function. It's all very straight-forward, you send flags to indicate that a new update is coming, then use the steam->write and stream->read functions to send/read the data.

My Player-derived class I actually use in-game stores a full inventory, 4 additional "vital" stats (transmitted every packet, like health and energy), 20 secondary stats (transmitted when they update from a player level-up), and a number of other small things not worth mentioning. This system consists of a few variables to store the data, alterations to the previously mentioned pack/unpack functions, and some access functions & console functions for getting the information. Using the mask system, updates for particular types of data are only sent when the data is actually changed, so you're not wasting bits resending stats every tick.

I'll throw this in.. if you really insist on using your existing server interface, then run the Torque engine in singleplayer and connect that whole thing to your server. What does that mean? I mean run a client and a server in the same thread, which is what Torque does for singleplayer, and then connect the server to your server and get position and data updates like that. It'll take less effort than actually trying to pry the client and server apart. :P

#68

Quote:
(64 players is the current limit, I believe, but I think you can get that higher)

This is based on Tribes 2 packet sizes and transmission rates. For an MMO, you will not need the server sending updates as frequently as for an FPS. Also, I suggest against basing any MMO object off of anything other than GameBase. Player/ShapeBase are really heavyweights as far as how big their pack/unpack updates are. For the RTS kit, each unit was actually it's own net object, but they were so stripped down there could be lots of them without adversely effecting performance.

I think Stephen knows the story on adjusting server frequency, but I know that (several years ago) there were hundreds connecting to a Torque server after adjustments were made.

#69 I don't have much time to brain dump deeply tonight, but I did want to follow up on one thread of this conversation--"Torque Bias".

Tony and others raise the point that on the surface, it sounds as if there is some minor fanboy-ism regarding Torque's networking here, but I honestly don't think it's a factor in the best overall implementation plan for Bo's goals.

Torque's networking handles most of the things that Bo ultimately will have to figure out, and therefore is definitely a good candidate for use, but as Tony strongly suggests, Torque Networking is never the only solution.

As I described pretty extensively, there have been projects I've worked on where Torque's networking did not apply directly (trying to implement DIS protocol requirements directly into the Torque networking model would have been a nightmare), and Tony points out well that there are other options.

The key deciding factor for Bo here however is evaluating the relative challenges of getting Torque and his C# server work to tie together, or to treat his C# implementation as a prototype, and re-implement it within Torque's existing model.

His challenge is best demonstrated by turning Tony's argument around: Tony's right that you should always evaluate all options instead of defaulting to Torque Networking Model as being the only answer--but that also implies that simply because a prototype of a possible server architecture exists, that doesn't mean that the only solution is to use it as it's implemented.

As an experienced Torque developer with a pretty decent understanding of Torque's networking and client/server architecture, I wouldn't even consider trying to tie together what we know of the C# implementation with Torque--I would instead treat the C# server implementation as a prototype, and re-implement completely in Torque.

Then again, I'm not Bo, and he's not me. He can take the advice here, or not--and part of that choice is knowing his options, and what he and his team can accomplish the most efficiently.

#70 @Stephen

I ofcourse take it all too me, i always do that, if not for now, then surely for later use (who knows right), also against all odd's, should my implementation fail, i can always fall back to this thread and get a brainstorm going.

I would also like to point out, i was not trying to start a pissing contest at all, and i know some people are hardcore torque "fans", and all respect for that.

But, as with many people in this thread, i am a bit more open minded, even if something works 100% for 10 years, and i knew it did, i would never consider it the only way to do it, other way may be just as perfect (if not better depending on situation).

So, we got alot of good pointer one way, and the other way, and ofcourse ill talk everything over with the team now i got the bigger picture :)

In the end though, i suspect they will go with the C# server 100%, though, it might end up being implemented other ways (i personally dont have any idea though yet).

But, in any and all cases, the thread is a good read :)

Spock: "... logic clearly dictates that the needs of the many outweigh the needs of the few".
Kirk: "Or the one".
Yes, but that doesnt mean the few (or the one), is less right :).

#71 If you get it working, it would be great if you could post your experiences and how you solved the various problems.

Matt

#72 Can we define what each one means when saying "Torque Networking"? Some blanket statements were thrown around. Tony, do you mean the actual packet/stream system, or the only the Move/Player/ShapeBase stuff? Because I would hardly consider the Move/Player/ShapeBase "Torque Networking".

I always saw those classes (and most of the ones inside the T3D folder, save for two or three) as implementation examples, not as core elements. Nobody should be afraid from throwing them away, and anyone would suddenly gain incredible flexibility by doing so. For people who have some experience writing games using frameworks instead of engines and/or are working in games that deviate too much from the way the T3D classes work (either in network behavior or logic) it would probably speed development up and they wouldn't have to bother about details like datablock transmission order and how the actionThread stuff works.

You have lower level access to the rendering, audio and network systems, but for more people to take advantage of that we need docs and resources explaining how to live in a world without ShapeBase.

(Hmm... maybe I should get my lazy ass moving and give it a try at a setting up a resource like that...)

#73 When I talk about "Torque Networking" I'm generally talking about the code that handles the app layer protocol and the "client scoping" code.

I agree that most of the code in the "T3D" folder should be used only as an example and is not actually part of the game engine proper.

Quote:You have lower level access to the rendering, audio and network systems, but for more people to take advantage of that we need docs and resources explaining how to live in a world without ShapeBase.

Absolutely.

Quote:(Hmm... maybe I should get my lazy ass moving and give it a try at a setting up a resource like that...)

We should have several examples, not just one... in the relatively near future I plan on providing an example / resource that shows how to use the Zen Engine game engine framework integrated with T3D (but not until after T3D goes "gold" and not until after we've finished the Zen editors).

I think an example like this is necessary because it'll open people's eyes so they can see the true power behind Torque and the flexibility you can get by integrating it with a well-thought-out framework.

#74 Yeah, more examples are definitely needed.

The longer I spend in the Torque3D source the more cool stuff I find on the rendering system, as example, which makes it great value, but the knowledge on how to tap that without going through the standard "T3D" classes is scarce. One could use it only to handle input/graphics/sound/resource loading and do all gameplay from scratch.

I keep entertaining the idea of making a small prototype completely different the standard Torque fare, like a 2D bullet-hell vertical shooter or something just for the sake of showing how to use the internals without the stock classes.

#75 Thank you Bo to raised such a topic with so much valuable information in the discussion thread.

#76 @Nicolas

Yeah, it surely started something i didnt expect :), and some great info here and there, surely something to think over.

Funny though, question no 2 in original topic was never answered really (except Tony i belive it was, mentioned the T3D source folder in engine).

Hint for GG ->
I miss some source documentation, and with class hierarchy so you can see what classes uses what and where. (atleast after beta release)
<- Hint for GG :)

This is a engine sold with source after all :)

#77 Essentially you'll want to take a look at (going by the TGEA docs found here):

SimObject (root simulation object)
NetObject (adds network support)
SceneObject (adds "scene node" support and collision detection)
GameBase (adds datablock support and the bulk of the networking)
ShapeBase (adds a lot of FPS specific code)
Player (definitely FPS specific code here)

GameBase is definitely the key component here. You're going to want to either replace it completely or modify it significantly.

ShapeBase and Player should only be used as a reference. You should not use the code in these classes. And I'll repeat myself because this is very important: ShapeBase and Player should only be used as a reference.

#78 On the project I'm working on we're taking a progressive approach to our player class: we created a new class, derived from AIPlayer, and any method that requires reimplementing is re-declared in our class and re-written iteratively as we progress. This way we don't have a large blank development time without anything playable.

Later on we'll reach a point where we can cut the umbilical cord to AIPlayer and derive from ShapeBase, implement only what we really need and then finally derive straight from GameBase. Our current project has no need to go down further than that (datablocks are relevant to our goals).

#79 I have to throw a little defense about the Torque networking. I've been working on MMOs for almost 15 years now and I keep seeing the comment "Torque networking is not good for MMO's its only good for FPS's"
and I have to say that generally speaking thats not a good statement to make.

Torque networking is so anal about what it sends that it maintains that twitch style game play without sending much data at all. You have to remember this networking code was written back in the 14.4 modem days when bits were at a premium. This was long before we got our multi-megabyte connections we have now.

I can tell you that man of the MMO games out there are not efficient at all when it comes to data traffic, in fact they are so bad most of them cant run on a 56k modem connection anymore.

So with Torque networking you are actually starting out with something that is way more efficient then you need it to be.

Now, that being said it does have some limitations that might not translate over to a MMO as is. For example the limitation on the number of unique bits that can be set for any given message is limited to a 32bit int. This is of course very easy to work around and extend however when you go to add a new mask to an object and the aggregation of all the masks for an object exceed your 32bit int it can make a mess of things and can be a pain to rework everything to handle it. But there are ways to extend it in a simple manner that still maintain the extreme efficieny that the current torque networking code has.

I can say after looking at dozens and dozens of networking libraries, both purchased and home grown, its a rare thing to come across one that is so ridiculously efficient.

In fact in current times it seems programmers have gotten sloppy and practically rely on that fact that we will all have 10MB connections with no latency and no packet loss. Dont laugh but its not much different then expecting everyone to have the latest vid card and 10GB of memory.

Anyway, dont throw the networking code out just because your making a MMO game. If you need additional functionality, or backend connections to talk to other server processes (common in a MMO infrastructure) then add in a new networking object to hand those specifics (like global chat, calls to a guild server for example) and plug in your custom networking for that and let the rest of the torque networking library do what its awesome at doing.

Its certainly really easy to tweak the current networking to slow the amount of data sent, send less, less often, etc very tweakable and then you still get the benefits.

Just keep that in mind when your reviewing the networking code and thinking of ripping it out. Its usuable and yes for RPG's just the same as FPS's.

#80 While this is an older discussion, it's still worth reading.

My only complaint about Torque networking (3D Pro 1.1) is that there's no simple way to exclude server functionality from a client (such as by adding a #define NO_SERVER statement). I'm currently trying to split the client/server spaghetti with limited success and lots of reverting to the previous revision of my code. If anyone else would like to help with this task, I'd be very grateful.

My current spaghetti untangler uses

#ifdef CLIENT
// Client-only code
#endif

#ifdef SERVER
// Server-only code
#endif

and I define both SERVER and CLIENT for single player/peer-to-peer products, only SERVER for dedicated servers, and only CLIENT for products where server code should not be distributed to players.