2D collisions for adventure games

Blitz3D Forums/Blitz3D Programming/2D collisions for adventure games

ErikT(Posted 2006) [#1]
Anyone know a good way to set up a collision system for 2D stillscenes Monkey Island style? I have no idea where to even start with this, how did they do it in the old days? 3D commands are no good, I have a collision system with invisible 3D objects already and it works fine but for several reasons I can't really use it.

EDIT: Oops, wrong forum. Any moderators up for moving this to beginners area?


Sir Gak(Posted 2006) [#2]
I don't know the answer directly, but I definitely enjoyed playing The Secret of Monkey Island. One thing I recall, is that there was z-ordering, meaning that some scenery was behind Guybrush Threepwood (cool name, huh?), and some was in front of him. Therefore, even though the graphics appeared to be all one piece, they were in fact different graphic images that were layered onto the screen. As far as considering where he could walk, hmm, I could speculate, but I think I'll see if anyone else can speak more accurately and knowedgably to the question.

Ahh, what the heck, I'll speculate anyway!

One hint I see, is that Gurbrush's movements were at least in part pre-programmed. By this, I mean, that you picked a destination, and then he was animated to walk over to that spot, following whatever path the programmers has deemed would be appropriate to the game and scene of that moment. So, maybe there are lists of coordinates/animations that were run through to get you from point A to Point B. Remember when you used the rubber chicken with a pulley on the rope, and rode across the way hanging on for dear life?. You weren't given the choice of stopping halfway through, so it was a pre-programmed sequence/animation.

Anyone else care to comment or explain? Thanks.


MCP(Posted 2006) [#3]
I seem to remember using an editor designed to create these type of games back in the early 90's. I can't remember what it was called though!
Anyway the system it employed there was simply the user drag dropped a series of rectangles over the 2d picture representing the location. Each rectangle was a collision zone which you could specify what type of action the player or object could do ie: if player character is in zone 1 then move only left/right, if in zone 2 move only up/down. Zones could be linked together allowing the player character to walk around a table for instance. Therefore the problem can be solved by simple 2d collision boxes, even though the environment was psuedo 3d - depth sorted. Hope that helps :)


SoggyP(Posted 2006) [#4]
Hello.

The use of z-ordering and placement of objects is important. You should have the background image and then have objects on top of that z-ordered so you can move in front of/behind them.

Ideally predefined paths on each screen should be used. Admittedly, this restricts free movement by the player but clever screen design should overcome that. Along that path have waypoints/collision zones that will move the players z-order so that at certain points they will move behind scenery/objects.

The system is quite easy to set up and if I was at home right now I'd throw something together for you, but alas not. So you'll have to do it yourself.

Goodbye.


Sir Gak(Posted 2006) [#5]
SoggyP: Well, when you DO get home, go for it! :)


ErikT(Posted 2006) [#6]
The system is quite easy to set up and if I was at home right now I'd throw something together for you, but alas not. So you'll have to do it yourself.

Oooh, how about a bit of pseudo-code to get me started :) Problem for me is setting up collision zones/borders using no 3D, just intricate mathematic formulas. Ahh who am I kidding, it's all way over my head :) But that's probably the one part I could never figure out by myself.

Thanks everyone for helping! I needed some fresh takes on this, yesterday my mind was completely blank.


Sledge(Posted 2006) [#7]

Problem for me is setting up collision zones/borders using no 3D, just intricate mathematic formulas



Why do you need maths? RectsOverlap, ImageRectOverlap, ImageRectCollide, ImagesOverlap and ImagesCollide should suffice.


Jaime(Posted 2006) [#8]
You don't really need to be so complicated... In golden age adventures there was only plane where the character was... So really you only have to worry by z-order (and not so often because usually the char stops just beside the item) and using the correct animation.

The paths began to be noticeable in Monkey Island 3 days, where the scenery was more complicated... mmm.. If I remember well, old days 2D collision was triggered by colors, so, if the path sides have a color 234,23,16 you make your char to not cross over that one, just go a couple of pixels away and continue walking.

btw, there's still a Adventure editor, it's named "Adventure Game Studio"; it isn't a language, it's a point'n'click object editor, but many ppl use it... There are lots of ready games there.


ErikT(Posted 2006) [#9]
Why do you need maths? RectsOverlap, ImageRectOverlap, ImageRectCollide, ImagesOverlap and ImagesCollide should suffice.

Well.. that's an excellent point you know. I can't use those commands since I'm using SpriteCandy but that lib has similar commands which I for some reason managed to completely overlook. Think I need a vitamine injection or something cause my brain's obviously not working right these days. Thanks for the heads up, I should be able to figure out something good now.


SoggyP(Posted 2006) [#10]
Hello.

Sorry, I spent time with a large breasted beauty last night so didn't have time to do this, so here's a rough outline thrown together at lunchtime. Any comments welcome:
' Set up Waypoints
- For each screen, carrying out the following process will give us the ability to move on predefined paths and search for the quickest (step-wise as opposed to distance-wise) path from one waypoint to another.  I’d suggest that a screen designer might be useful here :o)
- Define Waypoints, ie, junctions on paths
- Define Waypoint links (ie, which waypoints link to which others).  This will provide vectors/step size between the points, eg:
    A->B = (0.5, -0.25)
    B->C = (0.1, -5)
    Automatically generate reverse links as well here, eg, B->A = (-0.5, 0.25).
- Define Available paths through points, eg, 
    A->B->E->F
    A->M
    B->N->O->K
-Automatically generate reverse paths as well here.
    The paths can be stored as strings so you’d have ABEF and AM and BNOK, and in reverse FEBA, AM and KONB.
' Set up Collision Points
- For each screen you’ll want to have objects to move in front of / behind.  The waypoint system allows you to move around the screen, the collision points will be where the player interacts with objects.
- Each collision object will have a front and back position, and a y-pos switch position.  As the player moves along the path, if they collide with this point, the player y-pos and the switch position are compared and the players z-position determined through this.

'Main Loop
Repeat
cls
DoPlayer()

'Draw Stuff on screen
DrawBackgroundImage()

For each object
	If object.z > player.z then 
DrawObject()
	Else
		If Player is not drawn
			DrawPlayer()
		Else
			DrawObject()
		End if
	End if
Next

DrawHUD()
DrawCursor()

Flip
Forever

Function DoPlayer()
If mouseclicked()
    Get closest waypoint to cursor position
    Search through waypoint pathlist for quickest path from current position to selected position
    Set Moving flag to true
End if

If Moving = true
    follow path, via linked waypoints, until destination waypoint reached or cursor position reached
    For each CollisionPoint
      If playercollides
         If player.oldy > player.newy then
           player.z = collisionpoint.frontposition
         else
           player.z = collisionpoint.backposition
         end if
         break;
      end if
next
If destination reached set moving = false
End if
End function

Or something like that anyway :o)

Goodbye.


ErikT(Posted 2006) [#11]
Aha! Thanks a lot for taking the time away from the women and whatnot :] Looks like I can figure it out from here.


SoggyP(Posted 2006) [#12]
Hello.

Cool, let me know how it goes.

Goodbye.


Joestick(Posted 2006) [#13]
Monkey island is made with a Sierre Enginie(i don´t remenber the name) but it´s versy simple.
3 images compound the cenary:
1st - Collision image whith a mask color where the player can
walk.
2st - The cenery(1) image(draw above the player)
3st - The cenary(2) image(draw up the player)


Snader(Posted 2006) [#14]
Monkey Island is based on the SCUMM engine. Nothing to do with Sierra!! Take a look at http://www.scummvm.org, it's all there.

Play around with http://www.adventuregamestudio.co.uk/ for a while before starting your own blitz adventure game. It can give you some pretty good ideas. You probably also want to check out http://www.mixnmojo.com/ forums. You can ask there about how adventure games like MI where contructed, the people there are probably very willing to help you.