What made old games better?

Old computer games appear to be better than the newer ones. Perhaps the time goldens memories and people collect only the games that were great while the shovelware gets forgotten. Sometimes things happen that violate this explanation.

Recently a youtuber made his own C64 game. It looks quite nice considering it's a realtime strategy game on a square tilemap. Did he just happen to be lucky? Well no, he spent considerably more time to publish this game than you'd expect it to take.

8-Bit Guy told about Planet X2's development in the Portland Retro Gaming Expo. He explains how the game uses the limited amount of memory provided by C64. The world map takes nearly half of the memory and only 4KB is reserved for the units. The way how that platform limits the gameplay is obvious yet it still manages to look and feel nice.

That's odd.

Modern game engines provide an Entity-Component System for organizing the game. If you look inside Unity3D you might be mistaken that this is object oriented programming. But it has more to do with Relational Models.

8bitguy's game likely does not use an ECS in any way. But there is not much missing and you could likely make it work on a C64 computer.

To make a functioning ECS you establish an increasing roll of IDs and sort tables by it. It is easier to understand than the OOP-slurry presented in Unity3D.

You have this kind of an entity record:

struct entity {
    int id, x, y, sprite_id;
};
struct entity entities[MAX_ENTITIES];

When you add a new entity, you will pick a new id and add it into this table.

If you have vulnerable and invulnerable entities. Or if some of your entities can lit into fire, you will provide additional tables.

struct vulnerable {
    int entity_id;
    int health, max_health;
}

struct in_fire {
    int entity_id;
    int duration;
};

struct vulnerable entities_vulnerable[MAX_VULNERABLES];
struct in_fire    entities_in_fire[MAX_FIRES];

Your controllable player gets his own structure which refers to his entity:

struct player_controllable {
    int entity_id;
    int control_map[CONTROL_COUNT];
    int control_status[CONTROL_COUNT];
};

player_controllable player1_control;

If you keep these records sorted by the entity_id then you would be able to access them quickly with binary search or iteration. It is also very easy to serialize and unserialize this kind of data, for example, to save the game state or reload it.

A lot of computer games used to look like this because when you have limited space you're pretty much forced to do some things in a certain way.

When the space on your computer ends faster than the time you have remaining for your project, you are also required to spend your time differently. This way the hardware limitations may have provided some substitution for project management. But might have also brought some more time to think about the problem you're trying to solve. This time spent differently might have mattered more in the end.

Computer games are a mixup of a toy, fantasy, gameplay, competition, fiction, art, entertainment. Everything told about fun, board games, puzzles and children's play apply to computer gaming.

What you need to do is not necessarily very complicated. For example the Robotfindskitten is fun, yet it resembles a popular children's book format, where the stuff you're supposed to seek for is somewhere in the book.

Keep in mind that a lot of the good fantasy and fiction has directly sourced from historical events or scientific findings. Lot of the bad fiction solely roots into other fiction.

Creativity stems from the depths of your mind, except that if nothing has a chance to collect in there, then it is empty and nothing stems from there.

Of course some decline may be explained by other factors. For example, we might allow our strive for realism to destroy the good fiction, gameplay and narrative.

No matter what's going on, I would hope for some more variation in the games. A good while ago I tried to define taxonomy around game mechanics so that I could identify the ones that haven't yet existed.