so many problems...

[SparkOut]

This section:

Code: Select all

on mouseMove x,y -- handle dragging if the user is dragging the stack
  if not tDragging then exit mouseMove
  put (x - cx) + (dx div 2) into dx
  add (x - cx) to sx
  put (y - cy) + (dy div 2) into dy
  add (y - cy) to sy
  set the loc of this stack to sx,sy
  put dx
end mouseMove

handles the "speed" of movement. It is set to simulate the "strength" of the "fling", based on how far the mouse cursor moved since the drag began. When dragging begins, the original location is set and while moving, if it's still dragging then it updates the dx and dy values to reflect how far the drag has been "under power" from the user. dx is the amount by which the strength is adjusted in the x direction and dy in the y direction.
You could try limiting the values (eg 20, either positive or negative) as in this adjustment:

Code: Select all

on mouseMove x,y -- handle dragging if the user is dragging the stack
   if not tDragging then exit mouseMove
   put x - cx into tDragLengthX
   if tDragLengthX < 0 then
      put max(-20, tDragLengthX + (dx div 2)) into dx
   else
      put min (20, tDragLengthX + (dx div 2)) into dx
   end if
   add (x - cx) to sx
   put y - cy into tDragLengthY
   if tDragLengthY < 0 then
      put max(-20, tDragLengthY + (dx div 2)) into dy
   else
      put min (20, tDragLengthY + (dx div 2)) into dy
   end if
   add (y - cy) to sy
   set the loc of this stack to sx,sy
end mouseMove

You can mess about with it in other ways but that may be a start

[bn]

Hi Jodius.maximus,

here is a quick adaption of the bounce stack.
I put the code into a button and as Sparkout did limited the speed dx to -10 to +10
Additionally I set the loc to x,y in mouseMove
if you press the command key it all stops and the button returns to 300,300 as an emergency brake.

I deleted some handlers but left some others in that don't have a function in a button script,

You would have to clean up and adapt the script to your needs.

And YES, you have to get your head around the math, what Sparkout hinted at is a beginning to understand it. It is not difficult just tedious.

Kind regards

Bernd

[bn]

Hi Jodius.Maximus,

here is a side-scroller game example with jumping and running etc

http://livecodeshare.runrev.com/stack/3 ... -Game-Test

I don't know if you have seen this.

Kind regards
Bernd

[Newbie4]

For 1)
AZSun had an interesting solution but I like Simon's better. When you intersect with the slope you back up horizontally and go up vertically. As the player continues moving horizontally, it will go up the slope. I made a quick sample of how it would work - see the attachment. (use the arrow keys to move the box to the slope, it will automatically go up the it)

With a little coding you could make it go down the slope.

If you want it to cover any shapes and direction (as in a tunnel, etc), you would need to remember the last direction moved and back it off in the opposite direction when you intersect with an object.

Have fun, it would be interesting to program and a good learning experience.

slope.livecode.zip

(1.27 KiB) Downloaded 288 times

[Simon]

I think the site I posted is great for beginners making games.
Just a little hard to find the actual link to the liveCode files.
Under "Examples of My Student Produced Games:" there is a link called "Here".
That is where all the games are, they are liveCode files so you can download them and see how they were made!

Simon

[jodius.maximusGAsngK]

SparkOut and bn: Awesome! I really appreciate the help! SparkOut's code limits the strength of the fling but doesn't address the amplified mouse movement. bn's code allows the player button to be moved 1:1 with the mouse but then when the mouse is released, the button disappears because it's moving so fast. I was trying to combine the best of both without much luck, but I realized that I don't want the player to move while the mouse is being dragged. I want the player to stay in one spot until the mouseUp/Release rather than being dragged around the screen. Needless to say, I haven't figured out how to disable the dragging of the object.
Do any of you know why the original bounce code works normally but the modified one does not? The only thing that has been changed is instead of flinging the stack around the screen, we're flinging a button around the card. Other than changing those references, the code is intact and it's basically the same idea (flinging an object and bouncing it around a container). Why/how did it get so out of whack?

Newbie4 - I like where you're going with that, but because the angular movement is hard-coded, the player can only traverse 45 degree slopes. That gave me an idea that each slope could be a separate piece/slice of the terrain with (possibly) a custom property (?) containing its slope angle which gets passed to the player object when they intersect. But that seems needlessly tedious.

Simon - I've been to that site before but this is the first time I've seen the page with the students' games. Unfortunately, as far as I can tell, none of those samples do the things I'm trying to do/having trouble with I agree that it's a good resource though. Lots of useful information.

[Newbie4]

Good ideas. Now you are starting to think like a Livecoder. That was a good idea to use custom properties to pass the angle. The programming would not be that tedious. Think of the slope as the hypotenuse of a triangle. Use a little math to calculate the length of the sides (the horizontal and vertical sides) and "move" or "set the loc..." of your character in those proportions.

Have you checked the samples contributed by other users? (In LiveCode, click on the icon labeled "User Samples" and it will take you to a decent sized library of code contributions) There are some good ideas and samples of code there. You might find something to help you.

As for the site reference by Simon (Thank you), you can also use the shortcut - URL: http://bit.ly/erhslc It has been fixed to make the links more prominent under 0-Inspiration. (and more examples will be added soon)

[SparkOut]

I had another thought about the "bouncing" button and I think it wasn't really quite what you were after. I'm still not absolutely sure, but I thought I would go back and have another look at the idea. Here is a stack with a "sprite" character who will "leap" according to the strength and direction of a "swipe" you make to "power up" the leap. The physics in there is quite pseudo, but there is a variation in the leap arc according to the initial strength and gravity. Maybe you could play with it and see what other ideas you can use. I thought it was fun to see what approach could be taken, this way seems fairly natural. I think.

[SparkOut]

And here's another little play stack with a simplistic method of ground detection. It uses a duplicate player sprite image "mask" with blend level set to 100% to test the intersect with objects in the ground group. If there is an intersect, then the position is adjusted and tested again, so the real sprite doesn't get to jump "into" the ground. Once the position is set, the real sprite has its location adjusted to match. There's a separate test to see if the sprite lands in the "lava" and if so "Game Over".

(Background graphics stolen from Malte's parallax sample http://forums.runrev.com/phpBB2/viewtop ... 1266#p1266
Sprite stolen from internet)