Player / Enemy classes
-
drwbns
- Orc Shaman
- Posts: 788
- Joined: Mon Jan 18, 2010 6:06 pm
- Location: Costa Mesa, California
- x 24
Player / Enemy classes
Simple design question - In a multiplayer deathmatch game, how are Player and Enemy determined class wise? Being that all players are players, yet everyone else is an enemy.
-
saejox
- Goblin
- Posts: 260
- Joined: Tue Oct 25, 2011 1:07 am
- x 36
Re: Player / Enemy classes
from the servers perspective there are only players. no enemies.
from client perspective there are teammates, enemies and self.
from client perspective there are teammates, enemies and self.
-
thebluefish
- Gremlin
- Posts: 170
- Joined: Tue Apr 05, 2011 1:55 am
- x 10
Re: Player / Enemy classes
The way I do it, I have a generic "player" class that stores everything such as model, position, orientation, camera info, etc... My game stores a vector of all of these players and tracks them. Although I have a few methods to ensure that the first item in my vector is always my current player, I also always store an index that points to MY player. Then my game can do all the fancy stuff such as hiding the player model, adding the first-person models/animations, attaching the global camera, etc...
During the code inspection, a couple of minor points were noticed: -
Function inlining was critical to performance.
For MSVC, at least, a "delete 0" caused execution of 11 assembly instructions, including a function call. So in cases where performance is at an absolute premium it can be worth inserting the extra manual test.
-
Honas
- Gnoblar
- Posts: 23
- Joined: Thu May 31, 2012 2:09 pm
Re: Player / Enemy classes
You could use an integer (or something smaller 
) to create a "team tag". So every player stores some constant like TEAM_RED or TEAM_BLUE.
For instance, if you make an FPS and have friendly-fire off, you would first check when you hit someone whether he is not in your team. If he isn't, you can drain his life. So you don't necessarily need to create two classes, only one player class. Keep them in a vector or something.
) to create a "team tag". So every player stores some constant like TEAM_RED or TEAM_BLUE. For instance, if you make an FPS and have friendly-fire off, you would first check when you hit someone whether he is not in your team. If he isn't, you can drain his life. So you don't necessarily need to create two classes, only one player class. Keep them in a vector or something.