I haven't much to add to this, but here is a small suggestion.
GML:
target = noone;
if instance_exists (obj_ballestas)
{target = instance_nearest (x, y, obj_ballestas)}
if target != noone
{
target_x = target.x;
target_y = target.y;
dist = distance_to_point (target_x, target_y);
if dist <200 and target.state != "active"
{
hspeed = sing (target_x -x)*1
vspeed = sing (target_y-y) *1
}
if dist < 5
{
hspeed = 0; vspeed = 0
}
}
1) I'm not 100% sure of one these changes, which is to define 'target' as a null value beforehand.
In GMS 1 if you were trying to access 'target', and it had no value because no instance was found, it would throw an error. As you have it coded: it will only check for the nearest instance of "obj_ballestas" if there is an instance currently existing.
Your code after that isn't based on this same condition, and could be looking for 'target' even when there is nothing to possibly give it a value. I'd imagine you haven't seen this happen due to there being an instance of "obj_ballestas" in the room you are currently working on. Remove it from the room, and I believe you will see your other object (as it is now) cause an error.
2) This change is about how often you call to distance_to_point, and giving you some measure of what this involves.
Code:
distance_to_point (target.x, target.y)
You call this function twice, but it also means calling 3 further things: what is 'target', what is 'target' x, what is 'target' y. It is inevitable that 'target' will be a cost, as it must look up that value twice to find target.x and target.y. Once you have those x and y values, if you need them later you should store them.
When they're stored think of it as it looking inside itself, when they're not stored: it has to make that extra effort in looking outside of itself
Code:
hspeed = sing (target.x -x)*1
vspeed = sing (target.y-y) *1
Above, you again end up calling what is 'target', what is 'target' x, what is 'target' y.
Siempre que desee recuperar un valor más de una vez en el mismo paso y esté accediendo "fuera" de la instancia actual, es mejor almacenar ese valor.
[CÓDIGO] target_x = target.x;
target_y = target.y;
dist = distancia_al_punto (objetivo_x, objetivo_y);
hspeed = sing (target_x -x) * 1
vspeed = sing (target_y-y) * 1 [/ CODE]
El costo de buscar las variables almacenadas será menor que las 6 veces que llamas a los objetivos xey, y las 2 veces que usas distance_to_point. Probablemente no sea mucho menos por sà solo, pero no olvide que este costo aumenta con cada instancia que tiene al realizar esta verificación ... y por qué fomentar el despilfarro de todos modos.
Quién sabe: un dÃa puede que te preguntes qué puedes hacer para optimizar tu juego, y pequeñas cosas como esta podrÃan pasar desapercibidas. Todos se suman
Espero que ayude.
[/CITA]
Muchas gracias por la ayuda lo que buscaba conseguir era 1. Las torres tienen máquina de estado (construida, desactivada, activada) cuando aparecen enemigos los minions que buscan las torres y cuando están cerca de ellas se van a activar modo y luego comenzar a atacar a los enemigos.
I have already managed to do it but I still have a question, but this time is with the gui version 1.4 as I can print on screen the state machine of the same object without overlapping each other and do not repeat the same let's say I want to show what profession has each (state machine) example lumberjack, farmer, miner etc. ... is there any way?