On Monday, I resumed my work and started with the vrod-format, which is the most difficult, and risky part of the remaining work. What I managed to implement so far is more like a proof a concept with many hard-coded parts, but it cleared most of the risks, proved it works, and that it can bring even more benefits then I imagined.
I still have some problems with loading fonts from vrod-files, but in order to test that, I'll need to be able to create more complex vrod-files and for that, I need a vrod-editor.
I already started working on one and I think it will be ready tomorrow. Once the editor is done, I can check and make sure fonts can be loaded from vrod-files, too.
I'll have to update the engine to load game resources from either vrod-files or regular asset files (.xnb and .c-cup) and create some c-cup bindings so that vrod-files can be configured from within my c-cup code.
The editor and the changes to the engine are the most complex parts, but I think I'll be able to have everything ready by Monday (evening).
Once I'll have implemented all this, I'll have a great tool for developing games that are more complex.
First of all, these vrod-files help isolate the complexity, and secondly, they provide some unified access facades. These unified facades mean that I can create a vrod for managing game subtitles and then, at some point in the future, I can also change the vrod by adding the mechanics for scrolling back to previous scenes (like Ren'py does when you use the scroll wheel of the mouse).
Doing this kind of change now requires me to edit all places where I use subtitles and make the needed changes. You can imagine this is a lot of work and prone to errors or omissions.
By using a vrod, I mainly have to replace one vrod with another one, in which I have coded a new functionality, and set up some configuration.
In most cases that is all I have to do in order to have the new functionality available everywhere. Of course, it will not be always that simple, but the necessary changes that remain to be done are far fewer than without a vrod if I intend to implement new features.
For better understanding, I present you some more examples what a vrod is good for.
One example of vrod usage is for storing all graphics related to a character (or for a particular equipment). In this case, replacing an old vrod with one with newer graphics will automatically change how that character looks everywhere (or when using that particular equipment).
Another example is shared game mechanics.
Let's say I coded something complex, like everything needed in order to have an inventory for one of the characters in the game (a screen displaying the list of items and their quantities, a mechanism for accounting additions and removal of inventory items, and a mechanism to buy/sell items for money) and saved all this code into a vrod-file. Using this vrod and the extensions I already developed for c-cup, I can reuse the whole mechanism in order to add inventories to other game characters. Additionally, any correction or improvement I make in that vrod will apply automatically to every inventory screen in the game.
Aside from these advantages, probably the greatest advantage will be that it allows me to drastically reduce the number of c-cup-files I have to review and account for when implementing something new.
I still have to be careful about the implications when editing the facade, as changes here need to be updated everywhere, but behind that, where the real complexity lies, I only have to deal with a small amount of c-cup code that can be freely changed as long as the facade remains the same.
Note: At some point, I mentioned that the changes I make for the vrod-format would bring even more benefits than I initially imagined. Here is an example: With these changes in place, I can easily add some code so that my game can load graphics from well-known file formats, such as .png, .gif or .jpg. This means you will be able to alter the game by editing some of the graphics yourself.