I see. Then it’s settled. Off to the experimentation chambers I go! 
Regarding the question of performance… it really does largely depend on the format of the game/script style ‘overall’. I think it takes much less to *gosub within the same scene, for example, than to cross scenes. You do indeed understand the heart of what I was trying to express- yes, you can compress information for characters or objects or locations, it just takes work and setting up the code to do so. In the long run, it can save time using the same bit of script to ‘unpack’ information for many characters. Or have a whole bunch of one type of information for all characters in one variable string. Gotta remember there are only 26 letters in the English alphabet and 9 numbers within single digits, though. Doing an every-other letter based breakdown allows 26x26 possibilities, though, but is also a lot more work. How often and how it’s all used, in the script, may or may not affect game/CS engine performance. Basically what CJW said.
CS doesn’t… handle ‘open-world’ particularly well. By which I mean it kinda expects to work from a beginning to an end, somewhat linearly. At one point for CScomp one year I tried making a farming sim game like Stardew Valley or Harvest Moon. It… worked… essentially… but because of how I’d set it up, the game would actually slow down on transitions at some points, with *gosub bouncing, like, *gosub within *gosub, and such- which I’ve never otherwise seen CS do. And I don’t know precisely why it was slowing down, just that, yes, it’s possible to overload CS. I’m pretty sure that was on me, though, and my coding/scripting setup. On the other hand, I’ve also done experimentation with the information packing which shows considerable promise. Which is how I found out an *input_num/number based variable can only be 22 characters/numbers long- any longer and it breaks CS. Yeah, best thing for it is to experiment around! I look forward to seeing what you come up with!
4 Likes