Who controls my player's movement?

Question

In my game, does my player object control the movement, or does the map object control it? (Or some other object?)

The player doesn't know about the map's contents to stop at solids, interact with objects etc. Am I doing it wrong?

I'm currently dispatching data from a virtual joypad.

EDIT:

What if I dispatched movement notifications to my player and had it check with the map before moving, but the player would do the actual moving? Would that work?

EDIT2:

At this point I'm thinking about a top down game. Just to clarify, I want the player to move in 4 directions, not 8, and to be centered on the tile which they are standing on.

Answer 1

My approach to this is two-fold

• First, I abstract the source of control for every game object. That lets me implement a "user controlled entity", which takes input from gamepad/keyboard/mouse/etc for the player entity, and implement AI routines for NPCs.
• Second, each entity can only express an "intent" ... so the output from the abstracted control object in point 1 only says, "I want to move in that direction". That intent is then implemented by some other routine which checks against map details, does collision, etc.

Answer 2

Depends on the type of game. For a platformer, your movement is basically a large series of hacks, comprised of a lot of ray tests and highly specialized logic. For a top-down action game, you should have a basic physics/collision system that's independent of any particular type of game object, and player controls just set velocities/forces that move the avatar in the indicated direction. Other types of games have other types of controls and use less or more physics engine as appropriate.

In general, though, you have some kind of concept of a physics object. Players, enemies, items, etc. all have a physics component. This component in tandem with the physics engine (which knows about the level layout, among other things) will "correct" motion in response to collision. The player component then responds to movement requests by setting forces, which push the player around, and the physics component deals with things like "the object is moving into a wall, push it back out again and adjust accordingly."

If you provide more information on what exactly you're trying to do, someone may be able to provide a more detailed answer.

Answer 3

you can implement your object control in map calss, but that would create some god object and it'll be too difficult to debug or add features your program in future. there are two approches for this problem :

1- one is to handle all the inputs in the player class, and then ask map to move your player as player calculated, this can also be applied for any other dynamic or static objects in your scene. note that in this apprich map class only check for collision or other similar things , and doesn't care how or why is the object moving.

2- you can also share all map data with other dynamic classes (using physics engine and creating an object for every child of map is a way of doing this) and check all the thing you have to consider while moving objects inside their own class.

the first approch is much more simpler and take less time to implement, because you consider all your object the same and move them in a same manner, but in the second aproch you have much more flexibility with your obejects moving (for example you can make some object to ignore collsion)

Answer 4

There is really no right way to do this, because you are talking collisions and character control it really boils down to exactly the problem you are trying to solve, as no matter your approach you are going to have to look at your game mechanics and see if it fits ( order of resolution etc.. ).

My approach to this problem and as it seems you want to keep a certain level of abstraction would be to different layers that process the player data, so if your player controlled object has a velocity and a direction then these would be updated based on the input, these inputs are not checked against anything, the input knows about the player object and simply updates its values, this would be your first layer.

After this first stage is done, your map system then needs to scan through the data and validate it, at this point all controller input has been resolved, the map can then decide to accept or change the forces ( velocity and direction ) associated with player entity based on collisions, wind, whatever can affect the player movement, this is your second layer that affects the data.

The last and final stage would be to simply update any entities position based on their direction and velocity ( as is ), this movement is assumed correct, this could mean the velocity is 0 because he collided with a wall, or he is now being taken on the opposite direction by a river he stepped in.

The key in this type of solution is to have different layers that affect your data, after each successive stage your data is assumed correct and valid for all previous stages, which means each processing stage could be designed to be plugged in and out at run time and even re-ordered.