"Commander Mode" design discussion (brainstorming)
by Stephen Zepp · in RTS Starter Kit · 12/24/2004 (4:18 am) · 6 replies
The purpose of this thread is to be a free-form discussion on possible designs for a "commander mode".
Base assumptions
1) This design is targetted against a specific set of game mechanics:
--dedicated server/client enviroment (not required, but most appropriate)
--asynch login (players can join game at any time)
--persistent team assignment: teams are pre-defined on the server prior to a player logging in, and they will either already be assigned a team, or will be invited to join one. In either case, team membership must already be implemented as a persistent state.
--"hybrid" game genres, such as RTS/FPS, RTS/RPG, or a combination of one or more base genres.
2) Certain players will be assigned the authority to direct other player's gameplay. This is in a "request" mode, in that a commander can request players to perform certain in-game actions such as move to a location, attack a specific target.
--orders can be completely ignored
3) Commander players will be using "normal" RTS SK camera, selection capability, and general functionality
4) "avatar/troop" players will be using standard (non-integrated) camera modes, such as provided by the advanced Camera resource (or stock camera capability in TGE 1.3), or RTS camera modes as appropriate.
Vision
While in commander mode, players can treat all visible units on their map that are on their team as RTSUnits, being able to select, view, and issue orders without regard to them being true RTSUnits, or other "live" players.
When a player is playing in "troop" mode, and an authorized commander on their team issues them an order, they will be given a visual representation of the order, such as a marker on the terrain, or a visual indication of which targets to attack. They are not in any way required to actually follow these orders, and can clear any orders from their scene manually if desired. "Troop" players may also request orders from their commander, or simply operate on their own as desired.
NOTE: A "troop" player is not required to be in FPS/RPG mode, but can be an RTS style player as well.
General Requirements
--network performance should have the lowest possible bandwidth impact.
--Clients are responsible for any rendering/visual representation requirements.
--whenever possible, stock RTS SK functionality should be used. Minimal impact to FPS/RPG playstyles is required as well.
Discussion
When a player in the RTS SK using RTS playstyle issues commands to their units, a commandToServer function is called sending to the server the current selection set, and the order itself. The server script catches this command, and sets each unit to perform the command, and then broadcasts the event (via RTSAttackEvent/RTSMoveEvent networking) to all clients.
We can use this exact same process, but modify the server scripts to determine if each of the units within the current selection are actual RTSUnits, or real players. In the scenario where 1 (or more) of the "units" selected is in fact a player, we would over-ride the Event broadcast, and instead send an RTSOrderEvent to the appropriate player directly. The client that receives this event would be required to display the command appropriately on the client's scene.
NOTE: The RTS SK already provides us with the ability to send team "map ping" events, and we may be able to alternatively use that existing functionality instead of what is described above. Personally, I think that the above description would be more seamless to the commander, but alternatives do exist.
Ok, that's my initial thoughts...time for everyone to jump in!
Base assumptions
1) This design is targetted against a specific set of game mechanics:
--dedicated server/client enviroment (not required, but most appropriate)
--asynch login (players can join game at any time)
--persistent team assignment: teams are pre-defined on the server prior to a player logging in, and they will either already be assigned a team, or will be invited to join one. In either case, team membership must already be implemented as a persistent state.
--"hybrid" game genres, such as RTS/FPS, RTS/RPG, or a combination of one or more base genres.
2) Certain players will be assigned the authority to direct other player's gameplay. This is in a "request" mode, in that a commander can request players to perform certain in-game actions such as move to a location, attack a specific target.
--orders can be completely ignored
3) Commander players will be using "normal" RTS SK camera, selection capability, and general functionality
4) "avatar/troop" players will be using standard (non-integrated) camera modes, such as provided by the advanced Camera resource (or stock camera capability in TGE 1.3), or RTS camera modes as appropriate.
Vision
While in commander mode, players can treat all visible units on their map that are on their team as RTSUnits, being able to select, view, and issue orders without regard to them being true RTSUnits, or other "live" players.
When a player is playing in "troop" mode, and an authorized commander on their team issues them an order, they will be given a visual representation of the order, such as a marker on the terrain, or a visual indication of which targets to attack. They are not in any way required to actually follow these orders, and can clear any orders from their scene manually if desired. "Troop" players may also request orders from their commander, or simply operate on their own as desired.
NOTE: A "troop" player is not required to be in FPS/RPG mode, but can be an RTS style player as well.
General Requirements
--network performance should have the lowest possible bandwidth impact.
--Clients are responsible for any rendering/visual representation requirements.
--whenever possible, stock RTS SK functionality should be used. Minimal impact to FPS/RPG playstyles is required as well.
Discussion
When a player in the RTS SK using RTS playstyle issues commands to their units, a commandToServer function is called sending to the server the current selection set, and the order itself. The server script catches this command, and sets each unit to perform the command, and then broadcasts the event (via RTSAttackEvent/RTSMoveEvent networking) to all clients.
We can use this exact same process, but modify the server scripts to determine if each of the units within the current selection are actual RTSUnits, or real players. In the scenario where 1 (or more) of the "units" selected is in fact a player, we would over-ride the Event broadcast, and instead send an RTSOrderEvent to the appropriate player directly. The client that receives this event would be required to display the command appropriately on the client's scene.
NOTE: The RTS SK already provides us with the ability to send team "map ping" events, and we may be able to alternatively use that existing functionality instead of what is described above. Personally, I think that the above description would be more seamless to the commander, but alternatives do exist.
Ok, that's my initial thoughts...time for everyone to jump in!
#2
I'm not expecting to develop this particular functionality for our project in a version that would be readily available for the community, but I am more than willing to "lead" a design discussion that could very well develop into a community resource if others are interested in participating!
So, if this is a topic that interests you for your project, jump on in and start discussing any of the specifics, from design assumptions to implementation decisions, and we'll push for another community "domination through collaboration" resource!
In other words, if you are awaiting this thread to turn into a resource you can use on it's own, that's not going to happen without more input from the community ;)
12/27/2004 (12:40 am)
Small bump here, to make sure I was clear about intentions!I'm not expecting to develop this particular functionality for our project in a version that would be readily available for the community, but I am more than willing to "lead" a design discussion that could very well develop into a community resource if others are interested in participating!
So, if this is a topic that interests you for your project, jump on in and start discussing any of the specifics, from design assumptions to implementation decisions, and we'll push for another community "domination through collaboration" resource!
In other words, if you are awaiting this thread to turn into a resource you can use on it's own, that's not going to happen without more input from the community ;)
#3
12/28/2004 (8:25 am)
What you're proposing certainly sounds feasible Stephen. Nothing I've encountered in my efforts makes me think this wouldn't work. 
#4
01/31/2005 (10:44 am)
Reminds me of Salvage game (FPS/RTS style), they have a commander and players-warriors, workers are CPU-brained. Commander issues orders to all guys and builds structures and the technologies.
#5
How would you put back in the 1st person perspective,
as in the Domination mod the camera is set to the god view.
You cant even press 'Alt-C' to get another pespective.
how about when you select a unit and click a "Posess" button you take his view :-)
03/10/2005 (11:52 pm)
Okay, I'll get the ball rolling a bit. How would you put back in the 1st person perspective,
as in the Domination mod the camera is set to the god view.
You cant even press 'Alt-C' to get another pespective.
how about when you select a unit and click a "Posess" button you take his view :-)
#6
07/29/2005 (5:03 pm)
That would be cool.. I hope this is worked on.. I just don't have the time or experience with Torque yet to do this. 
Associate Kyle Carter
class CommandInterface { virtual goHere()=0; virtual doThis()=0; } class RTSUnit : virtual public CommandInterface { } class Player : virtual public CommandInterface { }Then making each class responsible for sending its own orders over and the like?