> I think any NPC with dialogue important to a goal (a quest, a tutorial, etc) is going to be hard to use generative AI for. It not only needs to be coherent with the story, but it needs to correctly include certain ideas. I.e. if the NPC gives a quest to go find some item at some location, it needs to say what the item is and where it is.
That was my experience when I was experimenting with using current LLMs to generate quests. You can of course ask for both a human-readable quest description and also a JSON object (according to some schema) describing the important quest elements, but the failure rate of the results was too high. Maybe 10% of quests would have some important mismatch between the description and the JSON; the description would mention an important object but it would be left out of the JSON, or the JSON would mention an important NPC but the description wouldn't, etc.
As a player, I think it would get frustrating quickly if 10% of quests were unsolvable, especially since, as a player, you don't know when a quest is unsolvable; maybe you just haven't found the item/NPC yet.
Yeah, 10% about jives with what I would expect under the assumption that the generated text needs to be non-deterministic (I.e. no careful prompt tuning and turning the temperature down to basically 0).
An interesting flip side I was just thinking about is the AI saying too much. NPCs keeping secrets until the player gets enough reputation or does a favor or whatever is pretty common. I wonder how good they are at keeping those secrets.
Prompt injection is one thing, and vaguely equivalent to cheat codes which is fine, but what is the likelihood that a player just asking for more info ends with the AI spitting out the secret without completing the quest? Will the AI know to unlock the next area or whatever, because there's no reason for the player to do that NPCs quest?
Should be neat stuff, I'm looking forward to how this all works together when the kinks get ironed out.
A structure with no members can be made to have zero length as a member of something else but not as part of its own definition. I.e., the `[[no_unique_address]]` attribute is a property of the member, not of the struct on its own. It's somewhat annoying that you can't flag an empty struct as being really empty, and have no-unique-address-ness applied everywhere it's used automatically; you have to flag every use with the attribute manually.
Prefixes come first, 1 byte each, order doesn't matter except that REX, if present, must come last. Then the opcode, 1-3 bytes. Followed by Mod R/M byte, if present. Followed by SIB byte, if present. Followed by address/immediate, 1, 2, 4, or 8 bytes, if present.
Ugh; there's a reason why I'm switching my architecture course to MIPS32.
The problem is that if you call another function, you won't know whether that function is uses any instructions that require alignment. So in practice, only leaf functions can skip stack alignment. The ABI states that the stack pointer must be aligned to a multiple of 16, plus 8, before any `call` instruction.
For my beginner programming class, I have them use a script `compile` which handles compilation and linking, while also enabling enabling all the warnings/errors I think are helpful, and also doing the above redirection. An absolute beginner doesn't gain anything from invoking `g++` directly.
A typical grocery store will carry on the order of 40,000 unique products. Costco is hard limited to a max of 3,700 unique products. If a store wants to bring a new product in, something must be rotated out. This also means that if a product wants to stay in Costco, it has to sell a certain minimum number of pallets, per month, to be worth it.
TurboVision was distributed as source with some of the Borland tools, and later open-sourced, I think. So it's not a rewrite, just a port to non-DOS terminals.
The implementation of inheritance (more specifically, polymorphism and dynamic dispatch via vtables) is a problem in games, because it adds an extra layer of indirection, and screws with cache locality. But the semantics of inheritance (X ISA Y) still apply. In an ECS, the implementation is different (struct-of-arrays) but you can still think of an entity as "inheriting from" the various components its built from.
That's not really accurate. Component based systems are designed specifically to address situations that traditional inheritance doesn't handle well.
Examples are usually something like having a base entity, a player that inherits from entity and an enemy that inherits from entity. Then you have a magic user and a barbarian inherit from enemy but now you also want your player to be able to use magic. Traditional OOP doesn't make it easy to share the implementation.
Even with composition and interfaces you still have problems with most traditional OOP languages when you want to do things like change the set of components of an entity dynamically at runtime (player gains or loses the ability to use magic during the game).
"Is a" is often not the relationship you want to model. A player and an NPC both have the "has a" relationship to an inventory, not the "is a" for example.
> you can still think of an entity as "inheriting from" the various components its built from.
If it's based on components, wouldn't that mean you would think of it as being... _composed_? I typically don't hear "it's made of many components" and think of inheritance
Is that article correct, that mixed DPI on Wayland works by just rendering everything to a virtual screen whose resolution corresponds to the maximum DPI of any physical screen, and then downscaling all the other screens?
That was my experience when I was experimenting with using current LLMs to generate quests. You can of course ask for both a human-readable quest description and also a JSON object (according to some schema) describing the important quest elements, but the failure rate of the results was too high. Maybe 10% of quests would have some important mismatch between the description and the JSON; the description would mention an important object but it would be left out of the JSON, or the JSON would mention an important NPC but the description wouldn't, etc.
As a player, I think it would get frustrating quickly if 10% of quests were unsolvable, especially since, as a player, you don't know when a quest is unsolvable; maybe you just haven't found the item/NPC yet.