What is a game?

[jcarrier0026]

After doing some research, I think we need to really consider what a game is so we can build our game right. We should have a discussion to figure this out. Some questions I think we should be able to answer are:

1. What is a game? Is it a bunch of sprites/animated sprites that exist on the screen, or is it a bunch of objects that exist in the game that have components, such as a sprite/animated sprite, location, hit box, physics, etc?

2. How are we going to handle these objects/sprites? Should we create some type of GameObject Manager class to keep track of them?

3. All of these objects/sprites need to be updated every frame. So far we have been updating everything in game.run(). Should we create a game update function that is called by the game run function, and in the game update function call an update function for each game object/sprite? Or, if we were to use a game object manager, should we call an update function for the game object manager that would update all of the objects?

4. Should we have a texture manager class? (Not as big of a deal, but I think it makes sense)

I'm typing all this so I don't forget it. It may be beneficial for you to watch some of the videos I've been watching before we talk. I'll link the interesting videos below. The first link is for the texture manager, and the second is for creating a system that would allow us to add components (ex. sprite component, location component, physics component) to an "entity" which is what I would call a "game object". If we were to use this, I think we should probably change some things about it, but I like the general concept.

https://www.youtube.com/watch?v=RqvpkZ7I1aU&list=PLhfAbcv9cehhkG7ZQK0nfIGJC_C-wSLrx&index=6 ~6 min https://www.youtube.com/watch?v=XsvI8Sng6dk&list=PLhfAbcv9cehhkG7ZQK0nfIGJC_C-wSLrx&index=9 ~37 min

[mrmarkwell]

I watched these videos. I don't like the coding style at all, but there were some good concepts in there.

I think we should continue with an Agile MVP approach: build the minimal thing that works, and then iterate. When we hit pain points, we know it is time to refactor.

The idea of a gamemanager seems smart: something responsible for tracking all of the game objects and applying mutations to them (position changes, collisions, physics, etc...)

[mrmarkwell]

Looks like the ECS pattern this guy uses is common. Here is a different perspective:

https://youtu.be/JxI3Eu5DPwE

Let's try not to use a sledgehammer to swat a fly though: our game is simple. Let's keep it simple except when it can't be.

[mrmarkwell]

Another interesting video: https://www.youtube.com/watch?v=8f_3x79PEZQ

[mrmarkwell]

From discussion on the phone, here are some architectural thoughts:

1. Use a GameObject abstract base class to allow all the stuff in the game to be processed in a uniform way. This is the "Entity" in ECS

2. Make Components be pure data elements that entities can optionally contain. The current components in mind are:

• Sprite/graphics
• physics
• AI
• Location

3. Make "Engine" classes that process through the game objects, mutating their internal state based on their components. E.g., the PhysicsEngine will take all the GameObjects and update them based on their PhysicsComponents

[mrmarkwell]

The game loop would then be something like:

• InputEngine applies mutations to GameObjects based on inputs
• AiEngine applies mutations on GameObjects with an AI Component
• PhysicsEngine accumulates physics on each GameObject with a physics component
• CollisionEngine detects any object collisions
• LocationEngine updates location of objects based on output of AI/Physics/Collisions
• GraphicsEngine draws all the objects on the screen
• Wait until it is time to process the next frame.

Something like this. This is just an idea of what it could look like, not necessarily the exact design.

[mrmarkwell]

Next step: make some issues to track building this out.