Multiple, concurrent missions (server questions)
by Daniel Buckmaster · in Torque Game Engine · 07/12/2008 (2:14 am) · 6 replies
The basic idea for multiplayer in my current project is that instead of just selecting a list of missions to play, you play 'campaigns' - progressions of missions that each have an effect on future missions. So, for example, the first battle is a beachhead assault. If the attackers fail, in the next mission they have no reinforcements.
This is fine - the server simply loads the correct missions one after the other.
However, you can't create a very complex campaign with only this limited linear progression. Even with branching mission trees, which add a lot of depth, there's something to be desired. Yes, I know I ask a lot.
My idea is to have multiple battles happening at the same time. The most basic example of this is a 'warzone' type campaign. The 'map' consists of a bunch of nodes, and each side has a number of armies. Each army may attack an enemy node - when this happens, the players in that army play a battle against an enemy army. When the battle ends, the result determines who controls that node.
Before I get into the technicalities, let me throw out some more ideas. The results of these battles should have real-time effects on other battles that are still being fought. The most basic use of this is to have players fighting a battle alerted to how other battles are progressing. I think it'd be awesome to hear radio communications as you're fighting - "We've lost the bridge!" "An attack on the gate has been defeated." And knowing that when you finish your fight, everyone else will hear about it.
More advanced uses include actual effects - say you win a battle for a node containing a missile silo. Then commanders in other battles gain access to a missile barrage from the silo.
Okay, now for the problems. Each node may represent a district in a city, or another planet. Each node should be represented by a mission - so each battle needs to happen on a separate server. The battle map itself, where you can see all the sectors and launch attacks, will need to be another server again - a 'master server' of sorts. Each battle sends its results to the master, which then notifies the other servers.
Is it possible to communicate between servers like this?
Also, the problem arises of who hosts the battle servers. My first thought was that players should host the servers - if you initiate an attack, you're hosting. However, players shouldn't be relied upon to host battles that will affect the result of a larger game, should they? It would just be an invitation for griefers - go into a campaign, launch an attack, then shut down the server.
On second thoughts, that's not as bad as it sounds. If a battle is shut down, the result should just be a tie - then someone else more reliable could recommence the attack.
And one more question. My idea is to have the master server basically act as a big lobby for the players. So if their army is not attacking or defending, they'll hang out there chatting. I assume it's possible for a large number of players to be on a server - I've heard there's no limit. Especially if there's no action happening to clog up the network - just chat messages back and forth.
Just checking...
So, for those who didn't want to read the long text:
-Is it possible to send messages between servers, which cause in-game events to happen?
-Is it good design to give host players the power to affect the game for a far larger number of involved players?
This is fine - the server simply loads the correct missions one after the other.
However, you can't create a very complex campaign with only this limited linear progression. Even with branching mission trees, which add a lot of depth, there's something to be desired. Yes, I know I ask a lot.
My idea is to have multiple battles happening at the same time. The most basic example of this is a 'warzone' type campaign. The 'map' consists of a bunch of nodes, and each side has a number of armies. Each army may attack an enemy node - when this happens, the players in that army play a battle against an enemy army. When the battle ends, the result determines who controls that node.
Before I get into the technicalities, let me throw out some more ideas. The results of these battles should have real-time effects on other battles that are still being fought. The most basic use of this is to have players fighting a battle alerted to how other battles are progressing. I think it'd be awesome to hear radio communications as you're fighting - "We've lost the bridge!" "An attack on the gate has been defeated." And knowing that when you finish your fight, everyone else will hear about it.
More advanced uses include actual effects - say you win a battle for a node containing a missile silo. Then commanders in other battles gain access to a missile barrage from the silo.
Okay, now for the problems. Each node may represent a district in a city, or another planet. Each node should be represented by a mission - so each battle needs to happen on a separate server. The battle map itself, where you can see all the sectors and launch attacks, will need to be another server again - a 'master server' of sorts. Each battle sends its results to the master, which then notifies the other servers.
Is it possible to communicate between servers like this?
Also, the problem arises of who hosts the battle servers. My first thought was that players should host the servers - if you initiate an attack, you're hosting. However, players shouldn't be relied upon to host battles that will affect the result of a larger game, should they? It would just be an invitation for griefers - go into a campaign, launch an attack, then shut down the server.
On second thoughts, that's not as bad as it sounds. If a battle is shut down, the result should just be a tie - then someone else more reliable could recommence the attack.
And one more question. My idea is to have the master server basically act as a big lobby for the players. So if their army is not attacking or defending, they'll hang out there chatting. I assume it's possible for a large number of players to be on a server - I've heard there's no limit. Especially if there's no action happening to clog up the network - just chat messages back and forth.
Just checking...
So, for those who didn't want to read the long text:
-Is it possible to send messages between servers, which cause in-game events to happen?
-Is it good design to give host players the power to affect the game for a far larger number of involved players?
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
1. Yes it's very possible to get servers talking with each other, in Torquescript there is a TCPObject that can get you communicating with just a few lines of code - personally I prefer to use Python to code my backend servers as you don't need all the extra weight that TGE adds for things like chat servers, master servers, etc.
2. No it's generally not a good design to allow players to host matches, it gives them copies of your server code which leaves you open to them hacking game play, giving themselves an unfair advantage or just plain abuse of the game - unfortunately if there is a way to exploit things someone will try and do it. Which is why all succesful games that have game play like you describe rely on hosting the servers themselves.
07/16/2008 (2:19 pm)
Daniel - 1. Yes it's very possible to get servers talking with each other, in Torquescript there is a TCPObject that can get you communicating with just a few lines of code - personally I prefer to use Python to code my backend servers as you don't need all the extra weight that TGE adds for things like chat servers, master servers, etc.
2. No it's generally not a good design to allow players to host matches, it gives them copies of your server code which leaves you open to them hacking game play, giving themselves an unfair advantage or just plain abuse of the game - unfortunately if there is a way to exploit things someone will try and do it. Which is why all succesful games that have game play like you describe rely on hosting the servers themselves.
#3
Unless you've gone to special lengths to pull out all the server code, your users have your server code anyways. Most of the classes involved in Torque networking and simulation have both the client and server half of functionality in them (NetInterface, GameConnection, etc.)
Any sophisticated hacker can disassemble these pieces and see how the server works, more or less.
For the 1.3 code base, it's fairly non-trivial to refactor all these pieces out and ship only the client functionality with the client. Also, in so doing, you have to go to further lengths to keep "standalone" mode still functioning (if you need that for testing).
It's better not to worry about that, because a determined hacker will be able to figure it out whether they have the code or not (they will reverse engineer the protocol from the network packets). Torque makes it pretty hard to cheat just from the client. Solid security comes from making it impossible to cheat, given the inputs from the client, and the outputs from the server... whether the hacker has the server code or not.
That's seperate from the question of hosting though... if users are hosting their own servers, there are plenty of ways for them to get an advantage which aren't even all that sophisticated (they can artificially increase latency for other players, they can use reflectors, they can use packet rewriting, etc.)
Sorry if I'm being a little pedantic.
07/17/2008 (10:46 am)
Quote:
2. No it's generally not a good design to allow players to host matches, it gives them copies of your server code which leaves you open to them hacking game play, giving themselves an unfair advantage or just plain abuse of the game - unfortunately if there is a way to exploit things someone will try and do it. Which is why all succesful games that have game play like you describe rely on hosting the servers themselves.
Unless you've gone to special lengths to pull out all the server code, your users have your server code anyways. Most of the classes involved in Torque networking and simulation have both the client and server half of functionality in them (NetInterface, GameConnection, etc.)
Any sophisticated hacker can disassemble these pieces and see how the server works, more or less.
For the 1.3 code base, it's fairly non-trivial to refactor all these pieces out and ship only the client functionality with the client. Also, in so doing, you have to go to further lengths to keep "standalone" mode still functioning (if you need that for testing).
It's better not to worry about that, because a determined hacker will be able to figure it out whether they have the code or not (they will reverse engineer the protocol from the network packets). Torque makes it pretty hard to cheat just from the client. Solid security comes from making it impossible to cheat, given the inputs from the client, and the outputs from the server... whether the hacker has the server code or not.
That's seperate from the question of hosting though... if users are hosting their own servers, there are plenty of ways for them to get an advantage which aren't even all that sophisticated (they can artificially increase latency for other players, they can use reflectors, they can use packet rewriting, etc.)
Sorry if I'm being a little pedantic.
#4
07/17/2008 (2:39 pm)
I don't think it's being pedantic at all Tim... just further expansion and clarity on things.
#5
Devon - I'm kind of unsure about master server stuff, but thanks for the tip. I didn't know to what extent the example scripts will help me, but now it seems they'll be valuable.
Andy - Thanks, I'll look into TCPObject. I'll also have to look into what master server functionality I want, and how to get it.
With regard to security... I'm guessing that al these issues will exist no matter who hosts a server. If they're hosting a server as part of a larger group of linked battles, then it's a shame, and it affects more players than if it was just a stand-alone server. Tim, it's strangely comforting to know what hackers will be able to do their thing with or without the server code, because I wouldn't know where to begin to strip it all out :P. Also, is it that desireable? If the game is distributed without server code, then players can't host their own games at all, right?
>>Solid security comes from making it impossible to cheat, given the inputs from the client, and the outputs from the server... whether the hacker has the server code or not.<<
I'd guess that that kind of security doesn't come along every day...?
And I agree, you weren't being pedantic at all, just informative ;)
07/17/2008 (9:43 pm)
Thanks for the info, everyone!Devon - I'm kind of unsure about master server stuff, but thanks for the tip. I didn't know to what extent the example scripts will help me, but now it seems they'll be valuable.
Andy - Thanks, I'll look into TCPObject. I'll also have to look into what master server functionality I want, and how to get it.
With regard to security... I'm guessing that al these issues will exist no matter who hosts a server. If they're hosting a server as part of a larger group of linked battles, then it's a shame, and it affects more players than if it was just a stand-alone server. Tim, it's strangely comforting to know what hackers will be able to do their thing with or without the server code, because I wouldn't know where to begin to strip it all out :P. Also, is it that desireable? If the game is distributed without server code, then players can't host their own games at all, right?
>>Solid security comes from making it impossible to cheat, given the inputs from the client, and the outputs from the server... whether the hacker has the server code or not.<<
I'd guess that that kind of security doesn't come along every day...?
And I agree, you weren't being pedantic at all, just informative ;)
#6
When it comes to security you can start to become really obsessive about it and spend years trying to stop the hackers but what you have to really consider is how secure you want your game to be, mostly the hackers that are smart enough to be reverse engineering packets of data and building up a picture of your protocols, etc are going to be doing that for big games like WoW, etc, rather than your small indie effort. If you reach a point where you've got hackers doing things like that then great... it means you should also have the cash to employee a C++ coder to rip out all that code then.
So I'd suggest you're targetting security features at your average Joe or at kids who do like to dabble and hack around with things so even simple measures like stopping them hosting games themselves will solve most of your security issues.
In terms of that kind of security coming along every day really it does, it's just about designing your game correctly, to give examples:
- The server should check all messages from the client are valid, for example if the client says fire this gun the server must check the user actually has that gun, has ammo for it and it's equipped.
- The server shouldn't send more information to the client than it needs to - for example if you send a list of all the locations of every other player it would be very easy for someone to draw a map of where they all are and could be used to cheat.
Just a case of thinking about things.
07/19/2008 (4:54 am)
Daniel - you'll find a few resources on here for creating your own master server in a variety of languages, they're worth having a look at to get an idea of how TGE works with a master server and if you look at the python master server I wrote here I added a brief description of the process for clients and servers.When it comes to security you can start to become really obsessive about it and spend years trying to stop the hackers but what you have to really consider is how secure you want your game to be, mostly the hackers that are smart enough to be reverse engineering packets of data and building up a picture of your protocols, etc are going to be doing that for big games like WoW, etc, rather than your small indie effort. If you reach a point where you've got hackers doing things like that then great... it means you should also have the cash to employee a C++ coder to rip out all that code then.
So I'd suggest you're targetting security features at your average Joe or at kids who do like to dabble and hack around with things so even simple measures like stopping them hosting games themselves will solve most of your security issues.
In terms of that kind of security coming along every day really it does, it's just about designing your game correctly, to give examples:
- The server should check all messages from the client are valid, for example if the client says fire this gun the server must check the user actually has that gun, has ammo for it and it's equipped.
- The server shouldn't send more information to the client than it needs to - for example if you send a list of all the locations of every other player it would be very easy for someone to draw a map of where they all are and could be used to cheat.
Just a case of thinking about things.
Torque Owner Dusty Monk
Windstorm Studios
The answer to your first question is definitely yes. You can totally set up a system of transmitting messages from server to server -- though it's going to take having a programmer get savvy with the networking code and not being afraid to build some systems. If it were me, I'd start with looking at the Master Server code in the First Person Shooter starter kit -- the stronghold game. It already has the notion of a Master Listener server. When you host an individual game, it connets to the master server, and registers itself with it. Players can connect to the master server, and see what games are being played, and then connect to those specific games. So see, there's already a framework there for you to start with in building a Server to handle servers.
As for your second question -- is it good design to allow host players to modify the game at a large scale -- well, what you're asking is "will my game be fun". And the *only* way to learn that is to implement the design, and then iterate.. iterate.. and then iterate some more. Is it fun for you? Do the people that try it out think it's fun? It kind of sucks in a way because if you want to try something innovative, you have to do an extraordinary amount of work before you can even ask the question. But that's the joy of game design. There are no shortcuts.
Good luck!