A programmer's philosophical question.

#1 @admin, please if you can, move this to general discussion.

#2 Well, using your example of live and die, generally you would make the assumption that the character would be alive as that is the state they'll be in the majority of the time. This means that you only have to check for the death condition to be met. There are ways the code be written to have a positive connotation like your live example, but it would probably get a little convoluted.

The live example actually gets more into while loop territory, which can be a dangerous conditional when not used properly. So the reasoning is kind of a one part optimization and one part readability thing.

#3 Nice, thanks.





Nice guns by the way.


:]...||k

#4 If I remember right back in the day when i could remember this sort of thing... A programmer designs a program to achieve a result.
The result is an expectation such as a correct number.
We know what the number is.. we did it by paper and pencil.
Programs are supposed to do the Paper and Pencil for us, So,
if{
MyExpectation(%this) != correctValue;
{
Then
{
I need to go back to school;
}
else{
GladThisProgramDoesThisForMe;
};

I know this isn't proper syntax, but hey.. Thats why we make programs..
To get correct results.. in this case, I need a program to read my mind and spit out the right answers :-)

#5 Because you can only have opposite variables, not opposite functions, otherwise you would need to do twice the programming. And considering your live function would need to be looped, it would also put more pressure on the computer, even if you use onUpdate();

#6 Any time you deal with a binary search tree, I've been told it's more efficient to trim off unlikely results as soon as possible. Every time you run a query or perform game logic, you eliminate impossibilities and erroneous data early to make the function faster simply by design.

In your example, most things live, so trim them out early to make your function faster. Conversely, if your game was one where keeping track of dead targets was more likely than living ones, or if more game logic dealt with dead things than living things, you'd test for living things instead (Sim Cemetery!)

Also, in most game logic, "live" means do nothing, and testing a condition for which the result will be "do nothing" is a waste of processor cycles.

Also, in English terms, using NOT (!) in a boolean comparison structures your statements to get more specific with more tests, versus more vague. It makes the code easier to read, while at the same time more efficient.

It's like telling a story. Don't you hate it when someone forgets a detail and they bring it up later and you're just confused as to why they even told you about it? Maybe the detail was important and needed to be told, but you'd rather it be told to you in order of importance.

You could test a hundred attributes, but at the end if the last test is "is it a dog?" you wasted a lot of time testing a non dog.

#7

Quote:Why is it, and please correct me if I am wrong, but why is it that most if statements made (inside the if) is a negative?

Sometimes you're interested in the case where something is NOT something else. It's not always a case of live versus die, which are two clear opposites - you might only have one function you want to call in specific situations. So instead of having to say

if(this == that)
{
}
else
{
doMyCoolThing();
}

You just write

if(this != that)
doMyCoolThing();

#8 right.

thanks guys!