Major reworks of the engine

[formerlybased]

After looking over the engine again after a couple of months, I am not so happy with some of the ways it works and some of it's features. I would like to rework major parts of the engine to more easily allow for new features like levels/scenes and better game organization. If you are interested in the project, give your thoughts down below on major ways the engine could change for the better. Thanks in advance.

[formerlybased]

1. Create a game class to hold data such as the renderer, entities, etc. This will make it easier to add level support
2. Create a basic GUI using imgui. I don't want a full-on scene editor but something basic to manage projects and stuff is a good idea.

[JavinalCharles]

A ResourceManager to centralize storage of resources (Textures, Audios, Fonts, etc) A StateMachine class to easily contain and transition between scenes (Menu, Loading Scene, Game Levels.. )

[JavinalCharles]

Hello there! I've recently started with SDL and was thinking of creating an engine using the library when I stumbled into this repository, so I decided to contribute to this project (I mean, if you'd allow it. ) and see if it would be something I could use myself later on. :-)

[formerlybased]

Oh hey, a resource manager for sure is something i've been meaning to do for a while. Also if you want to contribute go ahead, i'm always happy to see new faces @JavinalCharles

[JavinalCharles]

@formerlybased I'm also thinking of changing.... a lot. Particularly, I'm interested on changing the Entity class to more follow the Entity-Component-System framework.

add a base Component class to hold aspects of entities. Such aspects could be Transform, Sprites, Velocity, Camera, Collider, Inputs. So basically, the Components defines the Entity. This saves us from having to inherit Entity for each archetype we need (This probably makes RigidEntity obsolete) add a Window class as wrapper for both SDL_Window and SDL_Renderer An EntityManager, a system to hold onto Entities and loop through each of them and work updates on their components as well as passing them on to other systems. these systems include CollisionSystem, RenderingSystem, etc

[formerlybased]

Yeah a component system is something i've been thinking of for a while. Like the title says, I've been intending on changing most of the engine. I'm excited to see what you can do, and thanks a lot in advance!

[formerlybased]

Ok so @JavinalCharles i thought about this the past few months and I guess I kinda wanted the structure of a feather game to look like this

Game (holds data about the entire game) -> Level (holds individual entities for specific scenes in the game) -> Entities (hold components like a transform, sprite, etc.) -> Components (actually hold entity data).

If I am actually to make a GUI this also works pretty well with that.

[JavinalCharles]

Yup. Seems like we held almost similar vision on how to develop this engine. Good to know!

[formerlybased]

53 (resource manager) has been implemented

[JavinalCharles]

I got something big incoming. Which includes the reworked Entities, Components and some Systems added, probably tomorrow if not later today. We don't have a limit on which C++ version we want to use, do we? (C++20 okay?)

[formerlybased]

@JavinalCharles It depends, what C++ 20 features are you exactly looking to use?

[formerlybased]

I'm also going to work on the Game class if that isn't something you are already doing as well as the level system potentially.

[JavinalCharles]

Not features specifically, no. Just some STL methods that didn't existed in C++17 or earlier. One example being std::map::contains method.

[formerlybased]

Yeah alright C++ 20 is good, we just need to remember to specify that we use it in the README

[JavinalCharles]

Just made a PR. Thought you might need some of these stuff for the Game class.

[formerlybased]

54 (ECS) merged. I will work on the Game class now. We should deprecate the old Entity system before 1.0

[formerlybased]

@JavinalCharles I will basically completely rewrite the main function with this. A few things we should do after this include:

• implement levels
• fix the sound system (sound emitter component)
• adding the feature to serialize/save data
• collision component
• rigidbody/physics component
• an actual Input class

[JavinalCharles]

I'll start work on collision component once I've had some time. EntityManager is far from complete so I'll continue work on that as well. Probably Sprite component too if you're not working on that.

I have some ideas for handling events or inputs, but that can probably wait since I want to focus on just having something on a screen right now.

As for saving data, I'm thinking we could just save data in an XML file just so we could use the rapid-xml library, at least for the time being.

[formerlybased]

@JavinalCharles Thanks for the comment, sounds good. I have been sick the past 2 days so I haven't really had much time to work on the Game class but I will hopefully get better soon.

[formerlybased]

New rendering system with #55. Will merge. I am also (finally) getting around to actually writing the game/level system.

[formerlybased]

I am also going to make a SoundEmmiter component real quick

[formerlybased]

New sound system is finished and should work. Now I will actually make the game class for real

[formerlybased]

I created an experimental branch for things that I am not 100% sure about and want to test for a while before they become official features

[formerlybased]

Just quickly uploaded the still highly in progress game class. It's broken right now, but i'm still working on it.

[formerlybased]

Sorry for the inactivity, been a bit busy, i am going to finish the game class now.

[JavinalCharles]

Making a PR. Do you have any idea why cmake is making a '=======game' executable instead of 'game'?

[formerlybased]

@JavinalCharles huh, I have no idea. It creates a 'game' executable for me so something must be wrong on your end

[formerlybased]

56 merged. Also at this point we can start removing some of the old legacy code in the engine as well as some of the unfinished things I started last year but never finished.

[formerlybased]

I also want to do some more work on the sound emmitter component to make it be able to loop sounds and give it some more options

p.s. debug.cpp didn't compile for me, i fixed it by making the std::ostream a std::ostream&. will commit asap

[formerlybased]

Some things we can work on next @JavinalCharles:

• Saving data
• Work on resizable windows & fullscreen
• Improving the sound system
• Collision & Physics components
• Input system
• Levels

If any of these interest you send a quick message that you are working on it. I would like to create a new Input system but I do want to hear your thoughts on it before I start doing that.

[JavinalCharles]

I have an idea for an Input System. And besides, this would be one of the few that brings us closer to actually being able to build games succinctly.

[JavinalCharles]

I also want to do some more work on the sound emmitter component to make it be able to loop sounds and give it some more options

My understanding was that sound emmitter is for sound effects produced by entities. If you're talking more about something like a background music, I think you should use Mix_Music. Then we could have just one class/Entity in-game that holds reference to every music and plays/pause/resumes them depending on certain inputs.

[formerlybased]

@JavinalCharles yeah ideally I would also want an option to loop sound effects too, but we might not be able to do that with SDL_Mixer unfortunately. As for music, I was defnitely thinking of some kind of sound system that controls the current music being played as well as references to the other music in the game and can be stopped, paused, started, etc.

[formerlybased]

@JavinalCharles What is your idea for the Input system? I feel like there are two ways we can do this. Either we create an Input class that can act as a global access point for inputs and contains direct references to input, for example a key press function or a way to access the location of the mouse, etc. Otherwise we could do something more like in godot where the developer defines input actions somewhere and can then access them. This makes it pretty easy to allow multiple keys/controller buttons to correspond to the same thing as well as easy to change keybindings since instead of needing to go through and update the code you can just change the keybindings. I want to hear your thoughts on this.

[JavinalCharles]

@formerlybased I'm not familiar with how Godot does its thing, but my idea is somewhat similar to the former. Basically, a single class holding a map of SDLK as keys, and boolean as the value type, that is true if the key is currently pressed and false otherwise. Then just provide methods that returns a boolean value if the queried key is pressed down, or pressed up in the current loop. The Components as well as their ComponentSystems could then access those functions to make changes to their respective states through the shared context pointer that all entities ought to have.

class InputManager {
public:
    ....
    bool isKeyPressedDown(SDLK key);
    bool isKeyPressedUp(SDLK key);

    Vector2f getMouseLocation() const;

private:
    std::map<SDLK, bool> m_currentKeyMap;
    std::map<SDLK, bool> m_previousKeyMap;
    ...
};

class DerivedComponentSystem : public ComponentSystem {
...
   void update(float) {
       for(component in components) {
          if(component->getOwner()->CONTEXT->input->isKeyPressedDown(SDLK_w)
              // do something
      }
   }
...
};

I'm also debating of instead of boolean values, I could map the SDLKs to function objects, which will call their '()' operator upon key pressed but I thought the method I described above might be more flexible.

[JavinalCharles]

.... but function objects might be more functional.. Hrmm. I dunno.

[formerlybased]

@JavinalCharles yeah that's kind of what I was thinking. Having a system to handle SDLK and a global access point so you can just do something like Input::isKeyHeld("down") and see what's happening. We can experiment with a few different things.

[formerlybased]

removed some of the old, now unused code. I am going to write a few more components and maybe experiment with a music system. i also want to experiment with a way of "labelling" entities so that you can give a special tag to an entity and detect if it's an enemy, an item, etc.

[JavinalCharles]

The current files are starting to confuse me now, honestly. Can we separate the headers and the source files? Also, can we just use TitleCase convention in naming the files?

[formerlybased]

@JavinalCharles I think switching to TitleCase naming is a pretty good idea, but I am not sure how I feel about separating headers and source files.

[formerlybased]

New input system with #57. There is still lots of work to do for input, but for now we have the groundwork of a great system.

[formerlybased]

Some ideas for a next feature:

Work on resizable windows & fullscreen
Collision & Physics components
Text

[JavinalCharles]

I think Collision should be next, but I won't be able to contribute for 2-3 weeks cause I'm gonna work on other projects. If it's not done by then, I'll work on a Collision system.

[formerlybased]

As luck would have it, I have a lot of free time right now so I'll definitely implement a lot of features now while I have time. Good luck on your projects!

[formerlybased]

quick note while I work:

switching over to checking the keyboard state instead of polling for events could be a good method for input in the future

[formerlybased]

Next commit will include:

• Window resizing
• Entity labelling
• The start of the collision system

[formerlybased]

Was sick over the last few days so progress went a little slower than I would have hoped, however I have just pushed the code for the basics of the collision system and collider component. This also includes entity labels. Haven't finished window resizing just yet, but I will probably work on something else for now.

[JavinalCharles]

I have an Animation component coming later next week. Oh, and I'll probably work on that making everything TitleCase thing. Anything you want me to work on after that?

Also, can you make the Collider a virtual base class instead? I want to be able to have different kinds of Collisions later on so it would be good to have something that I can just inherit from. I'll probably want to use circle colliders for things like bullets or projectiles. Or even a rectangle that can rotate on an axis(which normal SDL apparently doesn't know how to do.)

[formerlybased]

60 merged

[formerlybased]

Making different types of colliders is obviously important, sorry that I overlooked that and didn't just make the collider a base class. Will work on that now, as well as the music system.