I have a question about how characters (player objects, if you want to call them that) are handled in games. Are they typically allowed to occupy the same space in the game world (or game map), or is it common practice that a single player's character occupies a spot and no other character can occupy the same spot until that occupier moves from it?

I'm trying to get a grasp of how things take up "space" in a game (or how is this simulated?). I know there is collision, which makes me believe that characters/objects can only occupy a space that is empty and thus things can be "collided". How is this handled in a typical 2d game? Is it handled differently in modern 3d games (like a typical FPS)? When you remove the layers of graphics from a game are they allowing multiple characters (or objects) to occupy the same point in the game space or no?

I'm struggling with this for some reason.

If a typical 2d game uses an array to keep track of tiles, are they placing multiple characters in a single tile? If I'm not clear in what I'm asking, I apologize. It's late.

Are there any references or articles I can read about how player characters are placed in game worlds in regards to how many are allowed to occupy the same point in space?

It is possible to occupy the same space without collision, yes. The prime example is spectator mode in Counter-Strike 1.6 released over 10 years ago. But I guess it's more of a drawing illusion since any object can be placed in a single location in RAM per object.

3D spaces are not typically represented by grids of elements that contain one or zero objects. A 3D "space" is theoretically composed only of its terrain collision information. Each entity contains its own data on its position and rotation. You have to tell the game explicitly how to prevent the entity from overlapping solid parts of the world, and you have to tell the game explicitly what to do if one entity has similar position data to another entity.

You can do the same in a 2D space. Make a small tilemap and then have a 2D array of collision values for the tiles (true = passable, false = solid, etc). Then add entities that contain their own position data. You have to explicitly code in the collision testing: you have to tell the game that if the player tries to move to a tile that is 'solid' then it shouldn't be allowed, and you also have to tell it that if another entity is in the way, don't allow the movement. The tiles are not containers for the entities.

In almost every single game I've ever played, player characters are always non-solid entities like any other non-solid entity, that only collides with other solids. In a 2D game, you can make a z-axis (third dimension) simply by controllng the draw order on the screen. Player characters, if drawn last, will be on top of everything. If you want to be able to move behind some textures, it should be possible to do this simply by rendering them after the player and making sure they are non-solids.

Depends on the game. COD does have player colliders. Some MMOs (like warcraft) have absolutely no player collisions, so multiple people can occupy the same space. In the former it allegedly creates tactical play (blocking a doorway), and the latter prevents griefing (big groups of people making the market place unreachable because they crowd around the entrance).

In terms of implementation, typically you have separate collider geometry that goes along with your player geometry. Usually it's less complex because it's only to detect if something is colliding with it, which doesn't need to be as detailed as the geometry that shows the wrinkles in your player's clothing. This would usually all be handled by a physics engine- Bullet/Havok/Physx etc.

In a demo fps from a game engine, it could be as simple as a capsule shape representing the player. The more complex the geometry, the harder/slower it is for the game engine to use it, so it's typically a mix of primitive shapes to cover the main areas of the body, probably more detailed geometry on the scene itself, usually excluding stuff like plants.

as stated above the typical architecture is as follows:

1. a "world map". in 2d, this is a tile map of the world, implemented as a 2d array of tile types. in 3d its a "level / area / chunk" map. 3d mplementations vary widely depending on game type. the world map stores info for collisions. in some cases it can be used for both graphics and collisions. 2d tiled movement with collision based on tile type is an example. the tile type info in the 2d map contains all the info required for tiled movement collision checks. all you do is decide what type of tiles are impassable.

2. one or more entity lists. either one for both npc's and players, or sometimes one for players, and one for enemies. in a single player game, the "list" of players may be just a single "player" object or data structure or set of variables. entity info includes location: x,y,z in 3d, or tile x,y in 2d.

moving an entity consists of moving the unit (or all units depending on algo), then checking for collisions vs both the world map and the other entities in the game, usually both player and non player entities. As you can see, the MMO example of no PvP collisions is a special workaround for a special case.

so in 2d, the map is a 2d array and it contains tile types as data. and the player has an x,y position, which is what tile they are on. ie: player x = 1. player y = 5. player tile type = tilemap[1][5].

in 3d, the player has an x,y,z and the "tilemap" boils down to a list of 3d "bounding shapes" (such as boxes and spheres) which is often derived from some sort of spatial representation of the scene such as tree. in essence, collision checks are run vs the list of "bounding shapes" determined to be "nearby" by use of some more complex 3d "world / level map". again, checks are made both against the world map and the entities list(s).

Depends heavily on the type of game obviously, the general rule of thumb is to have a "map" or "world" object, perhaps containing a map, the name and architecture doesn't really matter that much. The general point though is some object is responsible for containing the game world objects and handling their movement and interactions with each other.

For instance if you were making a game like a Snake clone the way the world may be represented is far different since the map is divided into a grid and may either only be able to contain one object or may have a short list, in a 3d mmo or something interactions may be different between objects. Code wise there's nothing really saying objects can't exist in the same place, it's just a constraint that may be placed on some game objects either for gameplay or to simplify the code.

Thanks so much for all your replies. Everyone has had great answers to my questions and this is helping me greatly to understand. I knew that the way games handled this varied depending on the type of game. Khatharr's reply was very helpful to me. I seem to be thinking of 3d spaces as grids that contain objects inside them, when you guys are telling me that they are not. If a 3d grid does not contain objects inside of it, then what keeps the object inside the grid in the first place? Is this just an illusion being created by the graphics engine? What keeps the object from just floating away into another spot? Obviously the object itself has to have some information that tells the game engine where it belongs... right? Am I on the right track here? Is this how I should be thinking of these things?

3D spaces are not typically represented by grids of elements that contain one or zero objects. A 3D "space" is theoretically composed only of its terrain collision information. Each entity contains its own data on its position and rotation. You have to tell the game explicitly how to prevent the entity from overlapping solid parts of the world, and you have to tell the game explicitly what to do if one entity has similar position data to another entity.

You can do the same in a 2D space. Make a small tilemap and then have a 2D array of collision values for the tiles (true = passable, false = solid, etc). Then add entities that contain their own position data. You have to explicitly code in the collision testing: you have to tell the game that if the player tries to move to a tile that is 'solid' then it shouldn't be allowed, and you also have to tell it that if another entity is in the way, don't allow the movement. The tiles are not containers for the entities.

I follow you on what you said about 2d space. I'm developing a 2d game that does exactly this. It's the simplest way I could think of to contain and restrict an object... but there I am again thinking of the grid as a container. I understand the concept of a grid and each sector of the grid can have information that says whether or not the sector is passable (or if it's solid). The object (or entity) can have information that says it is located on sector x3, y2. In order to move one space upward the space to be moved into would have to be checked to see if it were solid. So, I get this. But isn't the sector (x3,y2) still technically containing the object for the moment that the object is located there? I may not be storing the object information in the sector data but for all intents and purposes, If my object is located there... it is effectively containing it there, right? I guess in this type of 2d world, there would be no sense in storing the object in the sector... since the object itself stores it's own information.

Thanks again, If I'm confusing the issue it's only because I'm bouncing it up against all the walls in an attempt to really understand it.

Thanks, Runonthespot. Wow, so some games have no player collisions? That explains the player overlap I've experienced in some games. I didn't realize they simply didn't have player collisions. Thanks so much, you've filled a void I had. So it's all about geometry for collisions and some games allow multiple characters in a single spot. In addition, the characters contain their own location data typically, and the engine is constantly checking to see if one character is located where another character is (and adjusts accordingly).

Depends on the game. COD does have player colliders. Some MMOs (like warcraft) have absolutely no player collisions, so multiple people can occupy the same space. In the former it allegedly creates tactical play (blocking a doorway), and the latter prevents griefing (big groups of people making the market place unreachable because they crowd around the entrance).

In terms of implementation, typically you have separate collider geometry that goes along with your player geometry. Usually it's less complex because it's only to detect if something is colliding with it, which doesn't need to be as detailed as the geometry that shows the wrinkles in your player's clothing. This would usually all be handled by a physics engine- Bullet/Havok/Physx etc.

In a demo fps from a game engine, it could be as simple as a capsule shape representing the player. The more complex the geometry, the harder/slower it is for the game engine to use it, so it's typically a mix of primitive shapes to cover the main areas of the body, probably more detailed geometry on the scene itself, usually excluding stuff like plants.

Thanks, Runonthespot. Wow, so some games have no player collisions? That explains the player overlap I've experienced in some games. I didn't realize they simply didn't have player collisions. Thanks so much, you've filled a void I had. So it's all about geometry for collisions and some games allow multiple characters in a single spot. In addition, the characters contain their own location data typically, and the engine is constantly checking to see if one character is located where another character is (and adjusts accordingly).

The problem is you're mixing logic here, for all intents and purposes in code anything that is drawn on the screen is seperate from the logical representation of it. To think of it like this, the graphics device and the library you use to work with it basically keeps its own coordinate system, you feed vertices and information into it and it simply draws whatever you like onscreen. The rendering library has no real rules about what an object is, it's like a giant paintbrush that just draws where you like, you can even place vertices in the same coordinate point.

Now if you think of it like that, you can also think of it like a camera, basically the job of the drawing part of the game is to take a "snapshot" of the current state of your game and translate that into a visual. Of course the library itself doesn't do that, you have to write the code to generate those instructions yourself, but if you think about it that way you can basically see that the part that really matters is the logic part of the code.

The logical part of the code is what you create yourself, it's not unusual for you to create your own coordinate system and handle how objects can move in those coordinates and interact with each other. You basically make your own rules for that. When it comes time to draw it all you have to do is convert it into drawing commands, telling the rendering code where the objects are and how to represent them. So really the rules of the game are up to what you decide.