If you view orxonox like a level designer a small enhancement is missing:
It is quite difficult to define clearly to which party or team ( friend/ neutral / foe/ ... ) an object belongs.
That's why I would like to add the following enhancement:
1. There is already a value "team_" in the ArtificialController class. Since it is the controller who is evil or good - not the spaceship itself.
2. add a value "team_" to the pawn class. Why? Because level designers even want some objects that are not controlled to belong to a party/team. Think of the boxes in MissionOne.oxw - they should get the same colour as the pirate's spaceships. And later the uncontrolled Spacecruiser and HydrogenFarmer both should have the player's colour.
Concerning the variable's name: As far as I know there is no such object that is both a pawn and a controller - so the same name shouldn't be a problem. Of course most spaceships have a controller.
3. Do the colouring and in the gametypes. Therefore I would like to create a new baseclass TeamGametype that takes care of this issue.
4. Adjust the sameTeam() function in the artificial controller.
Is this the right approach? Or should I rather create a new interface?
About friends, foes and teams
Moderator: PPS-Leaders
About friends, foes and teams
Fail. Fail again. Fail better.
Re: About friends, foes and teams
I think it is a good idea to work on this team-thing, since so far it has been a hack and is missing many features and is not consistently integrated.
I like the idea to create an interface (which I believe you have already begun to do), the reason for this is, that I think that the ArtificialController class, conceptually, is the wrong place for a team_ variable and so is the Pawn class. The ArtificialController (as any Controller) is an entity that dictates the behavior of the ControllableEntity it controls. The Pawn is a ControllableEntity that can be killed (i.e. it has 'health'). The Pawn is not, because it is basically a mindless tool that only does what its controller tells it to do. And the Controller is not, because although it decides what the ControllableEntity will do, it is just the tool some player uses to control some thing. I realize that this distinction is much more subtle than with the ControllableEntity. But think of the case where a HumanPlayer is using a (New)HumanController to control his Spaceship (which is a Pawn). The affiliation is dictated by the player, while he uses the controller as a tool to control the ship.
Consequently the PlayerInfo, in my opinion, would be the correct place for this team-functionality, either by inheriting from a special interface or by implementing the necessary methods itself. This becomes more obvious when you think about a normal instance of a game. Each time the player spawns a new Controller and a new ControllableEntity is created and each time the player is killed they are destroyed. But the player (normally) doesn't change teams just because he is killed and respawns.
Now, with this approach you can't solve your problem with the boxes that need to be destroyed. But I think teams are not the correct solution here. What we would want for this case is some kind of objective marker (maybe integrated with quests, or not...) similarly to the checkpoints in space race. (Or rather they would ideally be the same thing just applied for different purposes) To color the objective marker with the players (friendly) color would then just be good level-design.
A new TeamGametype class makes sense, or even integrate some portion of the team functionality into the Gametype class. E.g. introduce a team_ = 0 variable that indicates no affiliation with any specific team, normal (non-team) Gametypes would then just force team_ = 0 for all players and color all players other than the 'current' as enemies.
As a final note: I think it makes sense to not consider the team-functionality as an add-on but as base functionality that can be used in different ways.
I like the idea to create an interface (which I believe you have already begun to do), the reason for this is, that I think that the ArtificialController class, conceptually, is the wrong place for a team_ variable and so is the Pawn class. The ArtificialController (as any Controller) is an entity that dictates the behavior of the ControllableEntity it controls. The Pawn is a ControllableEntity that can be killed (i.e. it has 'health'). The Pawn is not, because it is basically a mindless tool that only does what its controller tells it to do. And the Controller is not, because although it decides what the ControllableEntity will do, it is just the tool some player uses to control some thing. I realize that this distinction is much more subtle than with the ControllableEntity. But think of the case where a HumanPlayer is using a (New)HumanController to control his Spaceship (which is a Pawn). The affiliation is dictated by the player, while he uses the controller as a tool to control the ship.
Consequently the PlayerInfo, in my opinion, would be the correct place for this team-functionality, either by inheriting from a special interface or by implementing the necessary methods itself. This becomes more obvious when you think about a normal instance of a game. Each time the player spawns a new Controller and a new ControllableEntity is created and each time the player is killed they are destroyed. But the player (normally) doesn't change teams just because he is killed and respawns.
Now, with this approach you can't solve your problem with the boxes that need to be destroyed. But I think teams are not the correct solution here. What we would want for this case is some kind of objective marker (maybe integrated with quests, or not...) similarly to the checkpoints in space race. (Or rather they would ideally be the same thing just applied for different purposes) To color the objective marker with the players (friendly) color would then just be good level-design.
A new TeamGametype class makes sense, or even integrate some portion of the team functionality into the Gametype class. E.g. introduce a team_ = 0 variable that indicates no affiliation with any specific team, normal (non-team) Gametypes would then just force team_ = 0 for all players and color all players other than the 'current' as enemies.
As a final note: I think it makes sense to not consider the team-functionality as an add-on but as base functionality that can be used in different ways.
Re: About friends, foes and teams
Hey there,
It's great someone finally tries to solve this miseray. Unfortunately I currently don't have the time to think about this issue, I can not tell you how to do it right or if your approach is good, neither can I review the code which was written so far. But I'll try to write some short notes to explain why there is no "team" value so far, as well as some hints in which direction I would probably go.
First of all, what is a team? Looking at a soccer team, you could say, a team is a bunch of players with the same colored shirt. However if you look at the whole world and take all people that coincidentally wear the same shirt, they probably don't feel like a team. They don't even know each other.
At the same time, some of those soccer players might also be part of another team, for example the "friday evening beer" team in their neighborhood or you could also look at their families as teams.
So what is a team? A team is a bunch of people that are connected in some context.
In Orxonox, we basically try to model this in different ways. The TeamColorable interface allows to model the "same colored shirt". TeamDeathmatch represents the context in which a player can choose a team. But there could be multiple gametypes (e.g. a minigame in the singleplayer campaign) that have different team-options and there's even the possibility to have sub-teams, at least in singleplayer (e.g. the fraction could be a team, but within the fraction some ships are in a formation, which is also some kind of a team).
That's why the "team" is not a member of Pawn and neither a member of Controller. It is part of the context, in our case a map in TeamDeathmatch that maps the players to their teams.
This works good, but only until the players (or AI) need to know their teams. In this case, the AI needs to be aware of the context (gametype) and request the information from there. In theory it would be sufficient to check just the information provided by TeamDeathmatch. Unfortunately, that's not how it is in practice.
Example: The bases in TeamBaseMatch are pawns that can be destroyed, but they are not players, hence they are not in the "player->team" map of TeamDeathmatch.
Another example: DynamicMatch uses teams but doesn't inherit from TeamDeathmatch. Why? I quote Jo: "I want to learn how to implement it myself". And because I thought that's a good idea, I let him do (with the intention to refactor it some day). It's kind of funny that you have to do it yourself now
Anyway, from this point of view it's probably the best solution to keep team information in the gametypes, but it would make a lot of sense if we move the sameTeam function also to the gametype (and make it virtual).
Concerning the boxes in the tutorial level: Why not implementing them like a spaceship (i.e. with a controller) but without the ability to move or shoot by setting the accelerations to 0 and the weapons to none?
It's great someone finally tries to solve this miseray. Unfortunately I currently don't have the time to think about this issue, I can not tell you how to do it right or if your approach is good, neither can I review the code which was written so far. But I'll try to write some short notes to explain why there is no "team" value so far, as well as some hints in which direction I would probably go.
First of all, what is a team? Looking at a soccer team, you could say, a team is a bunch of players with the same colored shirt. However if you look at the whole world and take all people that coincidentally wear the same shirt, they probably don't feel like a team. They don't even know each other.
At the same time, some of those soccer players might also be part of another team, for example the "friday evening beer" team in their neighborhood or you could also look at their families as teams.
So what is a team? A team is a bunch of people that are connected in some context.
In Orxonox, we basically try to model this in different ways. The TeamColorable interface allows to model the "same colored shirt". TeamDeathmatch represents the context in which a player can choose a team. But there could be multiple gametypes (e.g. a minigame in the singleplayer campaign) that have different team-options and there's even the possibility to have sub-teams, at least in singleplayer (e.g. the fraction could be a team, but within the fraction some ships are in a formation, which is also some kind of a team).
That's why the "team" is not a member of Pawn and neither a member of Controller. It is part of the context, in our case a map in TeamDeathmatch that maps the players to their teams.
This works good, but only until the players (or AI) need to know their teams. In this case, the AI needs to be aware of the context (gametype) and request the information from there. In theory it would be sufficient to check just the information provided by TeamDeathmatch. Unfortunately, that's not how it is in practice.
Example: The bases in TeamBaseMatch are pawns that can be destroyed, but they are not players, hence they are not in the "player->team" map of TeamDeathmatch.
Another example: DynamicMatch uses teams but doesn't inherit from TeamDeathmatch. Why? I quote Jo: "I want to learn how to implement it myself". And because I thought that's a good idea, I let him do (with the intention to refactor it some day). It's kind of funny that you have to do it yourself now
Anyway, from this point of view it's probably the best solution to keep team information in the gametypes, but it would make a lot of sense if we move the sameTeam function also to the gametype (and make it virtual).
Concerning the boxes in the tutorial level: Why not implementing them like a spaceship (i.e. with a controller) but without the ability to move or shoot by setting the accelerations to 0 and the weapons to none?
Fabian 'x3n' Landau, Orxonox developer
Who is online
Users browsing this forum: No registered users and 6 guests