Spin a group as a single object?
x2501x
Member Posts: 11
Hi, I'm evaluating different game building apps to make a game I recently conceived. A major part of this game would involve a rotating planet, with objects that stick to the planet when they collide with it and then from that point rotate as part of. So I'm looking for some kind of function that can either make objects stick together and be rotated as a group, or else a behavior that will make one object rotate around another object or (worst-case) make an object rotate around a point on the screen. After my first few hours of digging I am not finding this as an obvious feature in GameSalad. Can anyone point me to such a feature, or any kind of library/code for customizing it if necessary?
Comments
http://forums.gamesalad.com/discussion/62202/linkmachine
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
You can link objects (aka actors) "on the fly" but it's a complicated process to code. An example of this, though not one that rotates, is my health bar demo: http://forums.gamesalad.com/discussion/comment/384027/#Comment_384027.
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
If you set up a rule that says when the player touches the 'cookie actor' it cries (don't steal my ideas) then just because you've set this up when you build the game doesn't mean you can't then have it happen throughout the game wherever you like . . . . it's the same deal with using a rotate or constrain behaviour, you can get then to 'switch on’ when you want.
I that knew when I reposted the video in that thread that unless it was in the initial post people wouldn't scroll down to find it
Anyway, it's fixed now @Socks .
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
Magic ! Cheers @tatiang
I still don't understand GameSalad well enough to have found this on my own so I will ask--is the actual control of the constrain behaviour part of your "link machine", or is Link Machine only the tool show in the video for setting up the relationships, and the constraints are things built into GameSalad itself?
I'm not sure I recognise the distinction, I'm not sure what the difference would be between figuring out a rule when you set the scene up or otherwise ? Isn't everything part of setting a scene up, sorry I'm a little confused by what you mean here ?
Again, I'm a little confused, doesn't take much to confuse me sometimes
GameSalad has constrain behaviours built into its rule set, once you've used this 'calculator' to work out the numbers you need to put into the constrain behaviours it plays no other role.
Hope that all makes sense.
What I'm saying is that I would need to *calculate those numbers* in the game, not ahead of time. Imagine, based on your own example, that your police car was spinning around, and someone threw a sticky siren/light at it, which might hit the police car at any point, and might be at any angle when it hit it, but *from then on* it would move and rotate as if it were solidly stuck to the police car, staying at the same distance and relative angle to the car as the car itself turned and moved. That's the problem I'm trying to solve.
I hope that makes it more clear? I guess I'm just finding things frustrating because I am used to working with 2d animation apps like Motion or Premiere, where you can just take a group of objects and set them to be a group with a specified center of motion, and then rotate them all around that center with a single action. As a backup I had been searching in GameSalad for some way to specify the center of rotation for an object to see if there is a way to offset that outside the dimensions of that object? That is, forget for a moment the idea of even sticking two things together, is there a way to set the center of rotation for a single object around a point outside the boundaries of the object?
wait... no, he did that too...
Make three attributes.
real "Orbit",
angle "Rotation"
and
real "Radius".
You can then use Constrain, or Change, or Interpolate to "calculate those numbers" in the game... and not ahead of time.
when the actor collides with the planet, you might want to try recording its position in relation to the planet in a couple self.attributes and use them so the object can reference where it collided with the planet. For example, you could use magnitude to determine the radius.
When overlapping or colliding with object
change self.radius to magnitude(self.position.x-planetposition.x, self.position.y-planetposition.Y)
So, is that correct--once I have a bit more of a handle on the workings of GameSalad and grab that zip file, the behaviors for Orbit, Rotation and Radius are contained in that project? I'm sorry I guess my assumption was that since the demo video *only* showed off the function for generating the numbers, that was the only part that @Socks had created.
That is, I have poked around in several places and searched through the online documentation and I see no mention of the word "radius", which makes me think that is not something that is a built-in behavior in the game?
What is the "radius" constrain behavior? I have looked at the "Constrain Attribute" behavior built into GameSalad, and I see nothing that maps to "radius". So, if I create a constrain behavior and *name it* "radius", how do I actually make it *do something* that has to do with constraining a radius? My presumption from reading your instructions was that you had built a custom behavior named "radius" that does something, but now you're saying you don't have a clue what I mean.
Behaviors are essentially predefined code that can serve multiple purposes. A constrain does exactly what it says. It constrains an attribute to a value (or another attribute, so any given variable).
This is very useful for joining two objects. Such as a rock and a planet. On the simplest level you could make an x and y attribute for the planet (integer or real) and, let's call them PlanetX and PlanetY and then say:
Planet Actor:
Constrain PlanetX to Self.positionX
Constrain PlanetY to Self.positionY
Rock actor:
When touch is pressed:
Constrain Self.positionX to PlanetX
Constrain Self.positionY to PlanetY
What this does is globally advertises the position of the planet actor so that the rock actor can pull that information and know where to lock to. In this case, this would allow you to constrain it to x and y position.
However what you're asking for is a bit more complex because it requires you to find more then just a pixel position. Thus this is where @Socks Linkmachine comes in. He has created some triginometric equations to take information passed (x/y/rotation) and make a more complex relationship.
While not every aspect of the project is what you need, it does provide the means for creating the relationship of actor
Like you say there is nothing that 'maps' to 'radius' (I'm not even sure where you were looking to see what maps to radius ?), nor is there anything that maps to 'alien width' or 'score colour' or 'arrow direction' . . . and so on, it's just an 'empty' behaviour looking for you to tell it what to do. I'm not sure you can 'name' behaviours (in any meaningful way at least), do you mean change the title in the behaviour's title panel ? Well, that's a difficult question to answer as it is so vague, you'd need to be a lot more specific. Yes.
I *understand* what "constrain" means. I get that. But there is no built in "radius" attribute to constrain to something. And so as I said, my assumption was therefore that @socks had made a custom behavior that *effectively* constrains the orbit and radius, but when I asked if that was the case, he said no. Can you see why I might find this frustrating? If *neither* of those is the case, then what *is* the case? Where do the "orbit" "radius" and "rotation" constraint behaviors *come from*?
It's much simpler than people often think.
Essentially what your looking for @x2501x is this
Constrain Self.position.X to radius*cos(PlanetRotation)+PlanetX
Constrain Self.position.Y to radius*sin(PlanetRotation)+PlanetY
Constrain Self.Rotation to PlanetRotation
This will provide you the actor relationship you need. Like @Socks said Cos is for X Sin is for Y.
Now to explain the variables:
radius is just how far from the main actor you would like it, it can be a static number you type in or a attribute to change it on the fly/easier adjustment.
PlanetRotation is a attribute used to track the rotation of the parent object
PlanetX/Y are attributes used to track the pixel position.
Of course these could be static values you type in as well, but it would'nt be very exciting without some movement/roation!
Linkmachine expands on this with more variables for greater actor control.
There are no orbit, radius or rotation constrain behaviours, the constrain behaviour simply tracks one value to another, you can use it for anything you want.
The only thing you'd also need in there would be an offset for the PlanetRotation . . . . so for instance if you have an incoming missile fired at the earth - it will hit in some arbitrary location . . . . you need to factor that in, otherwise all the missiles that collide with the earth and then are constrained to your rules will all end up in the same position, you'd need something like this . . . .
Constrain Self.position.X to radius*cos(PlanetRotation+theAngleTheyHitAt)+PlanetX
Constrain Self.position.Y to radius*sin(PlanetRotation+theAngleTheyHitAt)+PlanetY
Yep, not really given that part much thought, but it's probably just a 'when actor overlaps or collides with 'Planet' rule . . . . . ?
There is no text formatting that I can see on this forum. I am using asterisks for emphasis (in place of italics) and I was using quotations... because I was quoting words. Let me test something to see if HTML text tags will work.
As for the source of my confusion--In your instructions, you say that LinkMachine controls three variables, Orbit, Radius and Rotation. Later, in your instructions, you say: Can you see why it might make sense that I would assume the "three constrain behaviors" would, therefore, map to "Orbit", "Radius" and "Rotation"?
It's just a coincidence of kinds, they are related of course, but it's not a simple case of 1, 2 and 3 match 1, 2 and 3, one for 'orbit' one for 'radius' and one for 'rotation'. . . . one of the three constrain behaviours controls horizontal position of the actor, one controls the vertical position and one controls the rotation, so 'orbit' and 'radius' values are spread out across constrain behaviours 1 and 2 (x and y position), in fact that's all this really does, change the X and Y coordinates.
The idea of the Link Machine was to simplify a commonly used and simple (if not always intuitive) bit of trigonometry, what the constrain behaviours are constraining is the X and Y position of an actor (and the rotation if needed). All the other stuff, the words 'radius' and 'orbit' and the coloured lines and circles are just visual and conceptual aids, a kind of translation of the underlying trigonometry, rather than telling people they need to offset the angle on which cosine and sine are operating in order to move the object to a different angle in relation to the parent actor, I just used the term 'orbit' . . . as in 'drag the yellow slider around to change the orbit position' . . . . you could have called it anything, 'radial position' perhaps, or 'moon position' or even use the numbers on a clock, 1 o'clock, 2 o'clock, 3 o'clock, 4 o'clock . . . and so on, and just like 'radius' or 'orbit' you'd have no luck searching for 'radial position', '8 o'clock' or 'moon position' in any GameSalad manuals or forum posts.
My trig is a bit rusty, but for getting the values on the fly--
Am I right to assume that at the point of collision, I can just calculate the radius on the fly by taking the square root of delta-X squared plus delta-Y squared (delta from the center of the planet), or is there some other factor I'm overlooking?
And for the offset angle at initial impact, that would be X=tan-1(delta-Y/delta-X) ?