Sometimes when I'm doing something like platformer enemy AI I find myself using events like:
(This is just a representative version of the real thing, since I don't have access to MMF from my current location and wan't to make things as clear as possible.
What I'm saying is that the point of this is NOT to showcase any type of engine, so don't put too much energy into understanding what is going on.)
- If alterable value "falling" = 0 (checks whether enemy is in the air or not)
+ If alterable value "chasing" = 1 (checks whether enemy is chasing the player)
+ If alterable value "pit warning" = 1 (checks whether enemy is coming to the edge of a platform)
+ If alterable value "jump detector" = 1 (checks whether he can make the jump to the next platform as the player did while running away)
--- Set alterable value "jump" to 1 (makes enemy jump)
--- Set alterable value "pit warning" to 0
--- Set alterable value "jump detector" to 0
- If alterable value "jump" = 1
+ If alterable value "chasing" = 1
Only one event when event loops
--- (Make enemy jump over the pit whatever way you intend to)
--- Set alterable value "jump" to 0
- If alterable value "falling" = 0
+ If alterable value "chasing" = 1
+ If alterable value "pit warning" = 1
+ If alterable value "jump detector" = 0
--- Set alterable value "turn around" to 1 (makes enemy turn around, 1 is right and -1 is left)
--- Set alterable value "chasing" to 0 (makes the enemy stop chasing the player)
This is just the start of coding sophisticated enemy AI (as you all probably know) but it's already pretty complicated, and when something goes wrong it can be hard to know what exactly it is that's causing it. So when I'm feeling lazy and don't want to start thinking too much about it, what I do is insert a short "bleep" sound into one of the events. For example, let's say the enemy doesn't follow the player over the pit. Just do this:
- If alterable value "jump" = 1
+ If alterable value "chasing" = 1
Only one event when event loops
--- (Make enemy jump over the pit whatever way you intend to)
--- Set alterable value "jump" to 0
--- play sound "bleep"
Now, if you still hear the bleep sound but the enemy doesn't jump, you know that the problem is most likely in his movement engine...
To me this is a really fast, easy... and dare I say, "fun" ... way of doublechecking things. I hope this can be of some help to some of you as well.
- Superpower out
Edited by superpower
n/a
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
10th June, 2010 at 10:15:45 -
I do something very similiar to that, except instead of a sound I have the application end, or the object destroyed I debug it like that, element by element.
I also sometimes use "end application" if I don't have any sounds already loaded... Man, I just realized how lazy that sounds But I find using sounds helpful since you can assign different sounds to different events and keep debuggin.
I find my main problems come in when I did math wrong, so I usually just debug with counters that are equal to basically everything's alterable value. Then if something goes wrong, I look to see what numbers are wrong during gameplay, then go back and find my error in math.
I'm planning to write a big article on this later, after exams
What I do is I make a group called Debugging. I'd disable that group when I release the game, or when the game is stable, but till then I activate it.
Then I'd put the following:
- On loop "error"
--- play sound "bleep"
--- (other actions popping up a dialog box, etc)
Then when something is not working like you'd want it, you just put in the action "Run loop "error" 1 times"
Bonus of doing it this way is that you can leave the error checking events in, but disable the effects easily, without worrying that it'd affect the game later on. If you're feeling fancy, do like a proper error checker. E.g.
- (a bunch of conditions saying that jump doesn't work)
--- Change Alterable String A to "Jump doesn't work"
--- Run loop "error" 1 times
- (Conditions saying enemy has -20 lives but still isn't destroyed)
--- Change Alterable String A to '"Enemy not destroyed, HP " + Str$(lives)'
--- Run loop "error" 1 times
- On loop "error"
--- Display dialog box
--- Dialog box text set to Alterable String A
Takes a few minutes of extra work, but could save you a few hours on debugging.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
I find my main problems come in when I did math wrong, so I usually just debug with counters that are equal to basically everything's alterable value. Then if something goes wrong, I look to see what numbers are wrong during gameplay, then go back and find my error in math.
Yes, to me this has proven to be a very solid way of debugging when combined with counters.
Advertisement
Post Reply
... way of doublechecking things. I hope this can be of some help to some of you as well. 
Edited by superpower
