Some people have been asking me how to write new scenes using my Scene_Base architecture. Here's an overview of how it works, and how different it is from standard RMXP's scenes.
RMXP's Standard Architecture
Here's a pseudocode template of a standard RMXP scene.
class My_Scene def main create windows and sprites process transition begin loop update frame call update check if another scene was created, and if so, abort loop to end current scene end loop erase windows and sprites (dispose) prepare for next scene's transition end def def update update each window/sprite check for inputs and do the appropriate stuff for each key end end class
Seems perfectly fine as is, now doesn't it? However, when you think about it, several issues can arise with that simple, straightforward architecture:
- If you want to add a new window to the scene, you are forced to rewrite its main method entirely, because it's in a single piece. Thus you cannot use two scripts at the same time, which modify the same scene, because the latter will systematically override the former one.
- All RMXP scenes rely on this same architecture, thus the same lines are written over and over again, which is unnecessary repeating.
- Because of 2., if you'd like to tweak all scenes at once (for example modify the transition at the beginning for all scenes), then you have to rewrite all of them one after one.
Of course, as long as you're not dealing with editing scenes/making new scenes, you have little concerne for such issues. But since I've had the occasion to make some heavy on scenes, I thought it was about time to do something about it, and that's how I came to write the Scene_Base class.
Moonpearl's Scene_Base architecture
The Scene_Base class was written to address the previously stated issues. It was meant to:
- Provide easier writing for new scenes since you don't have to rewrite all the base code.
- Handle scenes in a more modular fashion to allow easier editing.
- Make it possible to tweak all scenes at once
Here's an overview of how the Scene_Base class works.
Now let's see how we could write an entirely new scene using this architecture.
class Scene_Base def main call setup begin loop frame update call update end loop call terminate end def def setup create windows/sprites and list all of them in @sprites end def def update update all windows/sprites listed in @sprites end def def terminate erase all windows/sprites listed in @sprites (dispose) end def end class
One can easily see the first benefit, which is a substantial saving of code, which in turns means a substantial saving of time and energy. But that's not all. Suppose we further want to edit our new scene as an independant script, while not rewriting everything from scratch. Here's how to add a new window/sprite:
class My_Scene under superclass Scene_Base # No need to redefine main method def setup create windows/sprites and list all of them in @sprites end def def update call superclass's method check for inputs and do the appropriate stuff for each key end def # No need to redefine terminate method end class
This is just enough since our new window/sprite is listed in the @sprites Array, which means both update and terminate will handle it as any other previously created window/sprite. Likewise, suppose we now want to ass new functions to our scene, for example make it able to respond to a new key.
class My_Scene under superclass Scene_Base # No need to redefine main method def setup call former code create a new window/sprite and add it to @sprites end def # No need to redefine update method # No need to redefine terminate method end class
As you can see, we stick each time only to the necessary edits. Furthermore, this allows several edits of the same scene to coexist, because we do never rewrite a part of the code, we only expand it with new features, always calling the older version.
class My_Scene under superclass Scene_Base # No need to redefine main method # No need to redefine setup method def update call former code check for the new input and act accordingly end def # No need to redefine terminate method end class
As an example of how powerful this architecture can be, you can have a look at my Scene_Menu_Base class, from the Animated Custom Menu System. This allows all menu scenes to exhibit common features (namely, a background image and a scrolling overlay). Basically, it's written that way:
Now we just have to write new scenes listed as subclasses of Scene_Menu_Base, and since we'll keep on calling formerly written code, the background/overlay will automatically show, and the overlay will automatically scroll, with no need to state those explicilty in our new scenes.
class Scene_Menu_Base under superclass Scene_Base # No need to redefine main method def setup create background image and add it to @sprites create overlay and add it to @sprites end def def update call superclass's code move overlay end def # No need to redefine terminate method end class
I hope this quick overview could persuade you how the Scene_Base architecture can be useful and handy. If you were trying to write your own scenes with it, I encourage you to do so, and I also hope it did clear things out for you.