Quote:
Originally Posted by cavedude
I just had a thought, we're going to need those Perl functions afterall for the doors with optional keys. Plane of Time is one example. Once alternate progression is put in, players can enter that zone with either a key OR a flag. That has to be handled by Perl. Unless you want to add a column to the table that says something along the lines of, this key is not required, however if they have it let them in and add it to their keyring.
|
If a player has a key then it won't get to the perl flag code, so nothing needs to change for that reason.
As for database tables, its not like we're going crazy and normalizing every 3 columns into its own table, this is a legitimate reason for a table. Its not uncommon for databases to have in excess of 100 tables. This is the only real solution, and it has the added benefit that it never has to get addressed again. If a case ever comes up in the future where 3 keys could be used, you won't have 99% of the rows with a null field where it only applies to one door. Even with 2 keys, it only applies to 0.1% of the doors, that hardly justifies its own column. This is my professional opinion.