GML How many cases can be in a Switch statement?

[anthropus]

Is there a built in limit, or a practical limit (causes slow down), to the number of cases that can be in a switch statement? does it matter where the switch statement is (like in a step event vs a draw event)?

the player in my game has a complex set animations/states and gear you can see, and i use a switch statement to control which gear/weapons are drawn, and its organized and works very nice, but how far can i push the switch statement in terms of number of cases? is 50 too many for example?

if having a high number of cases is something that is limited, would having each piece of gear you can see be its own object and ill just create instances of those, be a good idea or better alternative? what is another way i can control a such a complex set animations/states and gear you can see?

thanks!

 

[dj_midknight]

Switches are awesome. So long as your code is still readable and manageable your doing alright. Im not sure what the limit of GMS is for switch limits but I have worked on programs in other languages with thousands of case statements. At that point it is unweildy but still functional.

It might be better to have each weapon and each equip be its own object though. This also allows you to make an unlimited number of combinations without having to hard code each and every one. The decision on stuff like this comes down to what is more flexible and what suits your needs. EX. if you have a single character with 1-3 armor sets and 1-2 different weapons it might just be worth it to bundle everything into a single switch with no system to automate this all. However if you plan to have a vast amount of different options for both armor and weapons its definitely worth the extra effort to make the system generic and create separate objects for each of these items.

 

[Yal]

I'm not sure how switch cases are implemented... if they're implemented as sequential comparison branches (which sounds reasonable), you'll get O(n) complexity, while assigning a script to a variable and executing it directly has the same overhead every time (which is pretty substantial and proportional to the data in the arguments). There probably is a breakoff point where script_execute() is more efficient. I personally use it all the time anyway because of how it keeps the code clean and separated, though. Switch cases gets unwieldy somewhere past 1-2 screens of code.

 

[anthropus]

I'm not sure how switch cases are implemented... if they're implemented as sequential comparison branches (which sounds reasonable), you'll get O(n) complexity, while assigning a script to a variable and executing it directly has the same overhead every time (which is pretty substantial and proportional to the data in the arguments). There probably is a breakoff point where script_execute() is more efficient. I personally use it all the time anyway because of how it keeps the code clean and separated, though. Switch cases gets unwieldy somewhere past 1-2 screens of code.

Yal, for a game where the main character has a complex set of animations with multiple layers of gear (minimum of helmet, shield, weapon, clothes, boots, +2 accessories) you can see, would you recommend I handle it all with a draw event drawing all the sprites in a large switch statement, or make each piece of gear be its own object as @dj_midknight suggested? i seek your wisdom. thanks

 

[Yal]

Yal, for a game where the main character has a complex set of animations with multiple layers of gear (minimum of helmet, shield, weapon, clothes, boots, +2 accessories) you can see, would you recommend I handle it all with a draw event drawing all the sprites in a large switch statement, or make each piece of gear be its own object as @dj_midknight suggested? i seek your wisdom. thanks

I'd recommend assigning sprites to an array (one slot for skin, one slot for armor, one slot for boots and so on) and then just loop through that drawing each piece in order (and have a special value for 'no sprite' for cases when the player has nothing in that slot).

 

[TheouAegis]

Switches cooooulllllld be compiled as lookup tables, but considering GM is meant to be flexible, odds are switches are nothing more than cascading conditionals:

LDA exp
CMP a
BNE 3
CMP b
BNE 3
CMP c
BNE 3
CMP d
BNE 3

And so the more cases you add, the slower it gets for the latter cases. In other words, if you had 100 cases, then the code would be slower the closer to 100 the value of the expression gets.

Building an array or set of arrays will take up more RAM, but the speed of execution will be uniform across all "cases".


The main complaint I saw about switches was they're easy to bug out due to typos or oversight. In the case of a programming language that allows you to embed LUAs into the code itself, switches are inferior. Since GM does not allow you to embed LUAs, switches are about on par with using arrays or script_execute().

Me personally, I alternate between arrays and switches.