[guess] Serial Experiments Lain
set range is keeping history 
also iterating titles via this method will make guessing titles very easy, since the players will be able to easily estimate that next title will be within the next xx titles.
Setting a range is not keeping a history as no data is being stored in a non-volatile state (unless you ARE storing program variables in some stable form, like files or a database). If it's not being stored permanently, it can't be viewed later, which would mean it can't be "history". Unless your definition of "keeping history" differs from mine, in which case I would ask you to clarify. I can't give good advice on something without good specs.
If you are worried about people being able to estimate, then randomize the source between loops (once the game hits the end of the list, shuffle the master list or a COPY of the master list and start from the first entry there). That way, they can NOT estimate because the users no longer have a copy of your list to refer to. Alternatively, if you were to go that route, you could just randomize the master list (or, again, a COPY that the program is reading from so that you still have an original, in order, master list), and iterate through it one by one. You wouldn't have any repeats for a long time then. Of course, this might work against your intention of having SOME repeats for new players, but in that case, consider this:
any title will be new to a new player. Without repetition,
any title will be new to
all players.
Alternatively, to avoid repeats for potentially more than 100 titles:
- Set Range: 1-32
- Randomly select: 20
- Set new range: 21-52
- Randomly select: 33
- Set new range: 34-65
Either solution wouldn't require you to keep a history on what titles have been selected. You would only have to be able to read what the current range is, and optionally the index of the title that is/was selected.
Again, I'm not familiar with how you have your code set up, so I'm not sure if that would fall inside or outside your definition of "keeping history", but to me it would be tracking variables, either within code or within a session (or within a file/db if you needed something more stable than a session).
Care to elaborate on this "history" issue?
history, in other words making a list of previously appeared titles leads to a limit in title pool thru exclusion.
Neither method I described keeps a list of previously shown titles, though that would be my preferred approach (being a database guy, that approach is more natural to me). And yes, the delayed repetition is the goal of a randomizer. You don't want to roll Snake-Eyes every time in a game of Craps.
So suppose your range contains 550 titles, everytime you show a title you deduct one title from the pool. Unless "only one person" plays the game continuously for 100 games, non-repeating randomization was not necessary (and I can not know who is viewing the game, thus players)
the game's randomizer uses mt_rand(range_min, range_max)
mt_rand() to my knowledge is the right way to go, though it is troubling that the program
still gets so many repeats or clusters of the same titles. This says to me that the randomizer by itself is not doing a good enough job of shuffling the deck. Once again, I'd recommend shuffling a copy of the master list once in a while, or simply using some PHP maths to shuffle the range you are searching. Again, my preferred method would be to place titles on a "blacklist" for a certain number of rounds after it has been called just to be sure. Though you can easily do this for the 3-in-1 games without keeping a blacklist - just check the second title against the first and the third title against the first and second while you're selecting them. If they match, redo the mt_rand().
My reasons for not implementing a non-repeating randomizer is solely because a repeating title may be something new to somebody else and as I said I do not know who is viewing the puzzle.
I don't keep any ip addresses and won't, as a preference,there is no code that stores the visitors ip address.
Visitor info isn't really important for this type of randomization. That would only matter if you were changing the rules of the game based on the number of players at any given time. If that were something you wanted to do, you may be better off just tuning rule changes to certain times of day or for special team battles.
I'm quite tired at the moment, so I may not have been typing in the best of mind. If I've said anything confusing, let me know, and I will try to explain in a better way.
