Something I’ve never told anyone before..<\/p>\n
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.\u00a0 The whole engine architecture was originally built around that concept;\u00a0 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.<\/p>\n
Now, that game never actually got written;\u00a0 I got distracted by other projects.\u00a0 But the original plan is very visible in the engine’s architecture if you know what to look for.<\/p>\n
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.\u00a0 A single game (called the “mainmenu” game) can then get a list of what games are compiled into the executable, and switch between them.\u00a0 The currently active game can then set a ‘Quit’ command, which returns back to the “mainmenu” game.\u00a0 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.\u00a0 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.<\/p>\n
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).\u00a0 These scenes consist of layered sets of drawings, each one drawn on top of the previous.\u00a0 So for example, many games will have two scenes;\u00a0 one scene which contains the game objects (the world, the characters, etc), and one which contains the overlaid UI.\u00a0 Each ‘Scene’ can separately specify whether it’s 2D or 3D, can have a separate camera, and so forth.\u00a0 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.\u00a0 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;\u00a0 if you did nothing, you got just one scene automatically.\u00a0 And you could attach objects to those scenes by calling (for example) vsSprite::RegisterOnScene( int sceneIndex );\u00a0 (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)<\/p>\n
Where I’m going with this is that as I’m working on MMORPG Tycoon 2, I’m beginning to run into problems;\u00a0 places where I actually don’t want a static list of scenes.\u00a0 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.\u00a0 Inside the game itself, if the minimap is closed, I don’t need to draw two of those scenes.\u00a0 But VectorStorm is very strict about this;\u00a0 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.<\/p>\n
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.\u00a0 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.\u00a0 This would also result in the removal of the “RegisterOnScene(int)” functions on the vsSprite and vsModel;\u00a0 perhaps to be replaced by “RegisterOnScene(vsScene*)”, instead.<\/p>\n
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.\u00a0 This would be a much smaller change, and might be good enough for what I need right now.<\/p>\n
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.\u00a0 Probably will do something within the next day or two.<\/p>\n","protected":false},"excerpt":{"rendered":"
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…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":""},"categories":[4,3],"tags":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/po9WK-Ka","_links":{"self":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/2862"}],"collection":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/comments?post=2862"}],"version-history":[{"count":1,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/2862\/revisions"}],"predecessor-version":[{"id":2863,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/2862\/revisions\/2863"}],"wp:attachment":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/media?parent=2862"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/categories?post=2862"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/tags?post=2862"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}