Collision Detection v. 2.0!! - Updated for player location

[Netjera]

In the original tutorial, I only checked collision when a falling object crossed an invisible point in the air. This functioned like having a line drawn across the frame, and no matter where the player was, once the falling object hit that line, it was automatically "collected".

This is not what we want. We want to move our player, and to have the object fall to the ground when the player is not there to collect it. This required the addition of a simple player movement routine, and a much more elaborate code section which also compared locations on the x. I've also increased the error-checking textboxes and code, in an effort to help you keep track of things. If you don't want them, omit them.

==============================================

Greetings! I'm new, but I figured out how to do something that I consider rather important, so I thought I'd post a tutorial here, so others can also benefit.

Collision Detection

I. Introduction
Collision detection is a procedure whereby your code checks to see if one object has collided, bumped against, brushed upon or otherwise invaded the space of another object. This presupposes two things:

1) That you have at least one object that is moving; and
2) That you anticipate them colliding and want something to happen when they do.

For the purposes of this tutorial, we will use two moving hotspots. One hotspot will be "falling" from the sky. The other hotspot will be set to move when we click a location on the ground. This hotspot will be the "player". The hotspots will only collide when the falling hotspot actually lands on the player hotspot. If you move the player out from under the falling object, it will land on the ground. When the hotspots collide the hotspot that fell will be disabled, to simulate the item being "collected" without it going into inventory.

Requirements: Lyberodoggy's Mobility Xtreme plugin, found here: http://www.adventuremaker.com/phpBB2/viewtopic.php?t=5492

II. Installing and Using Mobility

Mobility is an excellent plugin with many and varied uses. It allows you to move hotspots, and is customizable in many ways. One of its most important features, is being able to call movement on one hotspot from another. For example, you can move Hotspot 2 from inside Hotspot 1. Another, is the ability to run code after movement.

These two features combined will allow you to create complex movement effects. One of my favorite effects, is clicking a hotspot from inside another one, so that each moves in turn. By using a small amount of code that runs after the plugin moves the first hotspot, you can set it up so that the next hotspot moves right after the first, the third after the second, and so on.

Installing the plugin is very easy - just copy "mob_txt1.pl1" and "mob_x2_1.pl1" to AM's plugin folder.

To activate the plugin, open your project, then click "Project Properties". In the "Plugins" tab, click the check boxes next to both Mobility files. (Do this to be safe, although you may not need both checked. I've tried it with only 1 file checked, the seemingly most-recent, and gotten unpredictable results.)

III. Create Your Frame

Click "Create New Frames" and select a picture. I used "Third_Person_Game.jpg" located in the Tutorial Graphics folder of the AM directory.

IV. Create Your Hotspots

Double click to open the frame you just created.

Click and drag to create your first hotspot. When the properties window appears, click "Okay", for now, to close it. Click and drag the hotspot to move it to position (45, 6). Now right-click the hotspot and select "Properties". On the General Tab, click the radio button next to "Picture". Then click "Click here to select a file". When the dialog box appears click "Import File (Browse)" and select a picture. I used ButtonActivate.gif. This file came with the tutorials for AM, and is located inside the Tutorial Graphics folder (which should open automatically when you selected browse). Next, click the "Open" button. This hotspot will be our MOVING hotspot. It will fall upon the player. One thing you should note, is that hotspots are numbered automatically in the order they're created. Click "Okay" to close the hotspot properties.

Now click and drag to create your second hotspot. Use the steps above to position it at (33, 251) so it looks like it's sitting on the path in the picture. Then follow the given steps to select a picture. I used "Robot_01_01.gif", which is found in the "Sprites" directory. (You will have to change directories to find it.) This will be our PLAYER hotspot. It will move when we click on the ground.

Next, we will create a third hotspot to move the player within. Click and drag to create a hotspot that covers the path of the graphic. My hotspot is at position 6, 331 and spans 624x97. When the properties window opens, click "Okay". We do not need to do anything else to this hotspot for now.

V. Create Your Text Boxes

We will be creating numerous text boxes for error checking. In every case, they can be deleted in your final version, as can the matching code in the subroutines that control them (which will be clearly marked). We need EIGHT text boxes to accurately track the various locations of our hotspots and the results of their collisions. Create these text boxes in order, as they are numbered automatically in the order you create them. If they are created out of order, then the numbering in the corresponding subroutines will NOT be correct. Be careful.

The first three text boxes will monitor our Y position and determine whether we've crossed the collision point vertically. Create the textboxes by right-clicking anywhere in the frame (that isn't over a hotspot). This will bring up the text box dialog, and you will then be able to enter your text and set your font, size and color. Do not worry about the text you use as labels. These labels show up in the preview where we are working, and are there to help us identify what they're tracking. These labels do not print in the game window unless something is wrong with our subroutines. Name your textboxes as follows:

Code: Select all

1)  Position1
2)  Position2
3)  Equal?

The next five text boxes will monitor our x coordinates. Two will monitor the left and right x coordinates of our falling object. Two will monitor the left and right x coordinates of our player. The remaining textbox will track whether or not the falling object is within the boundaries of our player. Create these text boxes as above, but name them the following:

Code: Select all

4)  CornerLeftI
5)  CornerRightI
6)  CornerLeftP
7)  CornerRightP
8)  Well?   

VI. Create a Variable to Control Disabling Our Moving Hotspot

Open the properties of your moving hotspot.
Go to the "Variables" tab and check the box next to "The hotspot (or picture) must be enabled (or visible) only if..."
Click the "Add" button next to "The value of the following variables is 1..."
Click "New Integer Variable"
Name the variable "Visible" and click "OK", then click "OK" again.

This variable will be set to 0 when we want the hotspot disabled, and will be set to 1 when we want the hotspot enabled. Because it starts out with a default value of 0, we will need to set it to 1 in order to see the hotspot at the start of the game. You may not want this to be the case in your final version, but for our purposes, we want to see it moving.

In Frame Properties: Advanced, check "Execute VBScript code immediately after the frame has appeared"
In the "Enter VBScript code" box, enter the following:

Code: Select all

Visible = 1

Click "OK".

VII. Make the Moving Hotspot MOVE

Open the properties of the moving hotspot
On the Plugins tab of the hotspot, Check the box for "Move a hotspot when the hotspot is clicked" Fill in the following values:

Code: Select all

The hotspot index: Your hotspot number (We'll be using 1 today)

This is the number of the hotspot you want to move. It can be the same number as the hotspot you're activating the plugin in, or a different hotspot.

Code: Select all

Initial X Position (leave blank for current) <Leave blank>

This is the starting x position of the hotspot. You can leave it where you created it, or reset it to a different location.

Code: Select all

Initial Y Position (leave blank for current) <Leave blank>

This is the starting y position of the hotspot. You can leave it where you created it, or reset it to a different location.

Code: Select all

Step Increase in Pixels for X: 0

This is how big of a jump the hotspot will make along on x axis. In this case, we don't want it to move, because the hotspot will be falling straight down.

Code: Select all

Step Increase in Pixels for Y: 5

This is how big of a jump the hotspot will make along the y axis. In this case, we want the number small, because a big jump would look funny. The bigger the number, the farther it travels in one "step".

Code: Select all

The Right Limit of X: 640
The Left Limit of X: 0

These two boxes are the left and rightmost values on the x axis. Because AM doesn't use negative values, the left limit edge is always 0, and the right edge is 640 if your frame is 640 wide. (This is unlike cartesian coordinate systems (and better, imo), which often use negative numbers ranging from -320 to 320 to describe a space 640 wide. (I hate using math. lol))

Code: Select all

The Down Limit of Y: 480
      The Up Limit of Y: 0

These are the up and down values on the y axis. Again, affected by the fact that AM thankfully doesn't use negative values. In this case, 0 is at the top, and 480 is at the bottom, if your frame is 480 tall.

Code: Select all

The X Destination: 100
      The Y Destination: 341

Be careful when setting these values. If you have the hotspot "stepping" at all (you have a non-zero value in one of the "Step Increase" slots above), then these values will cause the hotspot to STOP at THIS location, even if your step would normally cause it to go further. The default is 100 for both. In this case, we can leave the x at 100, because our hotspot isn't moving on the x anyways. But we need to change the y to 341 (the level of our "ground" plane), otherwise, the hotspot will "hover" and never land.

Code: Select all

Time Modifier in ms: 30

This is the amount of time it takes for the plugin to move the hotspot (assumedly 1 step, although I might be wrong about that) We've set it to 30, so we have more time to move the player around.

Code: Select all

Execute some vbs after movement: <Leave blank>

This allows you to execute some vbscript after the movement starts. I do not know whether this code is executed after the movement BEGINS or ENDS, and that difference makes it impossible to check for collision here.

Click "OK".

VIII. Set the Moving Hotspot to Move on Frame Load

Open the Frame Properties window, and go to the "Advanced" tab. In the same box where we set our Visibility variable, put:

Code: Select all

Action.SimulateHotspotClick(1)

This will cause Hotspot 1 to automatically fall when the frame is loaded.

IX. Set the Player to Move

We want the player to move when we click on the ground. We want him to move to our click location, whether that's left or right. In order to do this, we need to set up the code in the hotspot we'll be clicking, not in the player hotspot. While this may seem counter to common sense, it's really the most practical way of moving the player from place to place.

Right click on Hotspot 3, which should be your "path" hotspot, and choose "Properties". Go to the "Advanced" tab, and click the box next to "When the hotspot is clicked, execute some VBScript code". In the box under where it says "Enter VBScript code:" put this:

Code: Select all

xdp = Action.GetClickPositionX
Hotspot(2).Move xdp*15

What this code does is get the position of your mouse click, and store it in the variable xdp. It then moves Hotspot 2 (the Player) to your location. Notice that we've multiplied by 15, I'll explain why in the subroutines section, below.

X. Subroutines

Now we need to set up the subroutines to check for our collision. I've liberally commented the code, in the hopes of making it more understandable.

Click "VBS Procedures (advanced)" and enter the following:

Code: Select all

Sub CompareXSpots (index)
' This subroutine compares the left and right x values of two hotspots
' If either of the x values of the falling hotspot are within the area defined by
' the left and right x values of the player hotspot, then a collision can occur

'----------------------------------
' This section sets up our corner variables
'------------------------------------------

LeftI = Hotspot(index).left
RightI = Hotspot(index).left + Hotspot(index).width ' Add the hotspot width to original left-hand point, to find the right-hand point
LeftP = Hotspot(2).left
RightP = Hotspot(2).left + Hotspot(2).width

'----------------------------------
' This is the error-checking section
' You can remove this whole section, when you no longer need it
' Make sure to remove the text boxes, too
'----------------------------------------

Text(4) = LeftI/15 ' We divide by fifteen to convert twips to pixels for easier reading
Text(5) = RightI/15
Text(6) = LeftP/15
Text(7) = RightP/15

'---------------------------------------
' This section compares our x locations
' And then runs our Y collision check, if they work
'----------------------------------------------------

' Check to see if either the left or right point of the falling hotspot is located between the left AND right points of the player hotspot
If (LeftI >= LeftP AND LeftI <= RightP) OR (RightI >= LeftP AND RightI <= RightP) Then

Text(8) = "In Bounds!" ' This changes our text flag to read "In Bounds" if the value falls in the right place.  You can remove this line of code later.  It's just for error checking.

CompareYSpots(1) ' This runs our Y collision check subroutine

End If

End Sub

sub CompareYSpots (index)
' This subroutine compares the Y values of two hotspots, one with a variable index, and the other with a static number (our player)

'---------------------------------
' This section is just to check numbers
' Use this section to make sure your hotspot is moving, and to compare it to your player location
' You can remove this whole section, when you no longer need the error-checking
'--------------------------------------

x = Hotspot(index).top
x2 = Hotspot(2).top
Text(1) = x/15
Text(2) = x2/15

'--------------------------------------
'This section compares to see If we've collided
'---------------------------------------

If Hotspot(index).top >= Hotspot(2).top then 'Compare our variable hotspot with our player.

Text(3) = "Equal"  'Print "Equal" to a textbox, just so we know once we've crossed the collision point

Visible = 0 ' Set Visible = 0 so that the hotspot will disable itself

Action.RemoveTimedEvent 1 'Remove the timed event, or it will bog down the game by continuing to run
End If


End Sub

Click "Apply", then click "OK".

Explanation: CompareXSpots runs continuously. It is called from the Hotspot Properties of the falling object. It will run every .1 second to monitor the falling hotspot location and compare it to the player location. If the locations are in line, then it will call CompareYSpots, which will check to see if we've crossed the Y line. If the hotspots are not in line, CompareYSpots will never be called.

If CompareYSpots is called, it will check to determine if we've crossed the Y threshold we've set. If we do, the hotspot will be disabled. If this subroutine is never called, the hotspot is never disabled, and the icon seemingly "lands" on the ground.

In case you're wondering, any time you see me multiply something by 15, or divide it by 15, it's because AM uses VBScript. VBScript was made by Microsoft, and they always do weird things. In this instance, their weird thing was using a unit of measure called a "twip". If you want to know more, you can go here: http://en.wikipedia.org/wiki/Twip. While we work naturally in pixels, and AM also works in pixels, the hotspot code which is generated in VBScript uses twips. Therefore, in order to check the right x locations, we must convert them to twips first. Annoyingly, this also means that you will have to convert back, in cases where you want to see pixels and not twips. For example, during our error checking. The hotspot coordinates will automatically be generated in twips, giving you odd figures like 5000. In order to see actual pixels, you must divide by 15. Incidentally, this apparently changed after VBScript 6.

XI. Calling Our Subroutines

Finally, we set our hotspot to check to see if it's in line with our player. It must be in line with the player, before we can check to see if it's colliding.

In the "Advanced" tab of our MOVING hotspot (the one calling the mobility plugin, and falling - which in our case is Hotspot 1), check the box for "When the hotspot is clicked, execute some VBScript code"

In the box that says, "Enter VBScript code" put:

Code: Select all

Action.CreateTimedEvent .1, "CompareXSpots(1)", TRUE
'The number here, must be the number of the moving hotspot, and it must be called from the properties of that same hotspot.
'Setting the event to TRUE insures it will be called repeatedly and indefinitely

Click "OK".

You might wonder why we use a timed event here. Why not use the following code?

Code: Select all

CompareXSpots(1)

Basically, VBScript in the hotspot tab is always run before the plugin fires. This means that if we used this code, our hotspot would check to see if it's collided with anything, BEFORE it is even moving. By using a timed event, and repeating it indefinitely, we can be sure that our checking routine will fire continuously while moving, and will therefore be firing when the hotspot crosses the collision point. If you find for some reason that the collision isn't being caught all the time, change the amount of time for the timed event to a smaller value.

Whatever you do, don't forget to remove your timed events. In a game where you have several objects moving and colliding with the player, having multiple collision checking timers can really bog down game speed! Remove your timers when they aren't in use!

VIII. Testing the Frame

Finally, it's time to see if our work has paid off!

Click "Test Frame (Preview)" and wait for the frame to load. You should see the icon fall towards the ground. If you remain standing under it, the icon should be collected (disappear).

Run the frame again. This time, click somewhere on the path. The player should move to your click location. If that location is not under the falling icon, the icon should land on the ground.

Simultaneously, you will notice 8 text boxes down the side of your frame. The first one will change continuously as the falling hotspot falls. The second one will stay the same, representing the player hotspot's y location. When those two are the same, the third hotspot will say "Equal". The remaining four hotspots will monitor the x changes. The first two with the "I" ending (for "index") will not change, since they represent the falling hotspot which is constant on the x axis. The second two hotspots will only change if you move the player. If the falling hotspot and the player are in line, the final textbox will read "In Bounds!"

(Remember, if you see weird numbers like 5000, you forgot to divide your twips into pixels!)

===============================================
Well, I think that's about it. I hope y'all enjoy my first foray into the world of AM tutorials, and please let me know if you have any questions or comments. It's 4am here, and it's very possible I've thrown a typo or something. lol Enjoy!

*If you want to see how it works, download the file below. I've updated the file to match the tutorial. How it works should be pretty clear.

PLEASE let me know if you find any typos, or if you test this out and something doesn't work. [/code][/u]

[ShadowHunter]

Nice job

[Netjera]

Nice job

*blushes* Thanks!

[Mystery]

Very nice tutorial Netjera

[Netjera]

Very nice tutorial Netjera

Thanks Mystery! I just followed it on the laptop and found a code typo and a couple of spots that needed clarification, so I just updated it.

[Lyberodoggy]

I see a great programmer in the making

wonderful job netjera, you upgrated my plugin's and AM's capabilities and showed that AM is not that difficult to work wonders after all

[Chromegloss55]

Great job!

A very useful tutorial.

[Netjera]

I see a great programmer in the making

wonderful job netjera, you upgrated my plugin's and AM's capabilities and showed that AM is not that difficult to work wonders after all

I don't know about that, lol. Thanks a lot!

I was a bit surprised that I couldn't make it work with Mobility X moving the player. For some reason, figuring the xdp using the click location, and then calling xdp inside the plugin tab caused weird results. =/

I couldn't have managed this without the plugin, honestly. You can't have collisions without things moving, and I doubt moving things manually would've been so nice or so easy.

Great job!

A very useful tutorial.

I appreciate that. I'm hoping people find many uses for it. (And that it's easy to adapt to multiple collisions.) =)

[Lyberodoggy]

I was a bit surprised that I couldn't make it work with Mobility X moving the player. For some reason, figuring the xdp using the click location, and then calling xdp inside the plugin tab caused weird results. =/

That's because if you 're already moving an object you can't move another one untill the first movement is finished. That's because they use the same variables to move and two lines of code try to change the same variable at the same time. I hope I can fix this with a FIFO line...

[Netjera]

I was a bit surprised that I couldn't make it work with Mobility X moving the player. For some reason, figuring the xdp using the click location, and then calling xdp inside the plugin tab caused weird results. =/

That's because if you 're already moving an object you can't move another one untill the first movement is finished. That's because they use the same variables to move and two lines of code try to change the same variable at the same time. I hope I can fix this with a FIFO line...

Hrm.. I'll have to test, but I'm pretty sure it didn't work when I only had the player in the project, and not the falling hotspot. Or am I misunderstanding what you mean by having more than one moving?

And I'm glad you mentioned this, because that's important for me to know. I need to have multiple falling objects that fall on random schedules. If I have to move things one at a time, the plugin won't work and I'll have to find another solution. hmm

[Lyberodoggy]

I will try to modify the plugin within this week, but I can't promise anything since I have some urgent projects running

[Netjera]

No rush. I'm looking at other options. I figured you wouldn't have time because you're taking finals atm, right? Or preparing for them?

[Lyberodoggy]

Just preparing for them for the time being.
However I am already designing the next version, which will include major fixes in the code and hopefully several new features such as executing some script right before movement and stoping the movement when a variable has reached some value.

As for the thingy that didn't work for you (the xdp one), it's because xdp needs to be created as a global integer.

[Netjera]

Erk. >.< I thought I did that, but who the heck knows? lol I'll retest and I'd bet, between the two of us, that your answer is more-likely to be right. lol

[mercedes]

Great tutorial!~ very well put together..

I do hope you will soon be able to share with us the card stacking one too....!~...
That will come in handy for hidden object games..[ mini games inbetween..] I thought it might be usable for where there is a hidden object underneath a hat or something..[usually a ball]-[3 hats on board]..hats move around..they stop and u pick one ....Or Around The clock solitaire..

[Netjera]

Thanks mercedes! Incidentally, a side-effect of doing collision this way, is that ground-collection is built-in. What I mean, is that if you move the player so that he isn't under the falling object, and let it fall to the ground, but you then move to the object's location, it will automatically be collected off the ground, if the hotspot is still enabled.

I discovered this accidentally. :>

As for the card deal, I'm still fighting with it. As you can see, I took a break from that game and went to this one to see if I could make progress here. The z-layer order appears to be causing a lot of problems with how the hotspots are stacking. When we get the stacks to look correct, it's difficult to track what's where, in terms of value, and the stacking is imperfect, for some reason. (If you look at my syntax thread, the last post has a picture of what's going on.) I'll be going back to it soon, if I can't solve some of the movement problems here.