creatures caves welcome, guest
downloads   gallery   dev   community   creatchi   forum   mycaves
hack shack | script reservations | dev resources | dev forum

  

Nested DOIF?  on 4/13/2014

Hello,
     Have you ever used nested DOIFs? (DOIFs inside DOIFs) When would you recommend using them? Do you have any tips on how to work with nested DOIFs effectively?
- Malkin


Dear Malkin,
     I use nested conditions all the time: in CAOS, in PHP, Javascript, and ColdFusion (which is, interestingly, more similar to CAOS in some ways than it is to other web-related languages). The correct answer is: whenever it seems more efficient to do so. In general, which method you use isn't a matter of optimization, but basic logic that depends entirely on the circumstances: your script won't do what you want it to if you use the wrong method.

But there are definitely some times when it's better to nest them, and some times when it isn't. The most common alternative to nesting conditions is to link them, like this:

DOIF condition 1
(do something)
ELIF condition 2
(do something)
ELIF condition 3
(do something)
ELSE
(do something)
ENDI


It's all essentially one "block" of conditions. If the first condition isn't true, it will automatically try the second, then if that isn't true it will try the third, etc.

Nesting conditions, as you know, looks like this:

DOIF condition 1
(do something)
ELSE
DOIF condition 2
(do something)
ELIF condition 3
(do something)
ELSE
(do something)
ENDI
ENDI




There are a few ways in which humans use conditions that computers don't, and this "language bias" is the most counterproductive when using conditions, because our experience speaking English (or German, or Chinese) influences how we expect CAOS to work. For instance, I see a lot of new programmers write stuff like this:

DOIF the sky is blue
(do something)
ELIF the grass is green
(do something)
ELSE
(do something)
ENDI


Because we all think the same way and make the same initial assumptions when learning to code, you'll see people do this kind of thing in any programming language that uses conditions. The problem is that computers--regardless of what language you're using to communicate with them--don't like subject changes in the middle of condition blocks. Since the first DOIF is referring to the sky, the game expects that the next condition in the block will also relate to the sky. Even though the basic structure looks correct to the human eye, the code above won't work consistently because it relies on forcing the game to "think" in a way it wasn't designed to. This is the kind of situation in which we need to use nested conditions. The code above becomes much more stable and reliable when we "phrase" it properly:

DOIF the sky is blue
(the sky is blue, so do something)
ELSE
DOIF the grass is green
(the sky is not blue BUT the grass is green, so do something)
ELSE
(the sky is not blue AND the grass is not green, so do something)
ENDI
ENDI


Now the game will know for sure that we only care about the color of the grass if the sky is blue. If we want to check the color of the grass and take different actions depending on both the sky and grass color, we can duplicate the grass-related condition block like this:

DOIF the sky is blue
DOIF the grass is green
(the sky is blue AND the grass is green, so do something)
ELSE
(the sky is blue BUT the grass is not green, so do something)
ENDI
ELSE
DOIF the grass is green
(the sky is not blue BUT the grass is green, so do something)
ELSE
(the sky is not blue AND the grass is not green, so do something)
ENDI
ENDI


Or we can use variables to "tally up" the results of our conditions, like this:

DOIF the sky is blue
SETV VA00 1
ELSE
SETV VA00 2
ENDI

DOIF the grass is green
ADDV VA00 10
ELSE
ADDV VA00 20
ENDI

DOIF VA00 EQ 11
(the sky is blue and the grass is green)
ELIF VA00 EQ 12
(the sky is blue but the grass is not green)
ELIF VA00 EQ 21
(the sky is not blue but the grass is green)
ELIF VA00 EQ 22
(the sky is not blue and the grass is not green)
ENDI


Which one you use depends entirely on the situation: if you're only combining two conditions, the first method is certainly more straightforward at a glance. But if you're combining more than two conditions (perhaps you want to check if the sky is blue, if the grass is green, and if there's a mild breeze) that method will double in complexity with each condition added, which can get messy very quickly. The second method has an advantage in that situation, because the final condition retains the same structure no matter how many conditions are involved.

It also makes it easier to use the same action for different conditions, because you can do fun stuff like this:

DOIF VA00 EQ 11
(the sky is blue and the grass is green)
ELIF VA00 EQ 12 OR VA00 EQ 22
(the sky is blue but the grass is not green, OR the sky is not blue and the grass is not green)
ELIF VA00 EQ 21
(the sky is not blue but the grass is green)
ENDI



There's a lot that could be said about conditions and how to use them, but any method depends on what works best for your agent and what makes the most sense to you. I think that's why I find conditions one of the most fun and interesting aspects of coding.
- Ghosthande
 
 
Malkin | 4/14/2014  log in to like post

Wow, thanks for the detailled explanation! :D I'll have to let this sink in a bit and give it a go! :)


downloads
cobs
adoptions
creaturelink
metarooms
breeds
 
gallery
art
wallpaper
screenshots
graphics
promos
sprites
dev
hack shack
script reservations
dev resources
active projects
dev forum
 
community
links
advice
chat
polls
resources
creatchi
 
forum
bookmarks
general
news
help
development
strangeo
survivor
mycaves
log in
register
lost pw
1 online
Papriko
creatures caves is your #1 resource for the creatures artificial life game series: creatures, creatures 2, creatures 3, docking station, and the upcoming creatures family.

contact    help    privacy policy    terms & conditions    rules    donate    wiki