I’m in the planning stages for a game that will likely contain multiple separate puzzle areas rather than a single narrative. I also intend to add areas as time goes but the game will be playable as the “world” expands. The lack of a single narrative will mean folks don’t really lose progress when the game is updated.
I imagine I’m not the only one who writes and fixes stuff as they go along and is sometimes bewildered by their own work when they return.
I’m good at documenting what I’m doing but, inevitably, as things go along my grip on the way that older parts work together and why, is going to go from being tight to ephemeral.
With that in mind, and considering I am planning a sandbox where people will do small puzzles, and I will add to those puzzles from time to time, is there any way to create a game with walled off sections but that a player can move between?
I know there are regions and scenes but maybe there are other ways folks keep stuff sectioned off so rules and ifs and every times don’t get all snarled up as the game grows.
Keep in mind that the docs overstate there being some essential relationship between scenes and time. Scenes are a utility player. They can be triggered by any game state you could write a condition for and you can put during <scene name> in any rule preamble or use if <scene name> is happening as a conditional in any block of code, so they’re great for the isolation you’re talking about.
In fact, they don’t have much to do with time. OK, they have a discrete beginning and end. And then there’s the truly trivial: at any given time a given scene is happening or not. Just like at any given time a given global variable has a given value or not. This isn’t a coincidence – that’s mostly what scenes are: some helper functions around the very basic concept of having some global boolean variables and basing various bits of code behavior on whether given variables are on or off.
Remember, also, that even though they’re not objects per se, scenes can have properties. So if you have some list of values to track on a per minigame basis, making them properties of the scene could be a convenient way to do it.
When moving in between test chambers, a special “material emancipation grill” destroys any objects the player attempts to take with them while allowing the player to pass through.
Implementing something like this would reduce the unintended interactions of objects from one zone entering a zone written later. You wouldn’t have to destroy the items either. Perhaps guards could confiscate contraband, or customs officials could make you leave your items in a locker while you’re gone. Baking something like this into the game will surely save you headaches in the future by helping quarantine the sections better.
As an additional thought, you may want to ditch the traditional save function for one that uses recorded tables to take down inventory and various world and character states. Otherwise, each time you bolt on a new section to your game, it’ll invalidate any existing save files as it will ostensibly be a new game file. If you would like previous players to continue playing with each new installment, forcing them to repeat their previous progress each time would probably be discouraging. I believe @Afterward did something similar to that in Ryan Veeder’s Authentic Fly Fishing, but I’d be fine with being corrected if I’m wrong.
Save files aren’t portable between releases even if the difference between releases is just a trivial cosmetic one. The alternative is taking on implementing your own independent save game system, like Ryan Veeder did.
Yes, it works just fine in HTML (Ryan Veeder’s Authentic Fly Fishing is web-only, for various dumb reasons). When the game tries to write to an “external file,” the Quixe interpreter instead writes to a token in the browser’s LocalStorage… I think. And it reads from those tokens as if they were external files, no problem. I really didn’t have to do any extra work to get the interpreter to handle these “files” properly.
While we’re on the subject, though, I want to bring up a caveat for applying this save file paradigm to games you plan to expand: Give yourself way more space in the tables than you think you’ll need. If you end up having to change the format (or even just the size) of a table when people have the old version in their save files, you’ll have a devil of a time converting their data to your new format.
For RVAFF, I had space in the “inventory” external file for 200 collectable items, which is maybe three times more than I needed; I also had several dozen extra rows in the “miscellaneous” file in case I added a bunch of other customizable hats or something. So I never ran into the problem described above. But I’m trying to think of how I would handle it, and it’s giving me a headache.