In a nutshell, my devious little brain has gotten the idea that I wouldn’t have to design an entire game if the game designed itself. So, probably spending more effort on making an autonomous random game generator than I would have just writing the thing, my fruitless efforts were halted by one fatal flaw: Generating *create commands.
The general design for the randomness goes something like this:
*temp favourable_size 0
*temp favourable_mod 0
*temp cap 0
*temp adjust 0
*rand favourable_size 3 5
*rand favourable_mod 0 2
*rand adjust 1 2
*if adjust = 1
*set cap favourable_size + favourable_mod
*else
*set cap favourable_size - favourable_mod
So far, that’s worked quite well for me, and I’ve managed to create a random name generator that’s mostly decent (apart from the occasional ‘Oqxllh’), a city/town generator that develops both rural and urban settlements, a quest generator that strings together coherent storylines and people and personality generator that somewhat understands social structures.
The issue with all of this, of course, is that when everything is randomly generated, I don’t really know how many things will be generated. Lets assume that a map allows for 5 - 10 cities, and each city has an occupancy between 10 and 20.
Since the whole concept relies on that *rand command, the problem starts with utilising that specific desired number to create the objects.
Is there any workaround for this concept:
*create loop 1
*label top
*create example${loop}
*if loop = cap
*finish
*else
*set loop + 1
*goto top
Any advice or insight would be greatly appreciated, or if you could perhaps offer an alternative avenue of approach, that would be fantastic. I’m super open to ideas. I’ve come much too far to give up now.
This doesn’t sound too hard, with the right approach.
You’d just need to create a variable for the number of settlements. Assuming this algorythm is intended to repeat itself until the settlements are fleshed out, you’ll just need to make sure that variable, the number of settlements, is created via the specs you want. Such as, *rand mapacitynum 5 10. And, a variable for the city that your algorythm is currently working on. Eg, mapacitywhich, that you would *create at 1, starting off (or 0, if the map can have none). Then, at the end of the algorythm, *set mapacitywhich +1. Under which, you have *if mapcitywhich > mapcitynum - it has a *goto that exits the algorythm. You’ll need to do this for each map, please note, but if you have a variable number of maps, simply apply the same idea except that you already *create the max number of map variables possible for the game, and set them all to false, then, set true those according to the number of maps to be generated, or, simply ignore those that don’t apply to maps to be generated.
I’m not sure I completely understand.
My problem stems from ChoiceScript not being able to interpret ${var} after a *create command. I have no qualms about looping it back on itself until the quota is filled.
All of your *create commands need to be at the beginning of the startup file. Any variable made in another file needs to be *temp, which won’t carry over between files. If you need a possible certain number of variables, it’s better to create the maximum amount that might be needed, even if some are unused. At least, from my point of view- someone else with more experience in *temp variables may have more insights than I.
What I mean to say, is that right now, you look like you’re trying to use *create in the middle of the script, which won’t work.
1 Like
Yes, I see now. I’ll have to work on a workaround then… Maybe I’ll work on some primitive form of a memory storage and retrieval script.
Essentially, all it would need to do is store the things it creates so that it can use them.
Thank you for your insight!
After you’ve made a variable with *create, you can easily *set the variable, which places the new state of the variable into memory (basically), so that the variable thereon can be retrieved as the new state. *set variablea +5, or *set variablea 50; as long as the variable is ‘there’ to be altered, through *create, at the beginning, storing and retrieving is easy. Though for complicated systems, it can get a bit tedious in that any form of sub-creation arrays need variables to track the seperateness …I hope that makes sense. IE, that you don’t overwrite city A’s data when you set the variables in city B’s data. - That they aren’t the same. Having the game create your game world at the beginning, going through the creation process for any generated content, is likely better than attempting to have the script come up with the data for a city on the fly in the middle of the game, for retrieval purposes- but the quicktest has trouble with open-world systems that create an exponentially large number of choices to check, as it tries checking all possibilities and can get caught in infinite loops. Just a fair warning, in advance. Lucid has mentioned he has an RPG system in the works that passes quicktest, so I’d probably recommend checking with him for further advice in RPG-CS-system-development.
