Rayhem

Fun fact: the original was only produced in English but the Shrek remix (which is a *BOP*) got translated into every language the movie did.

The physics prof who gave me my start would always get this kind of fond, nostalgic look in his eye whenever anyone mentioned "the days of punch card programming". So, naturally, I took an old slide rule and mounted it in a shadowbox with lettering that said "IN CASE OF EMERGENCY BREAK GLASS" when I got ready to graduate. He got a tremendous kick out of it.

> I came across narcissism. The idea that you’re smarter than everyone else. Comes from a grandiose sense of self importance.

This may be the colloquial description of how narcissism manifests, but it isn't even close to (and possibly completely opposite) clinical narcissism. The grandiosity isn't so much a belief as it is a "false self" put on to garner caretaking from others. It's not "I got all the toys as a kid, so I deserve more stuff!" but a failure to individuate from caregivers. "Mom (as a tool, not a wholly independent person) came when I cried as a kid, so I need you to lavish attention on me and make me feel better now as an adult. I can't see myself without external input; I only see myself as a reflection through you."

While claiming an aversion to being evil. Actions matter more than words.

Yes, exactly. If you have to update everyone's health (you do) and the updates are pretty much the same (they are), then things don't get any more cache friendly than this.

Sure. If your monsters have health, then their health is going to need updating pretty much by definition. Option 1 would be to make each entity responsible for updating itself with an overloaded `update` function in sort of a "classical OOP" fashion:

    for(auto &entity: entities) {
        entity.update();
    }

You're then responsible for weaving the health changes into your update (or getting it from your parent). Weird stuff can happen if one entity updates before another, too: you likely want all of the health updates to occur after all of the damaging events. So now this update function has to register a deferred health update to occur down the line.

Option 2 with something like an Entity-Component-System design would have a "Health" system that handles health updates across the board.

    for(auto &damageEntity: entitiesThatDoDamage) {
        damageEntity.registerDamage();
    }

    for(auto &healthEntity: entitiesWithHealth) {
        healthEntity.updateHealth();
    }

Neither of these options is strictly better than the other. Option 1 is good if you need a lot of bespoke logic for health updates (dragons update differently from humans which are different from vehicles etc.). Option 2 is better if everyone has `newHealth = oldHealth - damage`. Things are generally more similar than they are different, so you end up changing all values of a single "kind" (structures-of-arrays) more often.

If you're really accessing those fields it's overwhelmingly likely that you're accessing the same field for all of your instances. Your access pattern is going to be

    monsters[0].health = //calculation
    monsters[1].health = //calculation
    monsters[2].health = //calculation

and not

    monsters[0].health = //calculation
    monsters[1].name = //update
    monsters[2].is_poisoned = //check

Striding over your monsters array means you have to load each monster to access one field which just blows your cache to hell. Much better is to pack all of your health values together in a structures-of-arrays layout as opposed to the usual arrays-of-structures approach here. Entity-component-system architectures are a brilliant tool for managing this with some pretty performant results.

> The health of a monster is currently represented by a 4 byte signed integer, meaning that the health can range from -2^31 to 2^31-1 (2^31 ~= 2 million). We can already see that half of the integers potential is unused because the health of a monster should never be negative, so an unsigned int would fit way better.

If you're strictly optimizing for memory size out of necessity, then yes. It's dangerous to use an unsigned type in any context where you might even consider subtraction, though, and it's pretty effortless to see that new_health = health - damage is going to be used somewhere. Congrats! Your 100hp lvl3 monster just got resurrected with sixteen thousand hp.

> Sometimes authors use it without thinking, but removing the passive voice often makes writing shorter and clearer.

I don't think mentioning "authors" is absolutely necessary, but I think this is both a faithful attempt to convert this to natural active voice and easier to read/understand.

In the same vein, I've been keen to try out "What would the world look like if..." and then show that we do or do not observe related phenomena. It seems like the best way to meet someone on their terms (because they get to write the "rules" of the world) and then you just apply them towards one conclusion or another. But I haven't had enough exposure to really test this out.

Except when LLM providers bury the thing you're obviously looking for under an entire page of sponsored ads (buy Diet Coke™!), then that convenience argument starts to not hold up as well...

I had a parallel thought when a loved one was in the hospital. I noticed the nurses were so busy that small requests like an extra blanket were often forgotten entirely. How incredible would it be to have a voice system that would build a task list and capture other notable bits of information that the hospital staff could review on an integrated device (like a phone)?

Sadly, I don't see this ever happening due to the insane number of regulations you'd have to satisfy and the major players in this space only doing it to collect PII.

I've come to understand that software has two axes: the problem domain and the software domain.

The problem domain is things like your physical model. Your 3d mesh. Financial transactions. All things that need to be represented in software.

The software domain is things like components and queries. Things you can build in-software to realize your problem domain on a computer.

Defining a component and the behaviors of a component has nothing at all to do with the problem domain; it's purely an artifact of software to make your system more extensible/reliable/faster/whatever. But this is the part that's OOP excels at because you get to write the rules of your component taxonomy in its entirety. You have a ThingDoer class that can accept any number of Components to give it the behaviors you need, and then you start writing out components to model your problem domain. The objects and their behaviors remain at the level of "how do I put these pieces together". OOP sucks for the problem domain, though, because you're always stuck trying to munge some limited inheritance tree (animal <- dog <- wolf) onto the Real World and it's always going to miss something. Far better to build atomic building blocks that are expressive enough to compose into whatever you need.