This isn't specifically Construct-related, but since I'm using Construct to learn programming and only truly understand it through Construct's interface, I felt that this is an appropriate enough place to ask. Please bear with me if I use some odd or unconventional terms; I have no formal programming education, so I'm improvising a lot of this as I go. Hopefully, it's intuitive enough that you'll understand the gist of it. If not, please ask and I will gladly clarify.
I'm programming a somewhat complex RPG engine that relies on a lot of conditions, sometimes 3 or 4 layers deep. For the initial version of the engine, which can be found here [url:adbcg1l5]http://www.scirra.com/forum/viewtopic.php?f=4&t=8405&p=64076#p64076[/url:adbcg1l5], I used what I call a 'disable-controlled' coding method. Instead of programming it so that certain actions were restricted under certain conditions, I left the actions alone and simply disabled the buttons that controlled those actions. So a typical chunk of code looked like this:
>On Player.Value('Reserve') equal to 0: disable button 'Attack'
>On global('Distance') greater than 1: disable button 'Attack'
>On button 'Attack' clicked..set Player animation to "Attack"
.................................subtract 1 from Player.Value('Reserve')
This worked fine until I switched from buttons to keys for faster, more intuitive command inputs. Since I couldn't disable individual keys, I had to restrict individual attacks. I had to reorganize the code into what I termed a 'stack-controlled' coding method. Here, the input methods were not disabled; instead, the commands themselves would only work under certain conditions. The same chunk of code above looked like this:
>On Player.Value('Reserve') greater than 0
>>On global('Distance') less than 2
>>>On key A pressed..set Player animation to "Attack"
..........................subtract 1 from Player.Value('Reserve')
At face value, this felt cleaner and more organized, but the sheer number of conditions made it unmanageable. All in all, the conditions were: Player.Value('Reserve') greater than 0, global('Distance') less than 2, global('Turn') equal to "Player 1", and Player.Value('Action') equal to _(1-4). This does not include special attacks, with effects such as staggering the opponent, which had to trigger a dice roll to determine success. It was an inefficient mess. Each extra condition exponentially increased the size of the stack, since it had to be added to every existing condition, rather than having its own section, as with the 'disable-controlled' coding method. The sheer scale quickly exceeded my practical capabilities. I am currently trying to minimize the amount of 'stacking' necessary by implementing a hybrid disable/stack coding method I have dubbed 'variable-controlled'. I'm doing so by allocating as many conditions as possible to variables that function like on/off switches, so that less conditions have to be programmed into the stack. The above code looks like this:
>On Player.Value('Reserve') equal to 0: set global('Attack Monitor') to "NEGATIVE"
>On global('Distance') greater than 1: set global('Attack Monitor') to "NEGATIVE"
>On global('Attack Monitor') equal to "POSITIVE"
>>On key A pressed..set Player animation to "Attack"
.........................subtract 1 from Player.Value('Reserve')
I'm just starting to pick apart the massive redundant stacks and convert as many of the conditions into on/off variables as possible. I'm not sure how much I can salvage; I might be better off rebuilding the system from scratch. My goal is to build a system that allows for fast, uncluttered customization. For that reason, the stack has to be minimized, or adding even single conditions will take cripplingly long. My question is this: how could I further streamline my system toward this purpose?