End of Year Update
Hey people! So... good news and bad news, first, the bad ones.
Bad news
As you can probably tell, the v0.2 won't release by the end of the year like I have planned, obviously I found some problems which I still need to deal with before releasing the next test version, these problems ain't got nothing to do with the sex scene framework (thankfully), it is something else and it was bad enough to take my attention.
I've investigating this issue for the past week and the root of the problem was that, injecting scripts into the game was causing lots of unexpected problems when starting a new game (or loading a save) and going back to the menu to start a new one, at first I thought that the problem was with the mods I was using to test the mod system and not with the engine itself, but then, I discovered a "rabbit hole" that I did not "notice" earlier.
This "rabbit hole" causes what it is called "undefined behavior" in the game, this problem occurs for two reasons:
I saw this problem coming back when I made the mod system, I designed the mod system to allow the user not to reload the game when a mod with scripts is disabled (event-based mods), but that requires a lot of effort, not only in my part but on the modders' too, certain mods may inject scripts into the game that requires a full restart, because they might add a lot of new things (or touch parts of the code that should not be modified) and break the game.
So I have decided to change this to make the game mod system more robust, I gave up on this idea and I'll force a reload if one or more mods with scripts are loaded, I still need to add a window about this in the menu where you manage the mods but it will be done, eventually.
- Non-standardized lifecycle
Mods that injects scripts into the game has an undefined lifecycle, this is not bad per-se, because it requires the modder to decide how to handle whatever they are adding to the game (I dunno, like a reputation system, a fame system, whatever....), but when it comes to interact with certain parts of my code (like the game map, or the player) it provokes lots of synchronization issues, because, since they don't have the same lifecycle, they don't "behave the same" in a orderly manner, for example:
> Modder A creates a mod that adds visual effects on the current map.
> Modder B creates a mod that zooms into the current map.
> Both modder A and B needs to know when the game is started, either by loading a save or starting a new game to create their effects.
> The user starts a new game.
> Modder A fights with Modder B to decide who is the first that modifies the current map instance.
See the problem? Some times Modder A will win this race and update the map before Modder B does it, and this is not a problem because they don't really depend on each other, but
what if Modder A requires that Modder B applies their changes before applying theirs?
That's why I decided to standardize the way game objects are created into the game and control their life during important events in the game, check out below.
Good news
I have made some important changes into the game, first of all, game objects in the game must follow a standard, this standard is called "Entity".
An entity is something like an object in the game, something that must exist during the whole game runtime and perform whatever they are doing in a ordered manner.
The entities will use hooks to run critical parts of their code when something important happens in the game, for example: starting a new game.
I also dealt with code priorities using a method #hook_dependencies(...), which will determine the order to run the hooks based on the dependencies each entity defines, so for example, if I need the game player to execute some code when a game starts BUT I need the game map to do it before the game player does it, the game player will define that their game start hook depends on the game map game start hook, so the game will run the game map hook
before the players'.
I also separated the capability to be serialized (saved into a savefile) from the entity, because not all entities must persist in the game, modders will decide whether their entities are saved into the savefile or not.
I have made some other changes, now the module that handles the savefiles in the game won't allow overwriting entities that shares the same ID, I have decided to do this to prioritize the savefile health above everything else, avoiding possible corruption if a badly designed mod is installed.
I don't want to bore you guys with code updates, so lets skip to the better-better (more visually pleasing) news.
I have made a little modification in the mod manager menu to reflect which mods include scripts, nothing to mind-blowing but Quality-of-Life rules.
Notice the little "
*" in the mod's name? That means that mod will inject scripts into the game (if it is enabled). Any other mod that does not have that will be safe to enable/disable as many times as you need, for example, mods that add static data like animations, events, or language packages, etc...
You may also have noticed that the window looks different, well, I have added new settings:
Nothing too crazy, something that 99% of games made in RPG Maker has, you can tweak the window's tone and you can have your dark-mode UI in the game now! Also you can tweak the game notification opacity, by default it is set to be transparent but if for some reason you want a background, there you have it.
I have finished integrating the animation system into the game, this is a key part not only because now you can play basic animations that are not sexual but also because the sex scene framework heavily depends on this, check out this video below:
The basics of the animation playback are implemented as you can see, you can tweak the position, visibility, playback frame rate, speed, etc...
One of the latest changes I've made is that I have separated the playback speed from the animation frame-rate, now the speed is determined by a factor that it is applied to the animation playback (0.5x makes the animation slower, 2.0x faster...), it allows me to slow down the animation to less than 1 frame (or speed it up a lot).
The sex scene framework uses this internally to play the sex animation, and not only does that but also it allows to insert any number of overlays dinamically sync'ed to the animation, also everything you saw in the video will be able to be tweaked by addons, some things like speed will affect the pleasure each actor gets during the sex scene, I already have some cool ideas for sex scene addons in the future, you'll see...
There are other things that I might implement eventually, like animation flashing, animation waving or changing the angle, but for a first version it is decent enough!
Other irrelevant information
In other news you might not care at all, I have wondered how big the sex scene framework currently is, so I have used a little tool to count the number of scripts I have done, and man, I did not expect the result to be honest.
It sits at 42 script files, still it is not finished, so it may increase or even decrease if I end up deprecating parts of the code for something better.
For reference, the mod system currently sits at 75 scripts, there are a lot of files compared to the lines of code because there is a lot of inheritance and polymorphism involved, there also some other scripts not counted because they are in the game-scope instead of the engine.
So yeah... That's all, Once v0.2 is released I'll update the Trello board and the roadmap I did to reflect the changes, for now, I wish you a happy new year and happy gaming!
