Game: Component First Steps

08/29/14

I've attempted to make a component system before. I didn't know what I was doing nor did I know what I needed the component system to do. A lack of focus on what I needed now hurt the design, I think. A lack of experience makes knowing what I'll need somewhat far in the future impossible.

Hopefully, this time it's different. One, I've read up a bit more on components, and I can use that reading material as reference now. Further, I'm going to be focusing on refactoring my code as it is now (the game should play the same as before), and the goal is to simply the codebase and make it easier to change and understand.

I'm going to mostly be modifying the Player class found in player.cpp. After this edit, it probably shouldn't be called "Player" anymore, as the content that makes it the player should be decoupled out and put into a controller component. "GameObject"? Hmmm... I'll figure it out.

Currently, the player is made up of these separatable pieces:

• Sprite rendered
• Mouse input event logic
• Physics update (gravity and collision detection)

Some stuff that can stay in the player class:

• x position
• y position
• x velocity
• y velocity
• width
• height

Width and height aren't in there yet, but I feel pretty confident that anything in the game that I would call a "game object" would have those. Some things won't ever have a velocity other than zero, but explicitly stating they don't move is perhaps still useful.

But other than those things, I don't think much more should be stuffed into the class. There's going to be various things that cause acceleration, but it'll be good to encapsulate those things elsewhere. Gravity won't affect all things, and the same goes for wind or what-have-you.

So, the separate components will be:

• Code that renders game object-related stuffs
• Code that sends user-input to the right code
• Code that executes jumping actions (sets velocity)
• Code that enforces gravity on a game-object

Hmmm.... Thinking about how I'm going to do this introduces some... difficulties. Gravity and jumping must be coupled. The way I'm doing jumping will set a Vx and Vy based on the clicked location and the gravity. The logic will set the clicked point along the arc that the user clicked on.

Should there, perhaps, be a component hierarchy? Should components contain their own components? I mean, anything that jumps must be coupled to gravity, but not all things connected to gravity will jump.

Hmmm....

• Gravity
  • Jumping
    • Something that triggers jumping
      • Controller input tied to something that triggers jumping

Argh! I don't like it. I could setup an event system. A change in gravity sends out an event that tells jumping what's up. Yeah, that's considerably better, but now I'm adding significant complexity.

What's a simple next step that would slowly lead to the infrastructure I need?