Scratch

I have the gravity but not the movement.

So can you just post the singular script w/ instructions?  I greatly appreciate your help.

~~Firedrake969

AngstromDog wrote:

when gf clicked
forever
if <key [left arrow v] pressed?>
change [gravdirec v] by (3)
end
if <key [right arrow v] pressed?>
change [gravdirec v] by (-3)
end
change [xvel v] by <(gravity)  *  ([cos v] of  (gravdirec))>
change [yvel v] by <(gravity) * ([sin v] of (gravdirec))>
change x by (xvel)
change y by (yvel)

Fixed

Firedrake969- Are you still interested in this topic?

If you don't want to deal with something unnecessarily complicated (like my post above, #8), check out some of zubblewu's planetary gravity things.  The code is pretty straightforward.  You can also look at a remix of one of his projects that I uploaded to my test account.  I would recommend checking out that link, since the project works pretty well.  I didn't even have to use color or sprite sensing, just distance checking.

Okay, so there's something we need to talk about before I (or anyone else) writes out a script.

How physically accurate do you want this simulation to be?  Zubblewu's planet projects, though cool, weren't quite accurate.  The velocity variable in those expressed a change in direction; the direction of the line drawn from the center of the circle to the player.  Now, if you only talk about the velocity at which that line is turning, you don't consider that if the player is further away from the circle, the same rotation will move him further (imagine putting something on the end of a long stick and rotating the stick 1 degree per second).

Last edited by amcerbu (2012-06-20 16:10:56)

Wes64 wrote:

amcerbu wrote:

Okay, so there's something we need to talk about before I (or anyone else) writes out a script.

How physically accurate do you want this simulation to be?  Zubblewu's planet projects, though cool, weren't quite accurate.  The velocity variable in those expressed a change in direction; the direction of the line drawn from the center of the circle to the player.  Now, if you only talk about the velocity at which that line is turning, you don't consider that if the player is further away from the circle, the same rotation will move him further (imagine putting something on the end of a long stick and rotating the stick 1 degree per second).

I think that might be a bit overboard. He doesn't even know how to do basic directional  gravity (hence the existence of this topic) so true physics might be a bit... much.

I want it to be fairly accurate, so that the player does not move off of the circle when moving.

This particular version is 1s1s, but it could be adapted to work for a system that uses multiple sprites.  To increase the accuracy of the simulation, it doesn't use the "touching color" or "touching sprite" sensors; everything is done by measuring distance.  Warning: this has not been tested yet, but I feel fairly confident it will work (some of the code was inspired by zubblewu's planet projects). 

when gf clicked
hide
clear
set [Planet.Radius v] to [value] // These statements initialize variables.  
set [Square.Size v] to [value] // Length/width number for the square costume.  
set [Planet.X v] to [0] // Center position of planet. 
set [Planet.Y v] to [0]
set [Velocity.Y v] to [0]
set [Velocity.R v] to [0] // Rotational velocity.  
set [Rotation v] to [0] // Straight up.  
set [Distance v] to ((Planet.Radius) + (Square.Size)) // A little above planet. 
set [MinimumDistance v] to ((Planet.Radius) + ((Square.Size) / (2)))
set [Friction v] to [0.8]
set [Gravity v] to [-0.1]
set [Jump v] to [4]
set [Speed v] to [1]
forever
set [Square.X v] to (([cos v] of (Rotation)) * (Distance))
set [Square.Y v] to (([sin v] of (Rotation)) * (Distance))
clear
go to x: (Square.X) y: (Square.Y) // Drawing the square and circle.
switch to costume [Square v]
point in direction ((90) - (Rotation))
stamp
go to x: (Planet.X) y: (Planet.Y) // The center of the planet.
switch to costume [Planet v]
point in direction (90 v)
stamp
set [Rotation v] to ((Rotation) mod (360))
set [Velocity.R v] to ((Velocity.R) * (Friction))
change [Rotation v] by (Velocity.R)
change [Distance v] by (Velocity.Y)
if <(Distance) < (MinimumDistance)> // Collision with planet.  
set [Distance v] to (MinimumDistance)
set [Velocity.Y v] to (0)
else
change [Velocity.Y v] by (Gravity)
end
if <key [right arrow v] pressed?> // Arrow key responses.  
change [Velocity.R v] by ((-1) * (Speed))
end
if <key [left arrow v] pressed?>
change [Velocity.R v] by (Speed)
end
if <<key [up arrow v] pressed?> and <(Distance) = (MinimumDistance)>>
set [Velocity.Y v] to (Jump)
end

Last edited by amcerbu (2012-06-25 18:14:07)

You, sir, deserve a medal (amcerbu). I'm impressed with your script, and I'm impressed that you took the time to figure out how to do it in Scratch Blocks. xDD

I just write it in scratch and take a screenshot. 

Would AngstromDog be as good as that one?  I don't like too many variables in a script.

Firedrake969 wrote:

Would AngstromDog be as good as that one?  I don't like too many variables in a script.

I tried out AngstromDog's script, and I don't think it's what you're looking for.  You want to make "planet gravity," right?  In which a character walks around a circular planet?

And yes, fg123 is right: Variables are deathly useful.  If/when you start programming in another language, you'll see that variables are everything.  The main difference about Scratch is that variables can't go "out of scope," you can't make variables local to a script, etc.

Last edited by amcerbu (2012-06-27 14:54:18)

Okay.  Some of the variables aren't completely necessary in my script, but they make your life simpler when you want to play around with different "qualities."  For example, how fast the player goes, how quickly he slows down, the size of the planet, the location of the planet, etc.  There's an idea in programming that you should avoid "magic constants."  Check out this article.