Client/Server basics
by Mark Farra · in Torque Game Engine Advanced · 11/06/2008 (8:00 am) · 2 replies
I'd like to bug the community for some design advice here. I'm becoming increasingly familiar with TorqueScript and how generally to get done the things I need with it. However, I'm creating a multiplayer RPG-style game, and I'd like some input on the basic design method for a couple of things.
First: combat. The combat system if fairly straight-forward; it uses a series of character statistics such as ability scores and character skills to determine hit/miss probability, damage, and so on (nothing innovative there). I've been reading as much as possible on the client/server architecture of TGEA and I know a few basic rules (such as never allowing the client to determine anything game-authoritative). However, putting this into script to run as smoothly as possible appears a little confusing to me.
In effect, the basics are:
Client: click button to attack blah-NPC
Server: get information about the client and NPC, make checks to determine the success or failure and report to the client the results
That seems fine "on paper". My confusion comes in implementation. The commandToServer and commandToClient functions read as a remote command to be sent back and forth. So, basically, I'm asking your opinion on how exactly to design this. Pseudo-code, perhaps? I've had a good look at melee combat systems available for implementation in Torque, and none of them quite fit the bill or what we're going with. I'm not asking anyone to design the whole system here, of course (hehe), but some guidance would be greatly appreciated.
Secondly, I've just created an RPG-style inventory system that works nicely for a single-player game, but not for multiplayer. The same general question applies: what would be a good design for a multiplayer RPG inventory? My initial belief is that it could be taxing if the server had to keep track of everyone's inventory locations; every time a player moved an item from one slot to another it would need an update from the server. However, if the client-side handles inventory, how much room for cheating the game is there, really?
I'm assuming it needs to be stored server-side, and that data (along with character information) is sent to the client on connection to the server. Once it's retrieved, the client handles inventory until special events (such as saving the character), when the character information, including inventory, gets sent to the server and stored there for safe-keeping.
Does this approach seem optimal?
Lastly, some basic questions about the client/server layout of TGEA:
1: Under the generic design, do the scripts located under the "client" folder only get executed on the client? And vice-versa, the scripts located in the "server" folder only run on the server?
2: Would it be more efficient to maintain constant updates to and from the server with smaller amounts of information, or to store larger chunks of data on the client to be sent to the server during certain events? Using inventory by example: should an update to the character's inventory be sent to the server each and every time the player moves something around, or only say ... every 10 or so minutes when the character information is saved?
Obviously, my knowledge of networking is a bit lax. I'd like to make this as efficient as possible, and I'm asking for some opinions on design-style, essentially. The ghosting system is a tad confusing to me, but I'm starting to grasp it a little.
I appreciate your time!
First: combat. The combat system if fairly straight-forward; it uses a series of character statistics such as ability scores and character skills to determine hit/miss probability, damage, and so on (nothing innovative there). I've been reading as much as possible on the client/server architecture of TGEA and I know a few basic rules (such as never allowing the client to determine anything game-authoritative). However, putting this into script to run as smoothly as possible appears a little confusing to me.
In effect, the basics are:
Client: click button to attack blah-NPC
Server: get information about the client and NPC, make checks to determine the success or failure and report to the client the results
That seems fine "on paper". My confusion comes in implementation. The commandToServer and commandToClient functions read as a remote command to be sent back and forth. So, basically, I'm asking your opinion on how exactly to design this. Pseudo-code, perhaps? I've had a good look at melee combat systems available for implementation in Torque, and none of them quite fit the bill or what we're going with. I'm not asking anyone to design the whole system here, of course (hehe), but some guidance would be greatly appreciated.
Secondly, I've just created an RPG-style inventory system that works nicely for a single-player game, but not for multiplayer. The same general question applies: what would be a good design for a multiplayer RPG inventory? My initial belief is that it could be taxing if the server had to keep track of everyone's inventory locations; every time a player moved an item from one slot to another it would need an update from the server. However, if the client-side handles inventory, how much room for cheating the game is there, really?
I'm assuming it needs to be stored server-side, and that data (along with character information) is sent to the client on connection to the server. Once it's retrieved, the client handles inventory until special events (such as saving the character), when the character information, including inventory, gets sent to the server and stored there for safe-keeping.
Does this approach seem optimal?
Lastly, some basic questions about the client/server layout of TGEA:
1: Under the generic design, do the scripts located under the "client" folder only get executed on the client? And vice-versa, the scripts located in the "server" folder only run on the server?
2: Would it be more efficient to maintain constant updates to and from the server with smaller amounts of information, or to store larger chunks of data on the client to be sent to the server during certain events? Using inventory by example: should an update to the character's inventory be sent to the server each and every time the player moves something around, or only say ... every 10 or so minutes when the character information is saved?
Obviously, my knowledge of networking is a bit lax. I'd like to make this as efficient as possible, and I'm asking for some opinions on design-style, essentially. The ghosting system is a tad confusing to me, but I'm starting to grasp it a little.
I appreciate your time!
About the author
#2
I'm terrible at understanding this, apparently. I have the whole inventory system running and working fine if in single player mode. It stops there, however; my updates to inventory aren't even fired when connecting to the dedicated server.
I've found out that apparently I can't use commandToClient functions to "get" data about the client from the server. At least not out of a commandToServer function call. Heh!
The combat system I've made does work. I have placed the script that contains calculation functions under "scriptsAndAssets/server". Essentially, I map the "attack" key to blah, on it I called a commandToServer('DoAttack') which in turn calls a function I added to the Player class (Player::onAttack).
Everything in that system works fine, single player or online. My inventory system, however, is set up a tiny bit different. As are the character saving functions. Here, for example:
I bind my "test key" (which is '/' to commandToServer('SaveCharacter'). And in "serverCmdSaveCharacter" I the code to save the character data (including inventory) to disk. Mind you, the test key's function "serverCmdTestKey" is what calls commandToServer('SaveCharacter'). My question is, should I make the saveCharacter() function outside "commands.cs", and call it like a normal function?
Obviously, I'm a bit confused on how exactly commandToServer and commandToClient roll out and when exactly they should be used.
11/07/2008 (3:26 pm)
Thanks for the advice. I was hoping to get a tad more advice, however. At the moment, could someone specifically address the first basic question?Quote:1: Under the generic design, do the scripts located under the "client" folder only get executed on the client? And vice-versa, the scripts located in the "server" folder only run on the server?
I'm terrible at understanding this, apparently. I have the whole inventory system running and working fine if in single player mode. It stops there, however; my updates to inventory aren't even fired when connecting to the dedicated server.
I've found out that apparently I can't use commandToClient functions to "get" data about the client from the server. At least not out of a commandToServer function call. Heh!
The combat system I've made does work. I have placed the script that contains calculation functions under "scriptsAndAssets/server". Essentially, I map the "attack" key to blah, on it I called a commandToServer('DoAttack') which in turn calls a function I added to the Player class (Player::onAttack).
Everything in that system works fine, single player or online. My inventory system, however, is set up a tiny bit different. As are the character saving functions. Here, for example:
I bind my "test key" (which is '/' to commandToServer('SaveCharacter'). And in "serverCmdSaveCharacter" I the code to save the character data (including inventory) to disk. Mind you, the test key's function "serverCmdTestKey" is what calls commandToServer('SaveCharacter'). My question is, should I make the saveCharacter() function outside "commands.cs", and call it like a normal function?
Obviously, I'm a bit confused on how exactly commandToServer and commandToClient roll out and when exactly they should be used.
Torque Owner Stefan Lundmark
As long as the item exists, why would the server have to know in what spot it resides?
As for being heavy, it's the only way to determine that you're running a legit simulation. You can put items in different priority groups, so when rare/important items are picked up, it's saved to the database, but if an item is of less importance it is only saved on the next queue or logout.