Something I’ve never told anyone before..
The original plan for the VectorStorm library (apart from teaching myself about a lot of different areas of engine design which I hadn’t learned while working in the industry) was for it to be used as the basis for an open-source “WarioWare” type of game — a collection of lots and lots of tiny minigames. The whole engine architecture was originally built around that concept; the idea was to provide example minigames, and use it as a tutorial both to teach C++ programming, but also to give people an idea about what real game industry code and engines look like.
Now, that game never actually got written; I got distracted by other projects. But the original plan is very visible in the engine’s architecture if you know what to look for.
For example, the whole concept of packaging multiple independent games into a single executable is central to the system — you can create as many ‘game’ objects as you like in a single program simply by creating classes derived from ‘coreGame’ and adding a macro. A single game (called the “mainmenu” game) can then get a list of what games are compiled into the executable, and switch between them. The currently active game can then set a ‘Quit’ command, which returns back to the “mainmenu” game. Each game created in this way is completely separate from the others — they automatically load files from different directories, all their memory usage is intensely sanity checked during transitions from one game to another, and so on. The whole architecture was designed around making it as easy as possible for a new programmer to create a new ‘game’ object which would automatically be linked into the main executable, without needing to write any special ‘set up’ code.
One tricky bit of this is that VectorStorm automatically creates a set of objects called “Scenes” (originally called “Layers’, back when VectorStorm was 2D-only). These scenes consist of layered sets of drawings, each one drawn on top of the previous. So for example, many games will have two scenes; one scene which contains the game objects (the world, the characters, etc), and one which contains the overlaid UI. Each ‘Scene’ can separately specify whether it’s 2D or 3D, can have a separate camera, and so forth. Each game must declare the number of scenes it wants to use, and VectorStorm allocates those scenes and will automatically draw them in the correct order. I did it this way because I wanted the engine to do something useful if the programmer didn’t write any special code at all; if you did nothing, you got just one scene automatically. And you could attach objects to those scenes by calling (for example) vsSprite::RegisterOnScene( int sceneIndex ); (MMORPG Tycoon 2 currently has 10 scenes, mostly to do with correct layering of different bits of the world and the UI.. though several of those could now be combined using the new material ‘layer’ setting)
Where I’m going with this is that as I’m working on MMORPG Tycoon 2, I’m beginning to run into problems; places where I actually don’t want a static list of scenes. For example, in the introductory sequence, I actually want a few extra 3D scenes to work with, which don’t need to be there during the game itself. Inside the game itself, if the minimap is closed, I don’t need to draw two of those scenes. But VectorStorm is very strict about this; every scene gets rendered every frame, whether there’s something in it or not, and the number of scenes is constant for a whole game.
I’m still thinking this through, but I’m getting very close to removing this whole “pre-allocated scenes” structure from VectorStorm entirely, and make it more like a regular engine where games are themselves responsible for creating and maintaining their own scenes. Perhaps they’ll still register them with the vsScreen so that VectorStorm can automatically perform renders correctly, but it would allow games to add or remove scenes as they need them, during the game’s runtime. This would also result in the removal of the “RegisterOnScene(int)” functions on the vsSprite and vsModel; perhaps to be replaced by “RegisterOnScene(vsScene*)”, instead.
An alternate approach would simply be to allow games to disable particular scenes — add “EnableUpdate(bool)” and “EnableDraw(bool)” functions on the vsScene class, so that games can still declare all their desired scenes at startup, but individually turn off updating or drawing of each. This would be a much smaller change, and might be good enough for what I need right now.
I don’t know whether anybody but me is using the VectorStorm engine for anything, but thought I’d bring up these thoughts, just in case. Probably will do something within the next day or two.
