SLE: depth selectors considered again.
I might as well write this down while I remember, since I can't seem to sustain any organized thought on it.
Everything in the last post is probably crap. The solution shouldn't be more complex than the problem, and I think that might be the case with the idea in that post.
If the World object has an instance of the depth selector, why shouldn't that be enough? All selection and generation of content will go through the World object anyway. So instead of divvying up all the content tables amongst the maps, why not just create a cache table in the original depth selector itself? Advantages:
- the entire table is populated at startup and doesn't have to be regenerated during the session
- since it's populated at startup and doesn't change, it doesn't have to be saved
- different maps with the same depth can easily reference the appropriate selection input
- dynamic or mutable depth is accommodated without regenerating the input
There must still be some way of passing the desired depth to the selector so that it can choose from the right input while adhering to the selector API. If the World object has a cursor which points to the map currently being processed, the cursor can be accessed by the selector to retrieve its depth. This is important in accommodating my dynamic level action mechanics. If I can think of a more elegant way, that would be great, but the underlying machinery doesn't have to be documented, only the API, so if it works, it works.
Time for bed, I think.
Everything in the last post is probably crap. The solution shouldn't be more complex than the problem, and I think that might be the case with the idea in that post.
If the World object has an instance of the depth selector, why shouldn't that be enough? All selection and generation of content will go through the World object anyway. So instead of divvying up all the content tables amongst the maps, why not just create a cache table in the original depth selector itself? Advantages:
- the entire table is populated at startup and doesn't have to be regenerated during the session
- since it's populated at startup and doesn't change, it doesn't have to be saved
- different maps with the same depth can easily reference the appropriate selection input
- dynamic or mutable depth is accommodated without regenerating the input
There must still be some way of passing the desired depth to the selector so that it can choose from the right input while adhering to the selector API. If the World object has a cursor which points to the map currently being processed, the cursor can be accessed by the selector to retrieve its depth. This is important in accommodating my dynamic level action mechanics. If I can think of a more elegant way, that would be great, but the underlying machinery doesn't have to be documented, only the API, so if it works, it works.
Time for bed, I think.