Structure GameObject - States - Visual representation

Question

Question: What is the best data structure for GameObjects that have different states and thus different visuals?

The situation is:

I'm creating a game for mobiles (written in Kotlin, no Engine used).

My simplified object structure looks like this:

I have 2 GameObjects (e.g. Person and Obstacle)

Each GameObject might have two different states (IDLE and MOVE)

But each state might also have different graphics. For instance depending on the movement direction, the MOVE state might show Bitmap-Left or Bitmap-Right.

Person -> WALK-State -> Visualisation (WALK, PERSON) -> draw(bitmap_walk_left_person)

My problem is, that I'm really not sure about that structure. Should I make subclasses for each State or a composition? One Visual object for each State (e.g. MOVE, IDLE, TALK) containing all Bitmaps for Person and Obstacle and always showing the right one depending on the parent?

Currently it looks like this:

I have the GameObject. The object has a state that is called in the update() method (e.g. moving a bit to the left). Every State has a "Visual" object that knows its parent State (State = WALK). It draws itself related to its states type (e.g. WALK) and considers (if needed) the orientation (left or right).

This felt like it keeps structures as abstract as possible but I'm not sure sure thats a good solution because all objects have to keep references to their "parents". So the visuals need a reference to the state (WALK) and to the GameObject (Person) in order to draw the visual for a walking person. Would it be better to create subclases for each State? So I have a class "VISUAL_MOVE_PERSON", "VISUAL_IDLE_PERSON", "VISUAL_IDLE_TREE" ... That seems a lot of redundant code and classes.

Is there a common structure for Actions / States and their Visual Representation? Especially since I will have many more objects with at least a few different states (IDLE, MOVE, TALK, ...)

Should the visuals be part of each state? Or are they independent to each other (e.g. GameObjects have a State and a Visuals object) instead of the "chain of references" shown above?

Answer 1

This is usually handled in a data-driven fashion. By treating your visuals as data objects, you end up with less code micro-managing which visual to use, and you open the possibility of being able to change your art, add more character types, or even allow your game to be modded by players, just by changing data files, without editing & recompiling your source code.

There are a lot of forms this could take:

• you could have a Spritesheet data object that maps a key representing a visual state to its corresponding graphic/region of an atlas. Each character type would have its own instance of this data structure, indexing only its own visuals.

• you could have an Animation data structure that knows the particular sequence of sprites to display for one action (which can help decouple your game logic from rendering logic when showing change over time). Your visual data for a single character would then be a collection of Animations for each state.

• for maximum decoupling, you could build an Animation State Machine that keeps track of a collection of Animations and the triggers to switch between them. Now your gameplay & AI logic doesn't need to know anything about sprites or animations at all — it just sends events to its state machine and it handles the necessary visual transitions.

In all of these cases, the visual structure doesn't know anything about the kind of entity it's representing, it just exposes something like a SetState method where we can inject a signal that it can use to choose the right representation from its collection of data.

So

frog.animation.SetAnimationState(JUMP)

and

player.animation.SetAnimationState(SWING_SWORD)

Are the same code running in the same animation class but just different instances with different data.

In general, any time you're tempted to make a subclass for each variety of thing in your game, it's a good time to check if any of it can be handled by different instances of data objects instead.