Refactor and Integration Devlog
Hey there, devlog time!
Like I said previously, I have paused the sex framework development to work in refactoring the game codebase, as well as integrating everything I have done in it.
Let's break this devlog into sections, shall we?
Codebase Refactor
This is what has kept me busy these past few weeks, refactoring the entire game code has been def a buggy process.
I believe once I got the game playable there were like 50+ crash report files in the game's folder , putting everything together was a bit tedious but definitely worth it.
There's a lot to talk about this since the game code organization has completely changed behind the scenes, but to keep it easy-to-understand, let's just do a Pros and Cons list:
Pro's
- Game codebase is organized in a way that is 100% mod-friendly.
- All monkey-patching has been simplified and replaced with my system of event callbacks
- Critical parts of the code has been overhauled to be mod-friendly, for example:
- Audio Manager (new)
- Vanilla RPG Maker does not have an audio manager per-se, it interacts directly with the native Audio module using the RPG::SE, RPG::ME, RPG::BGS, RPG::BGM data structures, this is how it was done prior this refactor update and it was a whole mess, specially because each audio data class has the ability to play itself, the new module Audio Manager manages all of this in a single place in an orderly manner
- Vanilla data structures (RPG::SE, RPG::ME, RPG::BGS, RPG::BGM) has no way to use an audio file added by a mod, so they were only able to play audio from the base game, a new serializable Audiofile class has been added that allows referencing to any file from the game root folder (supporting mods).
- Wraps every new MKXP-Z function available cleverly
- Integrates the settings module
- Data Manager (overhaul)
- *Check Data Manager Overhaul section below*
- Database (new)
- All database global variables has been replaced by the new database
- There is no more globals polluting the global scope
- Ensures compatibility with mods code that may be added
- Partially integrated key parts of the mod system (see Roadmap for reference)
- All game objects globals has been replaced by "static" modules
- There is no more globals polluting the global scope
- Ensures compatibility with mods code that may be added
Con's
- It is very likely that none of the existing free plugins for RPG Maker will work with the game, for example the Yanfly plugins that every RPG Maker game uses won't be compatible "out of the box"
- By "not compatible out of the box" I mean that every class definition has changed in either a minor or major way, so these scripts would need to be adapted manually to work.
- It is very likely that no save editor software will work with Sana Revamped, this is because the game objects classes has been modified in such a way that won't be compatible, also, the usage of mods will render all of these tools incompatible, unless they are modified to process the game savefiles in the same way I do it in the new data manager.
To compensate the con's explained above:
- I have been working all of this time to replace and remove external plugins gradually preparing for this refactor, as for now, the only missing third-party plugins which has not been integrated into the new codebase are yanfly's message system overhaul and the diagonal movement script I used in v0.1, not a problem since I have planned to work on my own overhaul for the message system in the game later in development, I have some ideas and design ready for this, so eventually, the message system overhaul won't be needed, I have removed diagonal movement script and won't work on it as for now until I fix some weird behavior with it, maybe this one will end up being discarded (not a priority for now).
- As for the save editor, I personally don't see it as a problem, especially because I have created an in-game console, you can use this to cheat on the game, but it is not a plug-n-play solution since it requires you to know how to use commands and what they do exactly.
The refactor is not fully completed as for now, there is still a few systems I have made which are not integrated, eventually all of them will be integrated
<-- I'm currently working on this.
Loading Scene
A loading screen is definitely a must-have, especially for a game that is expandable with mods like this one, basically because the more mods you have installed the more time the game will need to load everything.
The thing is, since Sana Revamped supports mods and also suports enabling and disabling them, I needed to implement a new database (which we have talked about in the past), building this database is a very complex process, it can take from a short to a long time depending on the number of mods installed and your computer.
I have been having a lots of problems implementing a loading screen on the game, mainly because RPG Maker games are single-threaded and does not support multi-thread operations at all (at least RPG Maker games made in XP/VX/VX Ace, dunno about MV/MZ) meaning that the whole game runs sequentially, one line of code at a time.
First I tried adding a custom scene which created a new thread running the code to load, so we would have two threads, the main thread which will refresh the screen and update the sprites, animations, etc... and the thread that runs whatever code they are given, the problem is that, a lot of the code in RPG Maker is not thread-safe, because it was never made to be thread-friendly to begin with, so the game would inevitably crash if any piece of code is given to the thread which is no thread-safe (for example: loading a savefile would crash the game).
I thought about shifting responsibilities between the main thread and the son thread (main thread runs the logic and the son thread refreshes the screen), but it turns out that the native functions to refresh the screen are not thread-friendly either, (Graphics.update) so it will lock the process indefinitely until it is killed by itself, so this means that
there is not a real loading screen on the game.
So we are stuck with single-threaded processes, still I wanted to show something on the screen meanwhile the game is running some complex code, since the screen is not refreshed it will look to the user as like the game has crashed/frozen, so I have come up with a "dirty" solution per-se, which is showing an image on top of the screen before the game runs the complex code and hide it after it finish.
I have modified the base class for all scenes to include methods to show and hide the loading screen bitmap, it also supports fading the load screen in and out, which you can see in the GIF below.
Do not mind the ugly art, it is a placeholder I made in MS Paint to test it lol.
Right now the loading screen is pretty much useless, because there is not much code to process, there are only like 4 mods which they are not heavy to load at all, but it will be useful in the future.
Also, as you can see, the load screen is not used everywhere, since it must be shown manually, it will be used only wherever I expect the code to be complex, like rebuilding the database, starting a new game, loading a savefile, etc... A transition between the title screen and the settings screen does not need to load anything heavy.
Data Manager Overhaul
The data manager overhaul was something I planned to do for v0.3, but once I started refactoring the codebase a few weeks ago, I had to push back this feature for v0.2, the reason why is because the way game objects are organized now needed the new data manager.
Since I had to work on this I asked myself, why not implement everything I had planned for this in v0.3 now? So I did.
The new data manager includes
new features as well as
quality-of-life enhancements which I think you guys would love every other RPG Maker game to have, savefiles has been modified:
- Savefiles are now saved with a new header, this header includes:
- Game version
- Version major integer
- Version minor integer
- Version revision integer
- Version string
- List of all mod IDs installed
- This list contains all mod IDs that were installed at the time when the savefile was created
- Map location
- A string representing the map location (map name) where the savefile was created
- Total playtime
- A string representing the total playtime in the format: HOURS:MINUTES:SECONDS
- A savefile description
- A string containing a small description the user can change to to describe the savefile
- The user will be able to change this description value before creating a new savefile
- Savefile thumbnails
- Thanks to MKXP-Z, I can include a binary representation of a bitmap, so every savefile will include a image thumbnail at the time the savefile was created
A new savefile header is not the only new thing left tho...
The
data manager now supports different profiles, you will not need to move savefiles around to try other people savefiles, which is something you probably have done several times as for now, so you can have:
- Saves/
- Saves/profile_1
- Saves/profile_2
- Saves/profile_3
...
- Saves/profile_n
All savefiles are saved within a folder which represents the profile, you can have as many profiles as you want inside the saves directory.
So you can have different profiles to play the game in different ways, also, the known hard-limit of the number of savefiles of RPG Maker games has been removed, you can create as many savefiles as you want,
the new data manager does not impose any limit so you are free to have 1,000 savefiles if you want to.
- Saves/
- Saves/profile_1
--- Saves/profile_1/Save1.rvdata2
--- Saves/profile_1/Save2.rvdata2
--- Saves/profile_1/Save3.rvdata2
- Saves/profile_2
--- Saves/profile_2/Save1.rvdata2
--- Saves/profile_2/Save2.rvdata2
--- Saves/profile_2/Save3.rvdata2
--- Saves/profile_2/Save4.rvdata2
--- ...
--- Saves/profile_2/SaveN.rvdata2
- Saves/profile_3
...
- Saves/profile_n
Also, as you can see in the video, there is a new option on the title screen, which is Load, it allows you to call the loading scene and load whatever profile and savefile you want.
There is also a "Continue" option, which it will process the whole Saves directory and load the most recent savefile available, so you don't have to go to the loading scene, selecting the appropiate profile and choosing the savefile everytime you wanna play the game, this button will be automatically selected for you everytime the game is started if there is savefiles available,
quality-of-life baby.
The first black screen in the GIF is because I forced a game reset (F12) to load the scene again, so you can check it out at the start.
As for now, the description cannot be set, that's why in the video it is not shown, but the code exists, I will probably finish this in v0.3
Like I said, since this was not planned for v0.2, I won't be spending more time testing it exhaustively, so bugs may happen, I will fix anything that may happen for v0.3
What's next?
The first thing to do is finishing refactoring the game's code, meaning that I need to integrate the rest of systems that were not integrated as for now.
Then, finish the sex framework, the next devlog will be about this.
