Is it possible to access tagged actors attribute from a seperate actor.

Icebox

I wanted to know if its possible in gs or in coding in general , to control attributes of all actors that are tagged.

so just a general example of what i mean.. if i had 100 actors on screen , and i wanted to constrain their x velocity to 100 , instead of having 100 actors with 100 constrain behaviors , have a seperate actor with one rule , if actor tag contains xx constrain tagxx.motionVelocityx to 100 so it will affect all actors that are tagged without having 100 constrain behaviors running at the same time. Would this be possible in coding? or is there an alternative way to do it?

The_Gamesalad_Guru

Sure you could do this with looking at two game level variables.

So two variables
Integer game.tag.velocity
Text game.tag

Rule (all)

If game.tag is self.tag

Then

Change self.motion.linearvelocityx to game.tag.velocity

Icebox

@Lost_Oasis_Games said:
Sure you could do this with looking at two game level variables.

So two variables
Integer game.tag.velocity
Text game.tag

Rule (all)

If game.tag is self.tag

Then

Change self.motion.linearvelocityx to game.tag.velocity

with this example if i place 100 actors on screen each actor would have this rule in it right ?

The_Gamesalad_Guru

@Icebox said:

@Lost_Oasis_Games said:
Sure you could do this with looking at two game level variables.

So two variables
Integer game.tag.velocity
Text game.tag

Rule (all)

If game.tag is self.tag

Then

Change self.motion.linearvelocityx to game.tag.velocity

with this example if i place 100 actors on screen each actor would have this rule in it right ?

Yep. Then just modify the values in those attributers from a manager. so one set of code in a manager controls when the velocity changes and when. With that you could control a ton of different tags from just those two attributes.

Icebox

For example in my game i have coin actor and i have this one constrain behavior in it

In the coin actor i have a constrain behavior that constrains its y position to 10sin(self.time100)+self.firstpositiony to give it a looping effect of going up and down

and i have 100 coins on screen , which means 100 constrains are running and updating.

So instead i want to have one constrain that applies to all the coin actors on screen. cause the more constrains i have in my game the more it becomes heavy and slow.

What i want to know is if there is a way to do this. So I asked it in general if its possible I think i confused you with that sorry

The_Gamesalad_Guru

@Icebox said:
For example in my game i have coin actor and i have this one constrain behavior in it

In the coin actor i have a constrain behavior that constrains its y position to 10sin(self.time100)+self.firstpositiony to give it a looping effect of going up and down

and i have 100 coins on screen , which means 100 constrains are running and updating.

So instead i want to have one constrain that applies to all the coin actors on screen. cause the more constrains i have in my game the more it becomes heavy and slow.

What i want to know is if there is a way to do this. So I asked it in general if its possible I think i confused you with that sorry

What you could do is create a proximity sensor that when the player get closer to the coin, I assume this is a long scrolling scene, then the coin starts the movement. So toggle on and off the constrain.

Icebox

@Lost_Oasis_Games Yes this is exactly what i did if maginute(game.playerx-self.positionx, game.playery-self.positiony) is less than 600 then constrain , but it still plays slow on the device , but much better than all of them triggering the same time. So im sure its this that is causing me pain with performance cause when i turn it off the game plays well. I sent the project to GS team to look into it but i wanted to make sure if there are other ways to get around it.

Edit : and thats when I thought if it was possible to constrain with tag so i can only have one constrain to all those actors

Adrenaline

Is it simply because it's a 'constrain' behavior that it's causing you issues? Or is it the movement in general?

If it's just because it's a 'constrain', then in your case you could easily replace all the constrains with 'interpolate' or 'move to'. It's just a coin going up and down, after all.

I don't know if 'interpolate's or 'move to's are easier on performance or not...

Socks

@Icebox said:
Yes this is exactly what i did if maginute(game.playerx-self.positionx, game.playery-self.positiony) is less than 600 then constrain , but it still plays slow on the device , but much better than all of them triggering the same time.

I'm not so sure the magnitude calculation is any less work for a processor than 10* sin(self.time *100) . . . ? They are, after all, both using the same basic trigonometry functions, and are both being calculated 60 times a second.

Is this a side scrolling game ? The reason I ask is that if you are side scrolling horizontally then you wouldn't need magnitude, you could use a more simple if X is bigger or smaller than some value.

Icebox

@adrenaline I tried that too interpolate , and i tried timer with every 0 seconds change attribute and other possible ways but it didnt make any difference , but this only occurs on old devices , with the new ones constrains runs great

Socks

@Icebox said:
@adrenaline I tried that too interpolate , and i tried timer with every 0 seconds change attribute . . . . .

Change attribute every 0 seconds is pretty much equivalent to constrain attribute, both change the value once every 60th of second.

Icebox

@Socks said:
Is this a side scrolling game ? The reason I ask is that if you are side scrolling horizontally then you wouldn't need magnitude, you could use a more simple if X is bigger or smaller than some value.

Yes it is a side scrolling game , most of my scenes have the width of 15,000 and height of 500 , working on iphone 5 project, the slow motion occurs on old android devices like samsung galaxy s4 and grand prime, and on ipad 3. I also tried with x position bigger or smaller but same effect so i thought it wouldnt make a difference

Icebox

@Socks said:

@Icebox said:
@adrenaline I tried that too interpolate , and i tried timer with every 0 seconds change attribute . . . . .

Change attribute every 0 seconds is pretty much equivalent to constrain attribute, both change the value once every 60th of second.

yea it was silly but i thought why not try all ways possible lol

The_Gamesalad_Guru

@Icebox said:

@Socks said:

@Icebox said:
@adrenaline I tried that too interpolate , and i tried timer with every 0 seconds change attribute . . . . .

Change attribute every 0 seconds is pretty much equivalent to constrain attribute, both change the value once every 60th of second.

yea it was silly but i thought why not try all ways possible lol

Maybe it's time to think about not moving the coins and have them set to different heights and do a spinning animation? Or do half and half.

Socks

@Icebox said:
I also tried with x position bigger or smaller but same effect so i thought it wouldnt make a difference.

Yes, it should make a difference, a simple is X bigger than Y is a more straightforward calculation than magnitude - if I were doing this I'd make a new scene, spawn a grid of a few hundred actors, with the prototype having two comparative calculations, and then run the project with one on and the other switched off, then switch them around . . . to see if either causes more processor strain, on iOS viewer you can monitor the frame rate as a pretty good guide, if neither cause it to drop below 60fps, then up the number of actors until one causes lag.

Icebox

@Lost_Oasis_Games said:
Maybe it's time to think about not moving the coins and have them set to different heights and do a spinning animation? Or do half and half.

I tried it long time ago with animation or rotation or changing size and i had performance issues , earlier thread that socks helped me with months ago http://forums.gamesalad.com/discussion/89295/actor-doesnt-collide-when-changing-the-size#latest

Im not really trying to optomize it now but i wanted to know if its possible to do the tag thing and seems like its not

Icebox

@Socks said:

@Icebox said:
I also tried with x position bigger or smaller but same effect so i thought it wouldnt make a difference.

Yes, it should make a difference, a simple is X bigger than Y is a more straightforward calculation than magnitude - if I were doing this I'd make a new scene, spawn a grid of a few hundred actors, with the prototype having two comparative calculations, and then run the project with one on and the other switched off, then switch them around . . . to see if either causes more processor strain, on iOS viewer you can monitor the frame rate as a pretty good guide, if neither cause it to drop below 60fps, then up the number of actors until one causes lag.

Sure, ill go look into that right now thanks.

The_Gamesalad_Guru

@Icebox said:

@Lost_Oasis_Games said:
Maybe it's time to think about not moving the coins and have them set to different heights and do a spinning animation? Or do half and half.

I tried it long time ago with animation or rotation or changing size and i had performance issues , earlier thread that socks helped me with months ago http://forums.gamesalad.com/discussion/89295/actor-doesnt-collide-when-changing-the-size#latest

Im not really trying to optomize it now but i wanted to know if its possible to do the tag thing and seems like its not

@Icebox said:

@Lost_Oasis_Games said:
Maybe it's time to think about not moving the coins and have them set to different heights and do a spinning animation? Or do half and half.

I tried it long time ago with animation or rotation or changing size and i had performance issues , earlier thread that socks helped me with months ago http://forums.gamesalad.com/discussion/89295/actor-doesnt-collide-when-changing-the-size#latest

Im not really trying to optomize it now but i wanted to know if its possible to do the tag thing and seems like its not

Yeah a tag isn't going to do anything for you. It's just a text identifier of an actor.

Socks

@Lost_Oasis_Games said:
Maybe it's time to think about not moving the coins and have them set to different heights and do a spinning animation? Or do half and half.

Yep, game making is the art of compromise, the original designers of Pac Man or Space Invaders were probably just as hemmed in by the limitations of the target devices, what we probably see as classic game design elements were probably the product of limitations.

The_Gamesalad_Guru

@Socks said:

@Lost_Oasis_Games said:
Maybe it's time to think about not moving the coins and have them set to different heights and do a spinning animation? Or do half and half.

Yep, game making is the art of compromise, the original designers of Pac Man or Space Invaders were probably just as hemmed in by the limitations of the target devices, what we probably see as classic game design elements were probably the product of limitations.

Yep can't make a VW bug win the Daytona 500.