Hi! I wrote this little cheat code function and decided to share it here if anyone wants to put cheat codes on their games, here's how it works:

paste all code labeled as requiered onto your cart, this includes:

• chsys={}
• all code on the _update function
• the add_chsys function

then, to call a cheat code, write it down on a table like this:
konami_code={⬆️,⬆️,⬇️,⬇️,⬅️,➡️,⬅️,➡️}

and then call the add_chsys function once (if you call it on an update function/every frame you'll chug the system):
add_chsys(name_of_your_cheatcode_table,function_to_load_if_it_succeeds)

So for example if I wanted to make the game stop when the Konami code was detected then I'd put this on my _init function (or any function that only acts once):
add_chsys(konami_code,stop)

Hope ya enjoy!

cheat codes function system

I too have recently tinkered with some cheat code detection of my own, so I quickly noticed a couple of shortcomings with this.

It abandons all prior input on failure to match nth input, even though a different, shorter matching may be possible. It's easier to explain by example: Konami code expects UUDDLRLR. UUUDDLRLR and UUUUDDLRLR will fail because when the bolded 'U' is reached, everything up to and including it gets discarded. Whereas discarding only excess 'U's from the front would make it possible to continue matching.

Also, there is a glaring lack of O/X buttons as stand-ins for A/B in the Konami code. To safely support O/X buttons in cheat codes, some additional machinery would be needed to deconflict cheat code entry vs normal behavior of O/X buttons. For example, we might want to permit cheat code entry while on the title screen or in some menu. In such contexts, dpad is typically used for navigation (game modes, menu options, character select, etc) so it is generally harmless if some cursor moves around while a cheat code is being input. However, O/X buttons may be mapped to functionality like select/start/cancel/return and it could be problematic if pressing O/X somewhere in the middle of a cheat code has the side effect of triggering their normal behavior e.g. staring the game prematurely, etc. The standard button behavior will need to be suppressed if (and only if) the button press is contributing to a potentially correct cheat code.

Other lesser considerations include:

• cheat code still accepted if paused and unpaused in the middle of entering it
• rare corner cases due to more than one simultaneous btnp

A more robust implementation that handles stuff like that would come with substantially increased token cost, though, so it ultimately boils down to a trade off.