just want to make sure there is no tricks in ensuring basic movement is as efficient as possible. As that will be the main thin players will be doing
Aug 16 2015, 1:41 pm
|
|
FKI
 |
Don't bloat the Move proc with uselessness; do things when you need to and it shouldn't be much of a problem.
|
It's a lot harder to answer this kind of question than it is to point out things you are already doing that could be done better.
| |
My move is like this currently
Verb/North() Src.move(bla,bla...) Than I have verbs for other directions | |
I assume you're just using default tile-based movement. If that's the case, the only code I would include in the Move() function would be to clean up the jittery movement. Other than that, if you need to do anything super complex, I suggest spawn()ing a new thread so it doesn't stop up Move(). I'd only do that in situations where you really needed it though. Creating a lot of fat, resource intensive threads can destroy you. (I mean resource intensive as in the code inside the thread. Threads themselves aren't resource intensive.)
| |
That post was only slightly less uninformative.
| |
spawn()ing a new thread Those two words should not be used together. Spawn() doesn't create a new thread. Further, Move() is waitfor=0, it can't be stopped. If you try to sleep() in a move, it will return whatever value is in ".". | |
Ter13 wrote:
spawn()ing a new thread Does it not? Hmm. I was always under the impression that it used threading to handle spawn() calls. I guess it just simulates a thread, then? | |