The workaround is now fully in place, and we’ve managed to make things a good deal simpler. Now, our game has the following structure. Upon game start, a “Setup scene” is loaded. The purpose of this scene is to hold the singletons and the travelers. Basically, anything that there is only one of (e.g. the dialog database) or that is expected to move from scene to scene (e.g. the player gameobject) is placed in this scene. Also in the setup scene, is a script which waits till the setup scene is loaded, and then additively loads the specified scene.
(In most cases, Nemed’s bar) Once that scene is loaded, it is set to the active scene, and the game begins. seamlessly changing scenes involves loading the destination scene when the player gets close, and then setting the previously active scene to unload after the player has left. Notice that this leaves the setup scene intact, and objects in that scene are free to do the functions they were designed for, regardless of which scene the player is in. Also, another notable system was cut this week. After some thought, it became apparent that the dialog system is flexible and robust enough to handle basically all of what the quest system was meant to handle. Once that became apparent, it was a simple matter to expand the dialog system enough to meet the rest of the quest system requirements, and make the quest system redundant. The dialog system is now working in greyboxing, complete with events that can be scripted from inside unity. next up on the greyboxing list are seeing how AI interacts with everything else, and how arena transitions will work now that the level manager has been made completely redundant.