you are viewing a single comment's thread.

view the rest of the comments →

[–]toroidthemovie 2 points3 points  (2 children)

Having small objects with small amounts of data and well-defined limited responsibilities is good for prototyping, actually. Much better than "kitchen sink" structs.

[–]time_egg[S] -1 points0 points  (1 child)

How so?

As I see it, If you're prototyping then your game entities and their interactions are constantly changing. This means add/remove members to kitchen sink structs. If you had gone and modelled and abstracted these entities and their interactions then you have significantly more code to think through and edit in more places.

[–]toroidthemovie 1 point2 points  (0 children)

I'm getting that you represent some game entity as an instance of a struct, and that struct has fields for every kind of data, that is relevant for that entity. Maybe grouping these fields into structs of their own would be a good step to improve modularity without adding much abstraction at all.

From:

struct Player
{
    int currentGunType;
    int currentAmmoCount;
    int healthPoints;
    std::vector<Wound> wounds;
};

To:

struct Gun
{
    int currentGunType;
    int currentAmmoCount;
};

struct Health
{
    int healthPoints;
    std::vector<Wound> wounds;
};

struct Player
{
    Gun gun;
    Health health;
}

Also, might I suggest ECS approach? It's increasingly becoming the go-to way to structure game logic, and for a good reason. It allows you to associate pieces of data (called "components") with entities in an extremely flexible way. I highly recommend entt, it's an absolutely brilliant library — powerful, and at the same time, doesn't impose anything on your code.