Member Avatar for nuclear

To be specific I'm trying to implement this into a small game. What I'm thinking of is having a base/default class for derived objects such as player, enemies, tiles and so on and later the derived classes would inherit this base class and add whatever is needed depending on the object.

Right now the base class contains all the basic variables needed and all the basic virtual functions. I'm thinking of making that the base class would have a constructor and parameters to initialize all the default variables and the derived class would add anything if needed in its own constructor, though this would mean I would have to add all the basic parameters which I would use in the base class constructor for initialization to the derived class constructor by using such syntax: classB(int x) : classA(x) and I think it's a bit too much work, I would like for a more automatic method.

Anyways, sorry for a long and hard to understand post, I would like some tips on how I should design such things. Posting some code below just clearance:

class Object
{
protected:
    fRect box_obj;
    float xVel, yVel, maxVel;
    float speed;
    std::string surfaceName;
    World* world_ptr;
    b2Body* body;
    Surface* sur_obj;
    Rotation* rot_pnt;
public:
    virtual ~Object(); //Virtual methods defined in the .cpp file
    virtual void move();
    virtual void show();
    void set_angle();
};

And the Player:

#include "Object.h"

class Player : public Object
{
public:
    Player(fRect fr_obj, World* bWorld, Surface* sur, std::string surName, bool isDynamic = false, bool rotatable = false);
    void handle_input(SDL_Event& event);
    void move();
};

But like I've said, this is a current method of mine which I think might need some work. I'm initializing those parameters in the derived class.

Edited by nuclear
  • 2 Contributors
  • 1 Reply
  • 214 Views
  • 22 Hours Discussion Span
  • Latest Post Latest Post by Despairy

Dani AI

Generated

A concise design direction for the situation described by : avoid a single monolithic base that owns every responsibility. That pattern quickly creates long constructor parameter lists, brittle coupling to global services, and classes that are hard to reuse or test. Splitting responsibilities into small, focused pieces keeps derived types lightweight and makes construction much less noisy.

As suggested, move game-wide concerns (event handling, movement rules, collision queries) into dedicated systems. On the object side, prefer composition: define small components such as position/transform, collision/physics, rendering, and input/AI. An entity becomes an assembly of only the components it needs. Systems operate on those components (movement system, physics step, render system), answering questions like “can this entity move there?” instead of embedding that logic in every object.

Practical construction patterns that avoid long parameter chains: pass a single configuration object or use a builder/factory that assembles components, or use a short, explicit Init/Config struct so derived constructors forward one argument instead of many. Inject shared services (resource manager, physics world, tilemap) as well-defined interfaces rather than raw global pointers; prefer smart pointers or references to make ownership clear. If using modern C++, leverage in-class member defaults and delegating constructors to reduce boilerplate.

Refactor strategy: start small—extract a Transform and Renderable, create a factory that returns fully-initialized entities from a config, then move logic into systems. Keep the base interface minimal (e.g., update/draw hooks or small marker interfaces) and avoid exposing lots of protected state; prefer private members with narrow accessors. For a small project this component approach is pragmatic; for larger projects an ECS can be considered later.

Member Avatar for Despairy

since the fields are protected you are able to change them in the derived classes,
so not sure if I understand what you mean.
anyway i think your inheritance tree should look abit different .

first have a controller that will manage the game ( event handler display handler , stuff like that)
and its better if objects wont hold EVERYTHING, why does the player need to have World*?
to know if he can walk in some direction? instead make a Logic class that will recieve the players current
position and the next move position ( by the controller) and it will return true if the player can move there or not

make sure every char inherits only what it needs, you can make interfaces instead of only classes
tell me what youre thinking about and ill try to think about it too ;)

commented: good answer +0
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.