Last time I gave an overview on what VBuilder is and how it improves iteration times. This time I'll give a small example by showing some extracts of what it takes to setup a project.
VBuilder is driven by commands coming from an XML file. Here is an how this can look like:
<!– register data resource –>
<!– load the cmo –>
<!– execute build process –>
<execute_script name="Load Buildings"/>
<execute_script name="Load People"/>
<!– set the save options for images and sounds –>
<set_save_options name="images" value="IMAGEFORMAT"/>
<– save to VMO –>
So first one or more data resources are registered. Basically it's adding the search paths for external resources like textures and audio. Then a CMO is loaded. It contains the import and processing logic which then gets triggered. Usually you have textures outside but if you want to include them for the final file, this can be done like shown above with the save_options commands. At the end the new VMO, that includes freshly imported assets, is saved and can be started ie.e with the webplayer.
Btw. VBuilder also supports commands like setting values for script-parameters – very useful for making sure that debug-information is turned off for release builds!
So how does the assets import looks like? Well, this is adjustable to your needs but here is how I often do it:
So basically it's a scriptable build pipeline. Some people asked in the past years what we do and here you got it finally unveiled. It's actually a pretty simple concept and similar to bigger gamedev projects. I could bring it even closer to traditional gamedev projects: a future version could detect what files changed and only process those. That could be VBuilder V2.
Feel free to contact me about it, if you're interested to use these tools. I say tools, because I would add BBs like the Directory-Parser which is especially useful for projects that did not license the XE player.