Should the entity handle his own movement?

Question

I am currently building a simple turn based game with a Room consisting of a 2D array of Tile objects. Those can be WallTile or FloorTile. Tile objects have a north, east, south and west Neighbour. The FloorTiles have a Stack of Entities so I can easily draw the top entity.

Now I am wondering, my Player is an Entity, when the player moves, should the player handle that logic, or the Game that holds my Player?

In the first case it would be something along the lines of:

class Player : Entity {
    public Tile CurrentLocation

    public bool CanMoveTo(Direction) {
        // Let's say that direction is East
        return CurrentLocation.EastNeighbour == FloorTile
    }

    // This method does the actual move
    public void MoveTo(Direction)
}

In the second case it would be like this:

class Game {
    public Player Player;
    public Room Room;

    public void Update() {
        // Lets say we get direction from some input from somewhere
        if Room.TileAt(player.Y, player.X) is FloorTile then MoveThere()
    }
}

I am not quite sure what the nicest of the two options is. Initially I am thinking about the first solution. Any help or tips would be appreciated.

Answer 1

There are no right or wrong ways to do things. Only ways which work for you or don't work for you.

There are several competing philosophies in mainstream game architecture.

A: Object-oriented architecture

Every entity should be represented by an object. Those objects should contain all of their own logic, encapsulate their internal state and communicate with other objects through well-defined interfaces. The core game engine just calls the "Update" and "Render" methods of all entities in a loop and then lets the entities do the rest.

When you have objects which share some functionality, you would usually do that through inheritance - by extracting the common functionality into a common base-class. For example, you might want to have a class Player and a class Enemy which both inherit from a class Combatant which contains all the combat code and inherits from Entity which contains the basic code for movement. And Enemy would likely be an abstract class which contains only the logic common to all enemies, with the different enemy types and their unique behaviors implemented in classes inheriting from Enemy.

Basically the way you are supposed to do OOP by the book.

This style is frequently seen in developers who came from application development, because it's the predominant style there. And what works for applications is not necessarily completely wrong for games.

B: Entity-Component architecture

This style prefers composition over inheritance. An entity isn't one object, it is a collection of objects with each object implementing a different feature of that entity. So you don't have a "Player" class implementing every single thing a player can do. You have a generic Entity with a "Sprite", a "Mover", a "Shooter", a "Hitpoints" and a "PlayerInput" component.

The advantage of this approach is that components are very easy to mix and match to create new kinds of game entities. This is pretty useful for rapid iterations on your game design. It's the favorite approach by some popular game engines. Like Unity, for example.

C: Entity-Component-System architecture

An entity should be a collection of components just like in the "Entity-Component" architecture. But in this architecture, those components should just be dumb data-holders. Usually in form of structures with only public variables and no methods. All the logic should be in systems. Each system is responsible for managing one type of components, or a set of components. For example, you have a MovementSystem which updates the Position component of every entity with a Movement component.

But this is just an oversimplification. If you want to know more, check out the question "What is pure ECS?". You might also look at other questions under our entity-component-system tag.

The ECS approach is currently very in fashion. The main argument for it is that it allows some very neat performance optimizations (particularly when it comes to memory locality and multithreading) without sacrificing the modularity and iteration speed of the Entity-Component approach. But the disadvantage is that a solid and flexible ECS architecture requires quite a lot of architecture code which runs "behind the scenes" and which can be difficult to implement for beginners.

Which one should you use?

That's something you need to figure that out on your own. But whichever approach you choose for your game, you would be well-advised to stick to it. Avoid mix-and-matching architecture patterns in your game when feasible.

Answer 2

It basically depends on the amount of data traversing your game network. Any massive multiplayer needs to keep track of who is where doing what always (otherwise massive cheating will ensue). However, receiving and sending packets from the server to every and each client (what is known as an authorative server) is seldom practical for any amount of significative users. So, the philoshopy seems to be how much logic you can get the player to control without affecting other players. In other words, what affects you and only you (except for looting) can be handled by the client. Whereas whatever affects several players must be handled by the server. Or, if not handled, al least authorized before any effect ensue.