ChessPawn said: Also, I am only using the demo for the super complicated formula.
I bet I'm sounding extremely stupid right now, but I just don't get it. :P
OK -- Let me say I admire your determined focus and persistence.
The problem is that we both don't (yet) have the math chops to independently write a function to plot the trajectory you want. But you found a demo that gets you most of the way. The problem is that the demo is set up for a trajectory that is on a flat surface. But you want to plot a trajectory that has different starting and ending Y coordinates. It's as if you want to fire a cannon from a hill -- but the demo's equation is set up to work like it is firing a cannon on a flat surface.
The other thing you want to do is have the dots swap sides -- according to which side the mouse is on. But the demo is set up to have dots all the way across the bottom.
So, you have a choice. Either come up with a new trajectory equation. Or use the equation you have found. And either come up with a way to move the dots back and forth (depending on which side the mouse is on) -- or use the demo's way of doing it.
My suggestion has been to use the demo but hide the things you don't want the user to see. (Including having dots evenly spaced across the bottom of the entire scene.) Even if you know its not doing it exactly like you want -- it's like being a magician. It's all illusion!
For example, I've tried to show that the dots have been there all along. But the original demo had them hidden below the scene. (Thats the -10 part.) Its OK to hide stuff you don't want the user to see.
You indicate that you want the dots to start in the center of the ninja. If you go the demo route, the dots will always be there, but you can still hide them and create the illusion of them starting in the center of the ninja. What you can do is set the alpha of the dots on the 'wrong' side of the center of the ninja to 0. And set the dots on the 'good' side of the ninja to 1.
Inside the mousedown rule of the "Plot Point" prototype (just below the long trajectory equation) -- add in the following two rules.
Rule: When all conditions are valid: ….Attribute: game.Mouse.X > game.gunX …..Attribute: self.Position.X < game.gunX ……..Change Attribute: self.Color.Alpha To: 0 ….Otherwise: ……..Change Attribute: self.Color.Alpha To: 1
Rule: When all conditions are valid: ….Attribute: game.Mouse.X < game.gunX …..Attribute: self.Position.X > game.gunX ……..Change Attribute: self.Color.Alpha To: 0 ….Otherwise: ……..Change Attribute: self.Color.Alpha To: 1
This will hide the offensive little dots that are sneaking up the backside of your ninja.
Its a pure fake-out, an illusion for your audience. To them it will look like the dots are flipping sides, and starting near the center of the ninja. But you will know it's only an illusion.
I really hope this little trick gets you closer to how you want things to appear.
RTHurman, you just made my day! This looks amazing! Now, I have one more question for you. This one probably sounds really easy, and it probably is. I have to go get my 40 hours of community service for high school done, but I'm still gonna be thinking about this. So my ninja moves in midair (yay!). But I want him to throw a shuriken, only when he is in midair, and the user taps with one finger. The problem is, when the user taps, the ninja moves in that direction as well. I tried to use an attribute to say that movement could only happen when game.MidAir is false, but then the ninja never processes the fact that it has gravity on it, so it just keeps going in a straight line diagonally. How would I make it so that he can throw a shuriken only when he is in midair, but not move when tapped?
The next question sounds like a new forum topic. I'd suggest making a new one. By now this one is so specific that I'm sure everyone has abandoned even glancing at it. You might get more responses if you start a new thread. I'd also suggest being more specific. For example, what rule(s) do you use to get the ninja to move, and what rule(s) do you use to spawn and move the projectile. And what is the exact behavior or the ninja that is going wrong.
Cool. One last question. These are what my controls should be.
Drag and move to control dots. Let go to fly. Tap for shuriken.
Are the rules I use now enough? In other words what's the difference between touch is pressed and mouse is down?
This is going on an iDevice (dunno which one), and I can't test until iPhone 5 comes out, because I don't wanna get an iPhone 4, just to find out the iPhone 5 came out next month. :P
Thanks. Last question on this thread, hopefully. In the video attached, you will see two things. The weird slanted part on the beginning left side, and the dots it forms in midair. Just watch my mouse. Is there anyway I can get all of these dots to spawn in the beginning as invisible, and, in the meantime, I will have a 3-2-1 countdown to let the dots spawn undisturbed? Second, can I make the dots invisible in midair?
You've probably figured this out already but -- yes.
I think that you can fix it all if you go into the plot point prototype and open up the otherwise section of the mouse down rule. Then add a change attribute: self.Color.Alpha To: 0
Then the dots only show up when the mouse is down -- otherwise they are not visible.
OK -- there is a little bit of logic that needs fixing. Most of if has to do with using constrain instead of change attribute Here is what the mousedown rule should look like:
Rule: When all conditions are valid: ....Actor receives event: mouse button: is down ........Constrain Attribute: self.Position.Y To: (the trajectory equation)
….....Rule: When all conditions are valid: ….....….Attribute: game.Mouse.X > game.gunX ….....…..Attribute: self.Position.X < game.gunX …....…..….Constrain Attribute: self.Color.Alpha To: 0 ….....….Otherwise: …....…..….Constrain Attribute: self.Color.Alpha To: 1
….....Rule: When all conditions are valid: ….....….Attribute: game.Mouse.X < game.gunX …......….Attribute: self.Position.X > game.gunX ……......….Constrain Attribute: self.Color.Alpha To: 0 ….....….Otherwise: …....…..….(don't have anything in this one -- leave it blank)
....Otherwise: ........Constrain Attribute: self.Color.Alpha To: 0
I tested it out in the demo and it seems to work OK
Well... that's unexpected! Does it do that all the time? Under what conditions does it happen?
A couple of guesses:
1) Has the device flipped into a different orientation? (Is it coded for portrait mode but its been flipped to landscape.)
2) Is the actor point to 0 when it starts? (Is the ninja's left arm pointing to the right of the screen? Or has the ninja been rotated to get it to look like it is stand upright?) (The rotated actor might also explain the strange angle of the first three dots when the game begins.)
No… The game is coded for both landscapes, and it is not weirdly rotated. All the weird things are happening in the iOS simulator coming with Xcode, but they don't happen in the GS preview. For example, on scene load, the ninja moves to the left in the iOS simulator, but not in GS. And, it makes the weird deformed curve. Gaaahhhh!!
Will try that. Now here's the final final question. There's gonna be walls in the middle of my game. How can I make it so that the dots cancel out and stop when they hit the wall, and when moved away from the wall, they all come back. Could it be like, if it collides with wall change alpha to 0, otherwise make alpha 1?
ChessPawn said: No… The game is coded for both landscapes, and it is not weirdly rotated. All the weird things are happening in the iOS simulator coming with Xcode, but they don't happen in the GS preview. For example, on scene load, the ninja moves to the left in the iOS simulator, but not in GS. And, it makes the weird deformed curve. Gaaahhhh!!
Darn! :P
your gonna need a device to test asap. The ios simulator from xcode behaves alot differnt then the device.
Thanks John. I am definitely looking forward to iPhone 5 (first phone ever!). Any ideas about making dots invisible when they hit a wall and not letting them go past, but then coming back into view when not colliding with the wall. I don't think my idea above works. :P
BTW: Is it possible to put GS Viewer on any iDevice with a free developer account?
ChessPawn said: Could it be like, if it collides with wall change alpha to 0, otherwise make alpha 1?
Place an actor that has the same background as the game (in your video it looks like that would be a big black swatch), beside the wall. If this actor is layered so that it is on top -- the dots beyond the wall will be hidden from view. You will need to resize the actor so that all the dots you want hidden are actually hidden.
(This trick would have also worked for hiding the left hand or right hand dots in a previous question.)
That would work for a wall that I can't pass, but what about a block that is randomly stationed in the middle of my level. I only want the dots to hide when it goes through the block, e.g not if I am making a curve directly beside the block. Unless I am totally misunderstanding what you are saying…
I guess I didn't understand what you are requesting. I thought you wanted the dots to look like they hit a wall and then stop. An easy way to achieve that effect is to put up a graphic of a wall, and then put up a black screen so that the dots behind the screen don't show. Its just an old magician's trick (used on 'stage' for two or three millenia).
Oh wait, perhaps you are asking how to make a block wall background?
If we put invisible walls around this block, the user might make a curve just under the block, and the top would be invisible, and it would look plain weird. :P
OK -- so I guess I was imagining that all the walls would extend to the 'floor'. (Like the red one.) But you are also planning on having 'walls' that float in the air. (Like the white one.)
In your second picture, I assume you are referring to how the dots continue on to the left side after they hit the big white square? I'm just suggesting that you make a screening actor that would be placed to the left of the white box and all the way down to the floor. I'd probably also put another one underneath the white box that would extend to the floor. (Wherever you want the dots to disappear.)
Of course, if you don't want to use layering. You could also use collision detection and turn the dot's alpha to 0 whenever it hits a wall or a screening actor.
---------------------
Perhaps what you are really after is a way to just turn all the dots off that go past a wall. That would involve a little more logic but is possible. For example, first you could test to see if a dot (any dot) hits a wall. Then you could test to see what side of the wall is facing the ninja, (eg. if ninjaX is less than wallX). Then you tell each dot that is on the 'wrong' side of the wall to go invisible. (eg. when dotX is greater than wallX -- change dotAlpha to 0).
I thought the last part would work as well, but it turns out not… Got no idea why.
Also the reason I don't want to put a screening actor on a 4 side accessible box is because it would look weird if the dots cut short, and go straight through again. Changing alpha seems like the only way, but for some reason it's not working. I put all the conditions under the plot point actor.
ChessPawn, let me interrupt this thread for a minute and say I am sooo glad that RThurman is helping you with this. I read through this and dang! Is this complex! I really admire your persistence in making this what you want it to be and not giving up entirely, or abandoning your vision for something simpler. You could charge 50 bucks for this game and you would have at least one sale! (but don't, cause I'm broke and unemployed.) ;p
Can't wait to see this finished.
Now... Carry on, you two.
(And I am so gonna hit up you and RThurman when it's time for my game to need some tricky math.)
Sorry, but it may be necessary to back off of the wall thing for a little while. I can't quite work out the logic. The only solutions I can think of are so brittle that any little thing makes it go wonk. Sometimes it helps just to set it aside for a few days and let the old noggin keep processing it in the background.
The efficient solution to this problem involves ray tracing. But I'm not sure how to implement that in GameSalad.
That was just a stray thought. Ray casting is sometimes used in game engines. Basically think of it as shooting out a 'ray' to see if the 'ray' is going to intersect another object. It can be used for distance detection, collision detection, and stuff like that. But, like I said, it was just a stray thought.
Comments
The problem is that we both don't (yet) have the math chops to independently write a function to plot the trajectory you want. But you found a demo that gets you most of the way. The problem is that the demo is set up for a trajectory that is on a flat surface. But you want to plot a trajectory that has different starting and ending Y coordinates. It's as if you want to fire a cannon from a hill -- but the demo's equation is set up to work like it is firing a cannon on a flat surface.
The other thing you want to do is have the dots swap sides -- according to which side the mouse is on. But the demo is set up to have dots all the way across the bottom.
So, you have a choice. Either come up with a new trajectory equation. Or use the equation you have found. And either come up with a way to move the dots back and forth (depending on which side the mouse is on) -- or use the demo's way of doing it.
My suggestion has been to use the demo but hide the things you don't want the user to see. (Including having dots evenly spaced across the bottom of the entire scene.) Even if you know its not doing it exactly like you want -- it's like being a magician. It's all illusion!
For example, I've tried to show that the dots have been there all along. But the original demo had them hidden below the scene. (Thats the -10 part.) Its OK to hide stuff you don't want the user to see.
You indicate that you want the dots to start in the center of the ninja. If you go the demo route, the dots will always be there, but you can still hide them and create the illusion of them starting in the center of the ninja. What you can do is set the alpha of the dots on the 'wrong' side of the center of the ninja to 0. And set the dots on the 'good' side of the ninja to 1.
Inside the mousedown rule of the "Plot Point" prototype (just below the long trajectory equation) -- add in the following two rules.
Rule: When all conditions are valid:
….Attribute: game.Mouse.X > game.gunX
…..Attribute: self.Position.X < game.gunX
……..Change Attribute: self.Color.Alpha To: 0
….Otherwise:
……..Change Attribute: self.Color.Alpha To: 1
Rule: When all conditions are valid:
….Attribute: game.Mouse.X < game.gunX
…..Attribute: self.Position.X > game.gunX
……..Change Attribute: self.Color.Alpha To: 0
….Otherwise:
……..Change Attribute: self.Color.Alpha To: 1
This will hide the offensive little dots that are sneaking up the backside of your ninja.
Its a pure fake-out, an illusion for your audience. To them it will look like the dots are flipping sides, and starting near the center of the ninja. But you will know it's only an illusion.
I really hope this little trick gets you closer to how you want things to appear.
Hang in there!
RThurman
Thanks :P
The next question sounds like a new forum topic. I'd suggest making a new one. By now this one is so specific that I'm sure everyone has abandoned even glancing at it. You might get more responses if you start a new thread. I'd also suggest being more specific. For example, what rule(s) do you use to get the ninja to move, and what rule(s) do you use to spawn and move the projectile. And what is the exact behavior or the ninja that is going wrong.
Great job!
RThurman
Drag and move to control dots.
Let go to fly.
Tap for shuriken.
Are the rules I use now enough? In other words what's the difference between touch is pressed and mouse is down?
This is going on an iDevice (dunno which one), and I can't test until iPhone 5 comes out, because I don't wanna get an iPhone 4, just to find out the iPhone 5 came out next month. :P
Thanks!
a) every actor receives the mouse down message
b) only the actor with the rule receives the touch pressed message
RThurman
Thanks! :P
EDIT: Forgot the video ROFL
http://tinypic.com/r/4hv3tc/7
I think that you can fix it all if you go into the plot point prototype and open up the otherwise section of the mouse down rule. Then add a change attribute: self.Color.Alpha To: 0
Then the dots only show up when the mouse is down -- otherwise they are not visible.
Video is looking good!
RThurman
How can changing colors be so difficult? :P
Rule: When all conditions are valid:
....Actor receives event: mouse button: is down
........Constrain Attribute: self.Position.Y To: (the trajectory equation)
….....Rule: When all conditions are valid:
….....….Attribute: game.Mouse.X > game.gunX
….....…..Attribute: self.Position.X < game.gunX
…....…..….Constrain Attribute: self.Color.Alpha To: 0
….....….Otherwise:
…....…..….Constrain Attribute: self.Color.Alpha To: 1
….....Rule: When all conditions are valid:
….....….Attribute: game.Mouse.X < game.gunX
…......….Attribute: self.Position.X > game.gunX
……......….Constrain Attribute: self.Color.Alpha To: 0
….....….Otherwise:
…....…..….(don't have anything in this one -- leave it blank)
....Otherwise:
........Constrain Attribute: self.Color.Alpha To: 0
I tested it out in the demo and it seems to work OK
RThurman
What's happening here?
http://tinypic.com/r/2mmiwm/7
A couple of guesses:
1) Has the device flipped into a different orientation? (Is it coded for portrait mode but its been flipped to landscape.)
2) Is the actor point to 0 when it starts? (Is the ninja's left arm pointing to the right of the screen? Or has the ninja been rotated to get it to look like it is stand upright?) (The rotated actor might also explain the strange angle of the first three dots when the game begins.)
Darn! :P
Its not great advise, but I'd suggest just moving forward using preview. Then when you get your iOS device, you can test it in the GSViewer.
RThurman
BTW: Is it possible to put GS Viewer on any iDevice with a free developer account?
(This trick would have also worked for hiding the left hand or right hand dots in a previous question.)
Oh wait, perhaps you are asking how to make a block wall background?
http://i51.tinypic.com/f445rd.png
But what about one in the middle of the level:
http://i54.tinypic.com/2dvl5ht.png
If we put invisible walls around this block, the user might make a curve just under the block, and the top would be invisible, and it would look plain weird. :P
In your second picture, I assume you are referring to how the dots continue on to the left side after they hit the big white square? I'm just suggesting that you make a screening actor that would be placed to the left of the white box and all the way down to the floor. I'd probably also put another one underneath the white box that would extend to the floor. (Wherever you want the dots to disappear.)
Of course, if you don't want to use layering. You could also use collision detection and turn the dot's alpha to 0 whenever it hits a wall or a screening actor.
---------------------
Perhaps what you are really after is a way to just turn all the dots off that go past a wall. That would involve a little more logic but is possible. For example, first you could test to see if a dot (any dot) hits a wall. Then you could test to see what side of the wall is facing the ninja, (eg. if ninjaX is less than wallX). Then you tell each dot that is on the 'wrong' side of the wall to go invisible. (eg. when dotX is greater than wallX -- change dotAlpha to 0).
Also the reason I don't want to put a screening actor on a 4 side accessible box is because it would look weird if the dots cut short, and go straight through again. Changing alpha seems like the only way, but for some reason it's not working. I put all the conditions under the plot point actor.
Can't wait to see this finished.
Now... Carry on, you two.
(And I am so gonna hit up you and RThurman when it's time for my game to need some tricky math.)
The efficient solution to this problem involves ray tracing. But I'm not sure how to implement that in GameSalad.