In programming language theory, lazy evaluation, or call-by-need, is an evaluation strategy which delays the evaluation of an expression until its value is needed[…]
For example, instead of knowing that a value is 2, the program might only know that it’s 1+1. Especially if you do things that depend on a lot of other things. It might be 1+1 + 1+1 for example.
Another way to phrase this is that it is storing “recipes” rather than complete food items. Instead of having pizza I have flour, yeast, tomatoes, and basil.
In other words, there is a canonical, committed answer (this satisfies “Paper → Rock”) but you’ve just been lazy and post-poned part of the actual work. You’ve done enough work so that the Gloracle stores the true answer of what’s there, what’s in the box. You’ve done the “decision-making” part of prep, you’ve committed to the hard facts.
Roll tables is a great way to do this. You can also have roll tables refer to other roll tables. (“OK so if they roll a 1, then this thing, and if they roll a 2, then this thing, and if they roll a 2–4 then something from other table A, and if they roll a 5–10 then something from other table B…”)
This is the second tier of truth in the blorb principles. It’s not great to have everything in the game world be this kind of “generated reality”. It’s usually more interesting to interact with something that is more strictly there.
For example of going north, east and west are all random, in a sense they are also all equal. The decision between them doesn’t really matter, and that’s not good design.
But there is a huge upside to this kind of lazily loaded prep: you don’t get too committed to prep that might never be seen or found by the players as they sandbox around wildly in the game world.
