<!--quoteo(post=1934374:date=May 8 2012, 02:24 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ May 8 2012, 02:24 AM) <a href="index.php?act=findpost&pid=1934374"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Early game it seems movement related code is a big factor, anyone can confirm ?
There is not much algorithmic about the movement code though, it's mainly a bunch of linear vectorial math.
<b>Something I wonder. There is a lot of function like self:GetSomething() that just return self.something or so. Is this slower than defining a local variable instead? Javascript has some of those kind :</b>
It also helps monitor field accesses for debugging.
Say we have a class Skulk that has a self.speed = 4. If we can modify it directly with skulk.speed, then we could accidentally be setting it to 0 somewhere and forgetting about it. To find this mistake would be difficult if we are not using this principle. However, if every access of speed is through Skulk:GetSpeed() and Skulk:SetSpeed() then all we need to do is look at who is calling the function. We put a breakpoint or a print statement in the function and we know exactly why and when the value is changing.
It also allows us to put error checking in the function so that the value isn't accidentally set to a negative number. If we did not have getters and setters, then we would have to write the error checking code every time we modified speed. One principle of modern programming is to never re-write code because it adds work and introduces more places for mistakes.
remiremedy [blu.knight]Join Date: 2003-11-18Member: 23112Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester
edited May 2012
<!--quoteo(post=1936033:date=May 13 2012, 03:27 PM:name=menohack)--><div class='quotetop'>QUOTE (menohack @ May 13 2012, 03:27 PM) <a href="index.php?act=findpost&pid=1936033"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->It also helps monitor field accesses for debugging.
Say we have a class Skulk that has a self.speed = 4. If we can modify it directly with skulk.speed, then we could accidentally be setting it to 0 somewhere and forgetting about it. To find this mistake would be difficult if we are not using this principle. However, if every access of speed is through Skulk:GetSpeed() and Skulk:SetSpeed() then all we need to do is look at who is calling the function. We put a breakpoint or a print statement in the function and we know exactly why and when the value is changing.<!--QuoteEnd--></div><!--QuoteEEnd--> In C++ land at least, this is a non-issue. It definitely makes it easier, but you can just set memory breakpoint just as easily. The other advantage you do get though is that in C++ things could be accessed with self.speed, skulk.speed, sk.speed, sk->speed, alien->speed, etc... a "find in files" would have a hard time identifying all the spots it's getting set (even with Visual Assist). It's far easier to keep track of this all when you have a function accessor (though good standards could also make an accessor uneccessary for this case).
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->It also allows us to put error checking in the function so that the value isn't accidentally set to a negative number. If we did not have getters and setters, then we would have to write the error checking code every time we modified speed. One principle of modern programming is to never re-write code because it adds work and introduces more places for mistakes.<!--QuoteEnd--></div><!--QuoteEEnd--> This is a great benefit, and even moreso it allows you to do this after the fact. To change which field it's using you only need to change one spot, not 50. To add bullet proofing, same deal. Definitely helps with maintainability and scoping (preventing what I mentioned above).
Comments
There is not much algorithmic about the movement code though, it's mainly a bunch of linear vectorial math.
<b>Something I wonder. There is a lot of function like self:GetSomething() that just return self.something or so. Is this slower than defining a local variable instead? Javascript has some of those kind :</b>
<a href="http://james.padolsey.com/javascript/zakas-javascript-performance-tips/" target="_blank">http://james.padolsey.com/javascript/zakas...rformance-tips/</a><!--QuoteEnd--></div><!--QuoteEEnd-->
<a href="http://en.wikipedia.org/wiki/Law_of_Demeter" target="_blank">http://en.wikipedia.org/wiki/Law_of_Demeter</a>
Say we have a class Skulk that has a self.speed = 4. If we can modify it directly with skulk.speed, then we could accidentally be setting it to 0 somewhere and forgetting about it. To find this mistake would be difficult if we are not using this principle. However, if every access of speed is through Skulk:GetSpeed() and Skulk:SetSpeed() then all we need to do is look at who is calling the function. We put a breakpoint or a print statement in the function and we know exactly why and when the value is changing.
It also allows us to put error checking in the function so that the value isn't accidentally set to a negative number. If we did not have getters and setters, then we would have to write the error checking code every time we modified speed. One principle of modern programming is to never re-write code because it adds work and introduces more places for mistakes.
Say we have a class Skulk that has a self.speed = 4. If we can modify it directly with skulk.speed, then we could accidentally be setting it to 0 somewhere and forgetting about it. To find this mistake would be difficult if we are not using this principle. However, if every access of speed is through Skulk:GetSpeed() and Skulk:SetSpeed() then all we need to do is look at who is calling the function. We put a breakpoint or a print statement in the function and we know exactly why and when the value is changing.<!--QuoteEnd--></div><!--QuoteEEnd-->
In C++ land at least, this is a non-issue. It definitely makes it easier, but you can just set memory breakpoint just as easily. The other advantage you do get though is that in C++ things could be accessed with self.speed, skulk.speed, sk.speed, sk->speed, alien->speed, etc... a "find in files" would have a hard time identifying all the spots it's getting set (even with Visual Assist). It's far easier to keep track of this all when you have a function accessor (though good standards could also make an accessor uneccessary for this case).
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->It also allows us to put error checking in the function so that the value isn't accidentally set to a negative number. If we did not have getters and setters, then we would have to write the error checking code every time we modified speed. One principle of modern programming is to never re-write code because it adds work and introduces more places for mistakes.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is a great benefit, and even moreso it allows you to do this after the fact. To change which field it's using you only need to change one spot, not 50. To add bullet proofing, same deal. Definitely helps with maintainability and scoping (preventing what I mentioned above).