Hi! Im an absolute beginner in Scratch and need some help!
So I kind of want some kind of gravity like if I jump of a cliff he's just standing in the air instead of falling down on the ground. So I need help with that.
Then my Character goes straight through other sprites, and I have no idea how to stop that.
I would really appreciate some help!
Thank you!
Offline
Please I really need help with this!!
Offline
What I use for jumping:
[blocks]
<when green flag clicked>
<glide(1)secs to x
<x position>)y
((<y position><+>howmanypixelsdoyouwanttojump))
<wait(1)secsc>
<glide(1)secs to x
<x position>)y
((<y position><+>howmanypixelsdoyouwanttogodown))
[/blocks]
Hope that helps!
Offline
For when a character is touching a sprite:
[blocks]
<when [whatever] key pressed>
<if><touching[spriteyouwant]
<glide(0)secs to x
0)y
0)
<else>
<glide(1)secs to x
(<x position><+>howfaryouwanttogo))>
[/blocks]
Hope that works!
Last edited by undefeatedgames (2011-10-25 16:17:15)
Offline
You could try using the Simulating Gravity technique at http://wiki.scratch.mit.edu/wiki/Simulating_Gravity on the Scratch Wiki and customize it to your liking.
Offline
Scratch doesn't come with colliding scripts, you've got to make you own. Because of that, many Scratchers don't make walls (I'm assuming you're making a platformer-type game). Many Scratchers, myself included, have made "game engines" with scripts such as these (that is, wall-collision scripts, gravity scripts, etc.) that are either pre-made or easily adaptable. You could try downloading one of those and looking at the scripts to see how they work or simply copying the scripts and taking for granted that they are infallible (*see below).
Many of these engines use color sensors <if [color1] touching [color2]> or other sprites that constantly follow the main sprite and see which directions it can move. The one that uses external types can be glitchy given the slight delay it takes for sprites to "go to" other sprites. The color one is great unless you're using long scripts. The lag can show the player the colors that ideally would be invisible. There are other methods though.
I use a method in which the sprite itself tests the directions. This is good in that there are no other sprites or costumes (the color-sensor method uses a second costume) and is completely adaptable to different costumes. It is bad because the script is rather long, you can not change costumes mid-game, and, though tolerable, very long scripts can cause this method to make the sprite "vibrate". On the plus side, the entire script is run by 1 loop, meaning there is no "delay effect" of scripts running on different time tables.
Sorry for the essay xD
* Many engines claim to be "perfect" meaning they are glitch-free. You should test whether or not they really. Some claim to be but are not, others don't claim this but could very well be glitch-free. Self-testing is the key to good game making. It can be boring, but it is the only way to catch bugs and make a fun game.
Last edited by MoreGamesNow (2011-10-25 21:18:54)
Offline