Regarding the performances, there are different ways to answer you.
1. Anonymous function are not faster than stand-alone functions. They provide the exact same results (well, I guess there is a marginal benefit since some variables are in a closer scope than they would be with a stand-alone function using file-scoped locals but it's negligible).
2. LUA is a weakly typed language, so it's slow as hell. But slow as hell on our modern, very fast CPU, is still very good. With a strongly typed language, I start to slightly worry when some simple function like yours is called more than 100k times per frame (one frame = 15ms = 20M language-level operations). Even if lua is slow, your function will take far less than one micro-second. And since the AI probably never moves more than 1k units per second, you will be below 0.1% of CPU time.
3. There is a thing called "premature optimization" and it is usually followed by "is the root of all evil". Programmers do not know what's going to be slow, programmers do not know what they need to optimize, programmers need to rely on measures. Optimizations must be usually done either at the prototyping stage (to ensure your idea is achievable or because you could have to choose specific architectures based on performances) or at the later ones (polishing the product). Focus on code quality, not on performances. Especially, most beginners tend to optimize things that do not need to be optimized ("how proud I am of this neat optimization that saves 1ms per year and totally wasted my code, made it unmaintainable, unextendable and unreadable, required me three days of development and introduced ten bugs in something that used to work fine"). Some of those young programmers seem to have an optimization compulsive disorder: anytime they see a perfectly fine code that could be made faster, they do it. Then project managers come and reject all those submissions for the sake of the project. Maybe it's faster but if it's negligible or irrelevant (there was no problem), then even a single additional line of code is too much of a price. We probably all went through that stage ; the earlier we quit it, the better.
4. That being said, it's not a reason to do things dirty. Besides code quality also means that you must do things at the moment one expect them to be. Why would you check the colonist's location on every move if you only need this information when the player founds a city? Choose the elegant way, as always: put that code in the proper event where it is supposed to be.
1. Anonymous function are not faster than stand-alone functions. They provide the exact same results (well, I guess there is a marginal benefit since some variables are in a closer scope than they would be with a stand-alone function using file-scoped locals but it's negligible).
2. LUA is a weakly typed language, so it's slow as hell. But slow as hell on our modern, very fast CPU, is still very good. With a strongly typed language, I start to slightly worry when some simple function like yours is called more than 100k times per frame (one frame = 15ms = 20M language-level operations). Even if lua is slow, your function will take far less than one micro-second. And since the AI probably never moves more than 1k units per second, you will be below 0.1% of CPU time.
3. There is a thing called "premature optimization" and it is usually followed by "is the root of all evil". Programmers do not know what's going to be slow, programmers do not know what they need to optimize, programmers need to rely on measures. Optimizations must be usually done either at the prototyping stage (to ensure your idea is achievable or because you could have to choose specific architectures based on performances) or at the later ones (polishing the product). Focus on code quality, not on performances. Especially, most beginners tend to optimize things that do not need to be optimized ("how proud I am of this neat optimization that saves 1ms per year and totally wasted my code, made it unmaintainable, unextendable and unreadable, required me three days of development and introduced ten bugs in something that used to work fine"). Some of those young programmers seem to have an optimization compulsive disorder: anytime they see a perfectly fine code that could be made faster, they do it. Then project managers come and reject all those submissions for the sake of the project. Maybe it's faster but if it's negligible or irrelevant (there was no problem), then even a single additional line of code is too much of a price. We probably all went through that stage ; the earlier we quit it, the better.
4. That being said, it's not a reason to do things dirty. Besides code quality also means that you must do things at the moment one expect them to be. Why would you check the colonist's location on every move if you only need this information when the player founds a city? Choose the elegant way, as always: put that code in the proper event where it is supposed to be.