Even the term "literally" has sometimes used to mean the opposite of its normal meaning.

There's other things that happen, like slurs being reclaimed and formerly innocent words being turned into slurs, as well.

It was once a USP...many years ago. Though you had to admit, it does sound cooler than randomly generated

Randomly generated contents are based on "handmade" designs by the developers. There is a set of fixed rules and values how things can be combined and look like based on the design of the developers. Then you are rolling the dice to create a level. The Diablo games are doing this. Think about certain structures in these games. They stay the same when they appear in every instance.

Procedurally generated content is different. The game itself creates the content. Game developers are creating here a set of rules how the content can be generated by the game. Based on these rules the game will create a level, a building, a tree, etc. Minecraft is an example for a game with procedual generation. However, a procedual generated level can have randomized contents. You can define parts where you can find certain types of enemies, items, etc. After the level is generated these elements can be placed randomized in the level with a randomized amount. In this case you have a mixture of randomly and procedurally generated content. It is also possible to add randomness to the rules. You can think about the generation of a tree. The rules create new branches with a certain probability. Thus, the game won't create the same tree over and over again. But this kind of randomization in the rules doesn't change the concept of procedural generation.

Indeed. True randomness is useful for say card order when playing solitaire. But anything else, dungeon/world creation is more based on say a maze. The maze will have rules, like you can't have more than 3 walls in any square, and the destination needs to actually be reachable.

To start a random dungeon, you'd start probably with a seed, and then place a couple random located up/down portals.

Afterwards, you can either randomly assign a room to each one where it actually connects.
Or make a path connecting them all in the shortest path, then do a few branching rooms
Or make a number of disconnected rooms, and then connect paths to them (This one seems like what Castle of the winds and Rogue-likes do).

Finally randomly clutter in empty spots treasure and/or monsters.

For something like Windforge there's weights to items, so the likelyhood of getting something at X, and then it will fill in that plus N number of spots nearby with similar items, like ores diamonds, dirt, rock, etc.

Some games will generate the world/area, and then assign quests or things each NPC should do, then let it run on it's own scenario for 1000 turns or something, so when you enter it doesn't feel like everyone just got out of their T-pose and are all trying to get money from the bank to purchase their morning coffee. less rolling list and more a single number that changes with each iteration.

RNG does something where you take the number+value(some large prime number), square it, then return the number. At least that's for more basic ones, cryptography can make it more complex, LFSR (Linear Feedback Shift Register) jumps all over the place and needs little in the way of calculation and is easy to implement

As for how the number is used, typically i just modular divide (get the remainder) to get within a range i want. Some languages give you a number between 0 and 1, so multiplying against the largest number you want gets a similar but slower result.

And while true randomness is unlikely, just being unable to predict how it is going to act is sufficient. Assuming you need say 100 numbers for generate something, the same seed in a different place in the chain can result in VERY different results.

Oh look, another troll post.

That won't actually lead to an even distribution in most cases.

Assuming that the modulus you're using does not divide the one the PRNG is internally using, the largest numbers will come up slightly less frequently than the smaller numbers. A PRNG will typically use a prime modulus, so it is highly unlikely for it to be an exact multiple of the modulus you're using.

Converting to floating point and doing a multiplication is a better approach, as it will give you an even distribution (provided the underlying PRNG provides an even distribution in the first place, of course).

And, as a result, use more computational power.

Cryptographicly secure PRNGs have there uses (in particular, the internet would be less secure without them), but for a single player game, they're a waste.

One other thing: Some systems (like Linux's /dev/random) can generate "true" randomess by harvesting entropy, using things like the precise timing of inputs to generate randomness. There's also some chips that have true RNGs (I believe even the Raspberry Pi has one), though there's still the question of how trustworthy those chips are.

Yes i'm aware. Was also thinking for like dice rolling, you might take say 3 full sets of rolls (1d20 x 3, so 60 numbers) then shuffle the numbers around. It wouldn't matter the PRNG, the results would have an even distribution, and still possible to get 2 of the same number in a row (and rare to get 3 but not impossible). Though as you get closer to the end like a deck of cards and playing Blackjack you can start to predict what the last results may be.

You don't need a strong crypto to get decent results for PRNG. There's plenty of ciphers that do a handful of shifts and iterations, possibly faster than squaring a number purely based on cycle counts.

Heh, i mentioned LSFR, which gives a next iteration but you can also reverse it, so it can be used for crypto. Doing 2-3 of those would also suffice, although what the values and if they are of different bit sizes would make different results.

Some password generators also use entropy, and when generating RSA and other keys, basically keyboard timing and mouse movements, likely deltas within a certain range of numbers. Regardless they will only store so much actual random data for access, while there's a faster pseudo random results for wiping large amounts of data. And the basic library has 'unpredictable seed' which is just an xor/add from the time/date or cycle count against rand(), not secure but enough that you can get a starting seed for games easily enough. (Reminds me Netscape SSL had a bit security issue back in the day when SSL could be cracked because the date/time was used too closely for generating keys... reliably cracked within minutes)

True randomness while it doesn't exist, nothing says you can't have say a small RF receiver which looks to a channel for static and then grabs any data it gets, with the exception of no more than 4 of any 1 or 0's in a row or some requirement and sends it as your RNG number.

Though the Atari800 also had a RNG built in if you read a specific port, which was the result of the audio chip and which cycle you read it at to get a random 8bit value. I suppose that's more for memory limits than actual attempts at randomness.

I really need to find some good lectures on the topic.

edit: Suddenly i'm reminded of timing and reading about instructions and using the RTC instruction and how you can't 100% rely on it. The reason being that the timer inturrupt can get in the way and give you bad results. I did a test with some multiply or divide instructions and did them over and over again, recording the results of the RTC, and it would bump from say 80-90 cycles, suddenly to 2000 cycles for 1 instruction every so often. It was a fun experiment back early 2000's as i remember.

Correct.

However, if you're in a situation where someone being able to predict the results of a PRNG could be catastrophic (for example, if it's being used to generate an encryption key being used for sensitive data), then you do need strong crypto.

In fact, debian GNU/Linux, at one point, added some code to OpenSSH (IIRC) to initialize an array (that was deliberately left uninitialized), and as a result, the keys generated became too predictable; as a result, the possible keys had to be blacklisted. (Worth noting that this was a debian-specific change, so it only affected debian and (possibly) downstream distributions, and that, once discovered, the patch was reverted.)

Other possibilities:
* The OS's scheduler may have pre-empted your process, causing it to have to wait until other processes got their turns before your process could continue timing. (This is probably what happened here.)
* There could have been a cache miss or a branch mis-prediction.
* A page fault may have occurred somewhere, causing the OS to swap out some data to disk in order to swap in memory for the running process (which may have been yours, particularly if it had just been pre-empted).

To eliminate these possibilities, you would need to get rid of the OS, running the test on bare metal instead. (No, a VM will not work for this purpose.)

Edit: When running on bare metal, you could also disable interrupts, so that timer interrupts can't occur (though I believe this won't prevent Non-Maskable Interrupts).

Here's an experiment you can run:
In a session of your favorite shell terminal (bash, zsh, ksh, et al), cat /dev/random

Now, open up Progress Quest and roll the stats for a character a few times.

One of these has a procedure to give valid results, the other is just garbage data. Both are still important.

Agreed. But you don't need super strong crypto if it's being used as PRNG for a singleplayer or multiplayer game so long as say it isn't for gambling or anything involving money.

Interesting. I'm still working on a crypto, blockshuffle or something, and using it for some PRNG there was an issue of determining the default array seeding was getting to me. Think i've decided on a small algo that xor and switches a code around, along with an LSFR, so even a weak seed will result in halfway decent PRNG. As for if it's good enough for encryption i'm not sure yet.

Mhmm, however you have to add those instruction lengths to the cycle count estimation. Regardless, yes if it's super important you can disable interrupts for a short period of time.

Regarding interrupts I'm reminded how interrupts make data transfer more efficient, how much extra running time is needed checking to see if you got data vs calling code after you have it, and a loop scanning say a small array used for dialup phones (1k round-robin or so) it took like 5x to 10x more cycles for the same job. But that's all going quite off.

It's also worth noting that in many user-level environments, you actually do get something like interrupts, where the environment or framework calls a function of yours every time input becomes available. For example, on the web, you can attach a JavaScript event handler to a button, and there's also the communication between web workers and the main thread.

Hate those types of games such LAZY level designers

Except that designing, developing, and debugging a good procedural generation algorithm involves a lot of work, and as a result is clearly not lazy.

In fact, having procedurally generated worlds means there can be many bugs that, if there were only hand-crafted maps, could simply be dodged by the level designers. (For example, in SMB1 they avoided putting too many enemies close to the flagpole so that it doesn't despawn.)

Yeah there are no enemies near that pole at all.

Attach a funtion call, or Lambda, anonymous function. Though depends on how complex it needs to be...