Apologies for anyone who subjects themselves to this post; it’s going to be incoherent, but I wanted to do this publicly instead of on my personal wiki because I do hope someone sees it and either affirms my idea or slaps me silly for even considering such an approach.


In my space game, I have always started it with the idea that a player would “bang” (as in “Big”) their own unique universe when they start a new game. I have a lot of code that I have written and ported around to various platforms that generates stars, planets, stations, asteroid belts, shops, and jump gates connecting systems.

What it does is create data structures. They have no form. Instead, I have always tried to create “a single scene” which builds itself dynamically by reading info on “the current star system” when the player enters it, and then instancing and assigning visual resources based on the associated data. For example, if a system has three planets, then we instantiate three “planet” objects in that system when the user enters; however, the entire thing “goes away” when the player leaves, and a new system is “built” wherever the player ends up. Further down the line, as a player opens a shop’s inventory, that shop’s data is loaded from the data store and icons are instanced and displayed, on demand.

The main reason for this is that running from data means I can use a Big Bang system to generate a game world “between 2 and n” star systems without having to hand-code them all. More importantly, as a game centered around interstellar commerce, I want to have a simulation system which changes prices based on inventory, availability, and in-game events.

All of the data needs to be available en toto for the simulation to make its decisions and to affect the places it needs to affect, and I need to be able to consolidate the modified data somewhere that I can save it out to disk for use in the next game session.

Every time I try to spin up this project in a new game engine, the first concern is “how to model the data” so that it’s available where needed, and how to make it available to the simulation. In the case of Godot, that seems to be “via Resource objects”, but how to use them? Do I create a single scene to serve as the container for data-driven, runtime-loaded Nodes of Scenes? Is there something else?


Runtime-created Scenes, filled with instanced Nodes, with a side of mutable data overrides, all of which is created by the Big Bang data and serialized to disk, making up a “new game”.


The idea is that there are a few Scenes which are hand-crafted and ever-present to provide services such as intro splash/loading screens, main menu, save/load, and settings (high level concept descriptions). These could be always loaded but hidden, or depending on the function of the scene, loaded and unloaded on demand.

A “new game” would run the “Big Bang” routine to create data in memory but unlike how I’ve done it in the past (all star systems > all planets > all stations, et. all > sorting and assignment), this time I’d do it by star system. The star systems would all still need to be created first, because I need to generate links for jump gates, but once those two steps are done, each star system would be built before the next one is started. That includes adding the star types, planets, stations, and other intra-solar features.

Now, though, rather than just writing the data to a data store, I’d create one scene per solar system. Starting with a template (or an idea) and a handful of flexible Scenes, I could create a “SolarSystem.tscn” which contains “Planet1.tscn”, “Planet2.tscn”, “Planet3.tscn” Scenes, each of which might have a “Station1.tscn”. Of course, a station Scene would have all of the UI and elements needed for proper use, but the inventory would be stocked with all items possible for sale, their icons, names, descriptions, legality, categories, and base prices. All of these objects would make up a dynamic Scene which would be created and serialized to disk.

I would also need a Resource-based object which contained a list of all solar systems, and their jump gate links. This is for map-making purposes and to validate routes. As I cannot look into a Scene that isn’t loaded to get that kind of info, I would still need a “master reference” data source to ensure that a path from one end of the galaxy to the other is valid.

I would also need to maintain the mutable “effects list”. This is the ongoing and updated info data store that would be used to modify inventory and price of items at commodity shops and shipyards. I would have to look at this when a player opens a shop at a specific station around a specific planet in a specific solar system to see which items are being bought and which items are being sold, the quantities in question and regional, faction, or event-modified price at that location. This might be easier, though, if I only kept modifier values on hand, along with current inventory, and updated the props of the commodity and shipyard item Nodes. When the Scene is unloaded (and the player moves to the next solar system), the scene is serialized to disk. That kind of takes over the need to “save” the game, as updates are written before they go out of scope; the alternative being that I do maintain the “master number list” above actual implementations, and only write that to disk when the player manually saves (or autosaves). I am not sure which is the better option. The same would apply to the player re: hit points, fuel, cargo, and money on hand.

tl;dr: After banging the Universe, build Scene files that contain data-constructed Nodes of other Scenes derived from templates hot-loaded into that solar system Scene. All values from the bang are set as props of the Nodes. Each Scene is serialized and saved to disk and can be loaded based on where the player is going via in-system jump gates, sourced from a high-level Resource map of the galaxy. I’m unsure if this will work, or how to deal with the dynamic runtime modification of values such as inventory and pricing, or the fallout of simulation-driven events throughout the game world.


Owner and author.

Leave a Reply

Your email address will not be published. Required fields are marked *