Variables and maxing them out


Choosing to make a game on the Gameboy is about limitations. You’re faced with them at every turn and your game gets shaped by them. 

Want an extra frame in your run cycle mid way through development? Better find some details you can remove from the background tiles (potentially across every level). Choices between a second enemy type on a level or an extra collectable, with sprite, tile and palette limits to stay under. Juggling this with the constant concern of slow down from the ancient CPU.

When I began to plan out Fall from Space, I was aware that I could be pushing against a number of hard limits. File size is something I’ve been constantly monitoring, checking the size against my estimate of percentage left, but also, the overall project variables count.

GB Studio has a Global Variable limit of 500, so from the start I’ve been very conscious to minimise the use of these, using flags where I could and also local variables where possible. I thought I was doing fairly well, but I made one major mistake.

Local variables compile as global variables

This, I didn’t plan for, and if your total variable limit, global and local combined, is over 768, you can run into problems, particularly with saving and loading the game.  This is something I became aware of in the QA testing of Tales of Monsterland DX, but, thankfully, it wasn’t far from this limit, so I could easily bring it under. However, I made a (slightly concerned) note to check how Fall from Space was shaping up and it was at –

1056/768 variables.

*screams*

1056 and the game has a lot more content to come.

  

Reducing the variable count

To find your own total variable count in GBS –
GBS menu, Advanced -> export source -> open include/data/game_globals.
Search for MAX_GLOBAL_VARS, if the number is higher than 768, it can apparently be bumped up to 800 without a problem

After the sinking feeling in my stomach had subsided a little, I found two areas of the game that I thought were the main offenders, where I had definitely used a ton of local variables –

Enemy AI

Perhaps unwisely for a system with limited resources, enemies, rather than travel on a set path, monitor and react to the player's position. If the player is to the left of an enemy, it’ll turn around and head towards them. When the player is close to the enemy, it’ll telegraph and then attack.

This was all done mostly with local variables. Enemy stats were also passed from central global variables ‘wheel bot HP’, ‘wheel bot DMG’, into local variables.

To improve this, reusable global variables were created for the enemy AI: getting hit and hitting custom scripts, times 7, which is the maximum currently in a scene. It was tedious to replace all these across the game, but 1056 variables became 780.

Still over the limit with a lot more enemies planned, but better.

Coins

Fall from Space is an open world and fairly non-linear game, you can visit and revisit levels to explore and find secrets. Coins (credits) operate in a similar way to XP, being used to purchase upgrades and items.

As levels can be revisited, coins needed unique variables to mark as collected or not, and there’s no way around this. Previously, they neatly used their own local variable for ‘collected’ and a custom script for when the coin is collected (that fed in the coin value). They could then be copied and pasted quickly without modification, remaining unique. However, having just a few coins on each scene can very quickly add up to a lot of variables and it’s simply unsustainable for a larger game.

I didn’t want to drop coins or vastly reduce them, so the best compromise I could find was to create new global variables using flags, e.g. Coins_1A (planet/set group) . Each coin within that group has its own ID that I could reference in a new custom script to mark a coin collected.

Flags allow 16 on/off switches within a single global variable, so I figured it should be a sizeable (16x) reduction (all the quests in the game were already built using flags).

1056 variables, which were reduced to 780, were now reduced to 522 overall, with plenty of global variables available.

With the majority of the game engine built, quests and coins fitting 16 variables into one, and no doubt other efficiency improvements I’ll make along the way, the project in its full scope is  viable again.

Conclusion

Variable counts are just as important as file size in how feasible your GB Studio project is, but somewhat of a hidden issue. This needs to be taken into account for all projects, but particularly those larger in scope.

I’m still likely to optimise further, with all the hidden nooks and crannies I’ve snuck local variables into, but the project is back on track, after a (thankfully brief) struggle. Hopefully any other GB Studio devs who weren’t aware of this hardcoded limit can take steps earlier than I did and save themselves the headache!

Thanks to Chris from Spacebot Interactive for tips on increasing the total available variables slightly, as well as how to get that combined total in the first place.

 

Get Fall from Space Demo (Game Boy / Analogue Pocket)

Download NowName your own price

Comments

Log in with itch.io to leave a comment.

(+1)

Yeah, also I am glad for sharing a post about this themathic. Will try to consider it in case I sould be getting into developing in the future.
So thank youuuu for sharing your expirence, I appreciate that!

(+1)

Not a problem, good look with the development when you do! A great resource if you don't already know it is – http://gbstudiocentral.com

(+1)

Thank youuu!
Well I allready came across gbstudio and it actually one reason why I came to the pointv thinking about doing development for old consoles/systems. But yeah so far it just have been thnking and trying arround, nothing too important...
But still thank you for pointing that out and wanting to help out!

(1 edit) (+1)

Yep.. happened to me too. Want to make a video about it. I had to go back on every corner of my game changing from local to temporal when I had the chance (whenever someone asked you a yes or no answer and stuff like that). I also turned many of them to flags, and it was a nightmare because I had to keep track of them on an excel ha ha ha. This took months to fix. I also used a global variable that was shared among minigames or numbers that could be reset on init screen.

I discovered this issue when I realized the variables were rewriting themselves (I didn't know you could check how many active variables the game had).

I feel you, it was one of the most terrible feelings I had while scripting the game, because I knew the only "fix" was going back and redoing most of the interactions and stuff. A valuable experience that will not repeat itself. Local variables can turn your project into a nightmare, and temporal ones are your best friends (whenever you can use them of course) alongside with flags and using global variables multiple (and I mean a LOT) whenever you can.

God I could re live the feeling just reading your post. I shared my experience with my Kickstarter backers, but a proper video showing this tips needs to be done ha ha ha.

Im sorry it happened to you, but I also know you will never, NEVER ignore that issue in the future. The trauma can be huge ha ha ha. Cheers and best wishes on your project!


PS: Deactivate the "view connection lines" as well and get used to work without them, no matter if you are working on an old pc (like I did) or a PC master race moster machine (tested in a few). By showing them on your project you will start getting unbearable slowdowns with everything (including simple stuff as writing dialogue) and you won't be able to even select scenes anymore ha ha ha. "Flies away"

(+1)

My post should have come with a trigger warning!

Funnily enough I was thinking of your project and wondering how you got on, since it's open world, huge and you can go back to the areas, that seems to be the big problem. Even now I'm thinking about all the triggers that I have that need to trigger just once and I'll have to convert to flags at some point, it must have been a nightmare for such a big project, I'm glad you got through it!

Some in game labels to flags would be a nice addition to make things easier.

I'll be interested to watch the video and hopefully that and this post can stop a few people who might do the same thing as we did otherwise!

(+1)

One of the most exciting things I saw in the upcoming GB Studio release was the feature to name each individual flag within the editor! Potentially less referencing of excel sheets for variables coming soon!

Yes! I can't believe it's out already, it'll be so much better having everything in one place, in the project

(+1)

This is so useful to know! For big games these limits are so important!

(+1)

thanks for making people aware of it!