I have a game called Zombie Defense. In One Player mode, the player points toward the mouse. If it touches a wall, it moves -5 steps. Sometimes, it goes through walls. Any help here?
Offline
Doing wall detection in this circumstance is difficult, as you basically have to go through walls if the mouse is in the right place. You could change x and y velocities based on the mouse position, which would make walls a lot easier to program. Is this a viable option?
Offline
make sure you're not going faster than the width of the wall. Otherwise you will go through the walls.
Offline
joefarebrother wrote:
make sure you're not going faster than the width of the wall. Otherwise you will go through the walls.
The problem isn't wall thickness (at least, not directly), since the position of the sprite is directly related to the position of the mouse. The ball isn't really "moving" in the traditional sense, but rather "teleporting" to a point, regardless of whether walls lie between that point and its previous point. You'll either have to check along the path the ball travels (fairly complicated) or work with some kind of velocity script (less complicated, but I wouldn't say "easy").
Offline
MoreGamesNow wrote:
joefarebrother wrote:
make sure you're not going faster than the width of the wall. Otherwise you will go through the walls.
The problem isn't wall thickness (at least, not directly), since the position of the sprite is directly related to the position of the mouse. The ball isn't really "moving" in the traditional sense, but rather "teleporting" to a point, regardless of whether walls lie between that point and its previous point. You'll either have to check along the path the ball travels (fairly complicated) or work with some kind of velocity script (less complicated, but I wouldn't say "easy").
It's a badly painted person from sky view... Anyways, your right...
Offline
Did you use color sensing or sprite sensing?
Try using sprite sensing as the wall...
lalala3 is quite right... because the mouse pointer is black... and you might have used color sensing.
Offline
MoreGamesNow wrote:
joefarebrother wrote:
make sure you're not going faster than the width of the wall. Otherwise you will go through the walls.
The problem isn't wall thickness (at least, not directly), since the position of the sprite is directly related to the position of the mouse. The ball isn't really "moving" in the traditional sense, but rather "teleporting" to a point, regardless of whether walls lie between that point and its previous point. You'll either have to check along the path the ball travels (fairly complicated) or work with some kind of velocity script (less complicated, but I wouldn't say "easy").
What you could do: instead of going directly to the inverse of mouse x and mouse y, as MoreGamesNow pointed out, store those values in variables ("destination x" and "destination y", for example). The player attempts to move to that location at a steady speed. If he can't get there (he runs into a wall), he backs up. This is more of the "check along the path the ball travels" method, but that should do it. This is probably easier than a velocity method (in my opinion). That being said, I don't really like working with Scratch direction in the first place, so I end up using velocity anyway.
Last edited by amcerbu (2012-06-10 20:09:06)
Offline
This script should work "better". Increasing the number of trials (increase "5" and the if-else statements) will make it "better", but at the cost of speed. I don't want to guess whether it will fit into a single frame, but, at the very least, the script should show the basic concept.
when gf clicked forever set [m_x v] to (mouse x) set [m_y v] to (mouse y) set [x v] to (x position) set [y v] to (y position) set [d v] to ((distance to [mouse-pointer v])/(5)) point towards [mouse-pointer v] move (d) steps if<touching [wall v]?> go to x:(x) y:(y) else set [x v] to (x position) set [y v] to (y position) move (d) steps if<touching [wall v]?> go to x:(x) y:(y) else set [x v] to (x position) set [y v] to (y position) move (d) steps if<touching [wall v]?> go to x:(x) y:(y) else set [x v] to (x position) set [y v] to (y position) move (d) steps if<touching [wall v]?> go to x:(x) y:(y) else set [x v] to (x position) set [y v] to (y position) move (d) steps if<touching [wall v]?> go to x:(x) y:(y) end end end end end
Offline
I like simpler programs though... My personality is "try to find the easiest way to get the best achievement possible."
Offline
It doesn't to me, though. Any simpler scripts? I'm making the project with my friend and he is a beginner.
Offline
This may be simpler.
when gf clicked forever set [d v] to ((distance to [mouse-pointer v])/(length of sprite)) point towards [mouse-pointer v] set[bool v] to [false] set [x v] to (x position) set [y v] to (y position) repeat until <<(distance to [mouse-pointer v]) < (length of sprite)> or <(bool) = [true] >> broadcast [check v] and wait end go to x:(mouse x) y: (mouse y) if <touching [wall v]?> go to x:(x) y:(y) end When I Receive [check v] move (d) steps if<touching [wall v]?> go to x:(x) y:(y) set [bool v] to [true] else set [x v] to (x position) set [y v] to (y position) endP.S. 1,300th post!
Last edited by MoreGamesNow (2012-06-16 07:58:06)
Offline
fetzer wrote:
Ya, i might also suggest making the wall a bit thicker?
Yep,that is a great idea,but what if u wanna make a wall thin?first you have to make a maximum velocity(your caracter cannot go faster than a certain speed),then make your sensor as thick as your maximum velocity(e.g. Max vel. Equals 5,u make sensor 5 pixels(if u don't know that measure,just estimate)).
Offline
EPICPIKAGUY wrote:
fetzer wrote:
Ya, i might also suggest making the wall a bit thicker?
Yep,that is a great idea,but what if u wanna make a wall thin?first you have to make a maximum velocity(your caracter cannot go faster than a certain speed),then make your sensor as thick as your maximum velocity(e.g. Max vel. Equals 5,u make sensor 5 pixels(if u don't know that measure,just estimate)).
No offense,of corse!
Offline
amcerbu wrote:
Well, if Scratch had greater computational speed (in other words, no built-in delay), I would use a recursive function, but unfortunately, loops are slow.
I don't think turbo mode has the delay.
Offline