Quote:
You could always standardise a replacement for destroy command. Using a class containing, for example, this:
function destroyNPC(){
//update index list
destroy;
}
|
When you say class you mean npc?
Just making sure, I am not aware of classes in graalscript (but that would be nice).
Quote:
|
Why do you need to be able to refer back to the NPC?
|
Well, I may just be using styles of the programming languages I know and mis-fiting them into graalscript.
One way to speed up collision detection, for example is for non-mobiles, say trees, to have references to each tree placed inside a quandrant variable (like a 2d array), and any tree can be right on the cross-hairs and be in up to 4 quads at once.
then you break the land down into about say, 20 by 20 of these, so 400 quads.
I can use math to say player[0] is at x,y such and such, thus in quad 10,5 say. Then, if he swings an axe, I can test collisions with only trees in the quad 10,5.
A memory address of this type of array would roughly be similar to that of a 20 x 20 true color/alpha image, but would reduce the amount of detections at runtime by quite a bit.
Also, for ship collisions, it can be nice to allow ship A to upon detecting the collision, take the NPC of ship B's x and y, npc[].vars, and also take the ship's basic stats, such as loaded wgt, total size, speed, armor, etc, to determine the resulting damage.
In short, I want to mix npc[] data with freely accessible data for that npc that cannot be stored within that structure, and say since I have npc[6], I know I can find it's associated data stored at .....somewhere.
since in npc[i], i can change if a previous npc gets deleted, I can't use arrays, and depend on moreData[i] relates still to npcs[i].
I am sure it's solved somehow, I just don't know the right approach yet.