The Little Shaman[1] has been one of the most comprehensive-yet-approachable resources I've found for understanding these kinds of high-conflict personalities. In particular [2-4] are pretty relevant to your question.
[1]: https://www.youtube.com/@thelittleshamanhealing/videos [2]: https://www.youtube.com/watch?v=uJZeXxU7QTg [3]: https://www.youtube.com/watch?v=TokWBgMQIZ4 [4]: https://www.youtube.com/watch?v=e5Hq_xNxrOg
I came across narcissism. The idea that you’re smarter than everyone else. Comes from a grandiose sense of self importance. But the truth is most people are smarter than you in some ways and less smart in others, but you’re unable to see it because you’re in this black and white mode where preserving your ego relies on you being the smart guy amongst the idiots.
It’s very common in tech to see this. Maybe because we were all exceptional at maths when we were young and got the idea that meant we were super smart and this compensated for our nerdiness.
I worked with a bunch of physicists and every single one of them was smarter than me at maths and physics, I wasn’t even close. But they sometimes talked about politics and current affairs, which I’m very well read in. I didn’t say anything, but I was shocked at how little they knew and how overconfident they were.
None of those folks were narcissists, thankfully they were lovely people, but for sure it highlighted how poor people were at judging their own expertise in an area.
It’s so easy to dismiss people, criticising is easy, and so hard to see just how stupid you can be yourself.
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."
double health[];
which is the value that would be updated by healthEntity.updateHealth() ? So because you're sequentially updating only that attribute it should lend itself to being cache friendly and potentially prefetch prediction? (can't remember the term)I'm not a games developer, so I don't have a good feel for why you'd need to iterate over every monster's health property in a tightly loop vs accessing each monster and calculating their position, what properties they have and updating one or more of their values in an iteration.
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.Why are you making your structs smaller. Probably for "performance". If your goal is literally just reducing memory usage, then this is all fine. Maybe you're running on a small microcontroller and you just straight up don't have much RAM.
But these days, in most areas, memory is cheap and plentiful. What's expensive is CPU cache. If you're optimizing memory use for that, it's really about runtime speed and less about total memory usage. You're trying to make things small so you have fewer cache misses and the CPU doesn't get stuck waiting as much.
In that case, the advice here is only part of the story. Using bitfields and smaller integers saves memory. But in order to access those fields and do anything with them, they need to get loaded into registers. I'm not an expert here, but my understanding is that loading a bitfield or small int into a word-sized register can sometimes have some bit of overhead, so you have to pay attention to the trade-off.
If I was optimizing for overall runtime speed and considering packing structs to do that, I'd really want to have good profiling and benchmarks in place first. Otherwise it's easy to think you're making progress when you're actually going backwards.
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.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.
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.
If the counterparty knew the answer to that, they would sit down with Google, not engage in an argument. Debate is mainly information sharing, but also to some degree about exploring the answer to that question.