• We merge the "Software" section with the "Games" section under one tab (not necessarily one page)
• We list all games and software under alphabetic sections in the "List of All…" page, for example, software that starts with "A" would go into the "A" section in that page
• We remove the pagination in the "List of All…" pages and the "List by…" pages. For example, in this page the 2nd page has only a couple of items, both of which should go on the first page.

Minh

Since books count as an external resource, it should probably go on this page.
Then it would be instructive to change the name of the page to "Resources" from "External Links"

And feel free to rewrite this to make it clearer. You can certainly have a graph in b), the naive implementation is a tree.

With persistent levels, either a) the each 'floor' of the game is always the same once generated and all exits from the current level lead to one of two adjacent levels, or b) each exit from a level leads to a new level, which results in the game space consisting of a tree of levels branching away from the root which the player first entered where the number of children of the level equals the number of exits from that level, minus the one that the player arrived from.

Why is it only the case in a) that "each 'floor' of the game is always the same once generated". I would think this by definition is always true for persistent levels.

In b) I'm confused if it's meant that in the tree of levels, the player can go up to the 'parent' of the current level (i.e. the level where he came from) or not. If he can't, and a given level is only ever entered once, I'd say it's a case of non-persistent levels - unless they're the same the next time the game is played from scratch. If he can, then surely the parent levels should be the same as before in order for this to qualify as persistent levels?

Also, I would like to rewrite the paragraph to say that levels can be connected by arbitrary graphs rather than saying they must be connected either in sequence or in a tree structure, which is an arbitrary limitation of the definition in my opinion.

It really happens though. In X-Com a soldier had the same name as a friend I knew, so he was kept around, even after I discovered PSI and found that he had mediocre PSI strength.

Many of the TIG-PCG entries got attributes for items by asking the player for a word and seeding the RNG with it, or hashing it, etc.

Diablo adds prefixes and suffixes to an item, and the mods on an item are dependent on the prefixes/suffixes.

Then there is Treasure of the Rudras where the player-entered name of the spell was parsed into prefixes, base, and postfixes to select the effect of the spell.

I'll add in the additional reference I was planning to create on a name generation page to this one…

a) the sounds that make up the music are not procedurally generated
b) the music selection is procedural, made up of a number of music fragments put together.

In particular, key words: dynamic and artificial life strongly suggest that procedural algorithms are at play.

I also think this long form style comment deserves to be an article: we should really have a section of is 'x' procedural articles, because these are thought provoking and good examples of stuff you may not have initially thought was procedural.

We can't look at the source code to check, we must rely on developer commentary etc.

The presence of music files doesn't prevent the music from being procedural, the Music Director might sample from that music and stitch it into something new.

Here are relevent quotes from the developer commentary (I think all the music commentary is on the hospital section of the commentary level, I haven't checked the other parts).

Tim Larkin: We took several steps to keep the music interesting enough that the players would be inclined to keep it on as they play. We keep it changing so it won't become tedious; to this end, we created a music director that runs alongside the AI director, tracking the player's experience rather than their emotional state. We keep the music appropriate to each player's situation and highly personalized. The music engine in Left 4 Dead has a complete client-side, multi-track system per player that is completely unique to that player and can even be monitored by the spectators. Since some of the fun of Left 4 Dead is watching your friends when you're dead, we thought it was important to hear their personal soundtrack as well. This feature is unique to Left 4 Dead.

Mike Morasky: A lot of over-reaching dynamic music systems go to great lengths to organize and control a very expressive art form, often to the point of making the results perfectly 'controlled' but also perfectly predictable. Our Music Director aims for 'planned serendipity'. By designing the music and rule sets to increase the probability of beautifull happenstance and to minimize the probability of inappropriate mistakes, we end up with the highest percentage of musical events working as planned, an nice mid percentage of acceptably artfull mistakes, and very few actual poor moments. If you overdesign the music and rule sets, there are no surprises but without surprises, listeners are quickely bored. Ironically by keeping things simple, the music seems planned; greater complexity just leads to greater randomness and many more poor moments.

Mike Morasky: We based the music on what the player is actually experiencing and not on what we want them to experience. Working from artificial life work our designers had done on Lord of the Rings and the Matrix sequels, we implemented a simple system to examine what's going on in the player's immediate environment, the added the appropriate reactive, scalar rule sets to cantrol the music and its volume levels. Most of the more prominent musical events are thus reactive results from rule sets processing this input — making the musical experience specific to each player. This system also controls the dynamic mix system — another feature unique to Left 4 Dead.

At the very least there is a set of tracks that are mixed to give different feels as well as musical events that are triggered on "witch alerted" or similar events. Though the notes and instruments are not procedurally generated, it would be fair to say that the music is dynamically mixed and arranged.

If you have the game, the music resource files are at:

steamapps\common\left 4 dead\left4dead\sound\music

To me they sound like fragments of the in-game music. With the exception of the non-interactive parts of the game they are all pieces 5-30 seconds long that mixed with other pieces to give the in-game music. The longest parts are the "you are dead", "safehouse reached" and "ending credits" music, those are always identical in-game without mixing.

Another reason the line is blurred is that any content affects gameplay. For example, think of how much effort Valve puts into getting the silhouettes of their characters unique, and how their effort that changes only the appearance of the characters makes the game different by allowing players to identify objects faster.

The distinction is still useful and we still focus on PCG, but the only thing this excludes is something like: "making content manually (that is, the hard way) and then finding a way to generate the exact same thing procedurally." In which case it is more of file compression than any thing else.

Which reminds me of the definition of algorithmic information content…

Perhaps I should put in a page on AIC. Will take a bit of research first.

Just my interpretation.