I still don't quite understand how you mean it.
Suppose all spawn points are aligned to the attribute grid (they don't have to, but for the sake of making an example).
You'd have all possible spots labeled* like so:
That's our imagined table of spawn point ID:s.
A row is 0-F for making it easy for us to understand what position it represents.
Now, we create a shuffled array:
11, A1, AE, 1E,
22, 92, 9D, 2D,
11, A1, AE, 1E,
33, 83, 8C, 3C,
(add in all you want - but exlude outer walls and doorways)
The array points to which of tile an enemy is spawned. In this example, since 11, A1, AE, 1E appear twice as often as the other ones, they (the corners) are twice as likely to be positions where enemies spawn. It's like having a modified deck of cards where some cards would appear twice, thrice or not at all. Also, the deck is rigged in a certain order.
With the one and only array-approach, you'd want all legit positions to appear at least once. With more arrays, they can be smaller and exclude certain spots if you want to. For example, it could be enough for a certain enemy type to only be able to spawn in corners, in which case you'd need only 4 bytes for that monster type. You'd better move their priority up in the list, then, as their spots are few. Another monster type may only spawn in a centered quarter of the screen. You get the idea.
The pick position procedure could be as follows:
Randomize an index.
- if yes, place enemy, dec index (or alternately randomize index again). if index = 0, start from top, pick next enemy to place.
- if no, dec index. If index = 0, start from top.
Loop until all enemies in the list are placed or in case there are no vacant spots left to place in (fail level count?), escape.
This way you could tailor 'randomness' pretty efficiently, at the cost of having at least one array. With more arrays, you can have varied "patterns of likelihood".
*It's a mental labeling - you don't need to store this information in ROM. The integers stored in the array can be used for moving the spawn decision to the correspondent position.
What algorithms does "The Legend of Zelda" use?
I don't know, but there's a disassembly here:http://computerarcheology.com/NES/Zelda/
I originally got this idea when contemplating the fortunate/unfortunate side features of the 'random table' in the Lone Wolf adventure book series.
It was the game constructors' intention to work as a makeshift die. You'd close your eyes and point your pen, and see what you got.
The fact is that the player will get familiar with the table and know what regions have high numbers, low numbers, high risk, low risk and so on. In this particular game, i think it's bad because it is meant to substitute a ten-sided dice but works nothing like it. There is potential, however. You can modify the chances of certain numbers by modifying their rate of appearance. You can modify the width of relations to neighboring numbers. You can modify the algorithm which picks a cell (you could have a set of methods how to pick a number). And the fact that the player can learn patterns can be used for good, because what you want is not randomness - it is patterns with a touch of chance large enough to keep the player alert/previously explored areas fresh.