ID:151757
 
So I've been messing for about three weeks or so working on a side scroller, check it out here: http://www.mediafire.com/?n2wzjn0nnoz

What I need are some tips: How would one go about determining collision with an object that is only 16x16? Also, How would one even begin to decide how slopes are made and how the player interacts with them?

Thanks for the help!
ArcaneDragonX wrote:
What I need are some tips: How would one go about determining collision with an object that is only 16x16? Also, How would one even begin to decide how slopes are made and how the player interacts with them?


1: Badass work so far.

2: Slopes: You really don't need anything to do with it. Just make them very slight slopes. :D Other than that just do the wall jumping setup.

3: As for collision... Yea I have no clue.
ArcaneDragonX wrote:
So I've been messing for about three weeks or so working on a side scroller, check it out here: http://www.mediafire.com/?n2wzjn0nnoz

What I need are some tips: How would one go about determining collision with an object that is only 16x16? Also, How would one even begin to decide how slopes are made and how the player interacts with them?

Thanks for the help!

First, as AJX said, sweet work.

Collision can be handled by using a simple bounding box set up.

If Megaman is a 32x16 pixel sprite (32 tall, 16 wide), then his bounding box would be 32x16. That means the upper left corner of the bounding box would be 32,8 and the lower left would be 0,16 (pixel_y, pixel_x format based on a 32x32 pixel tile). Collision happens when any bounding boxes overlap (I leave that part up to you; based on what you've done so far I think you can work it out with the idea as a seed).
Assuming you have it set up so that you fall when you walk off the edge of something, walking down a slope could just be a matter of letting the character fall a pixel when the slope gets lower (or more than 1 pixel if the slope is lower than -1.

As for walking up, when you collide with something you could have certain objects place you on top of them when you walk into the side of them instead of just blocking movement.

These two things combined are probably one of the easiest ways to handle going up and down stairs or hills or whatever.
ArcaneDragonX wrote:

Also, How would one even begin to decide how slopes are made and how the player interacts with them?

There's this thing called, 'physics.' May want to look that up. In this case, what you need is called a 'normal force.' That is, a force that pushes perpendicular to a surface and pushes with the same force pushed against it. As to how to slopes are made, you may have trouble with that in BYOND, (lack of pixel-based collision) and you might want to get help from the people who have tried it before.
ArcaneDragonX wrote:
So I've been messing for about three weeks or so working on a side scroller, check it out here: http://www.mediafire.com/?n2wzjn0nnoz

What I need are some tips: How would one go about determining collision with an object that is only 16x16? Also, How would one even begin to decide how slopes are made and how the player interacts with them?

Thanks for the help!

I made this a while back:
http://www.byond.com/games/CalusCoRPS/LineWalkDemo

I would not mine letting you look through the source to learn how I did it, although it is quite messy.
In response to Naokohiro (#4)
Naokohiro wrote:
There's this thing called, 'physics.' May want to look that up. In this case, what you need is called a 'normal force.' That is, a force that pushes perpendicular to a surface and pushes with the same force pushed against it. As to how to slopes are made, you may have trouble with that in BYOND, (lack of pixel-based collision) and you might want to get help from the people who have tried it before.

...I'm not sure if this was a sarcastic remark or informative. Regardless, I will treat it with respect.

As far as the physics go, the demo wouldn't work if there wasn't some module applying a force down. In this demo, the force pushing down is 2 pixels per proc cycle (0.5 seconds) until a terminal velocity of 16 pixels per proc cycle is hit while the user is falling. The formula for this works as such:

constant force (Cf) = -2 pixels
terminal velocity (Tv) = 16 pixels
falling (F) = 1 (for falling) or 0 (not falling, detected collision)
cycles while falling (Fc) = 0

vspeed = ((Cf * Fc) * F)

The formula is crude, yes, but the results are pretty good if I might say.
In response to Calus CoRPS (#5)
Believe me, mine is also messy. If you see no problem with allowing me to browse the source code, I would be very appreciative. Also, should I implement some of your code into mine, you would get credit, of course.
In response to ArcaneDragonX (#6)
ArcaneDragonX wrote:
Naokohiro wrote:
There's this thing called, 'physics.' May want to look that up. In this case, what you need is called a 'normal force.' That is, a force that pushes perpendicular to a surface and pushes with the same force pushed against it. As to how to slopes are made, you may have trouble with that in BYOND, (lack of pixel-based collision) and you might want to get help from the people who have tried it before.

...I'm not sure if this was a sarcastic remark or informative. Regardless, I will treat it with respect.

As far as the physics go, the demo wouldn't work if there wasn't some module applying a force down. In this demo, the force pushing down is 2 pixels per proc cycle (0.5 seconds) until a terminal velocity of 16 pixels per proc cycle is hit while the user is falling. The formula for this works as such:

constant force (Cf) = -2 pixels
terminal velocity (Tv) = 16 pixels
falling (F) = 1 (for falling) or 0 (not falling, detected collision)
cycles while falling (Fc) = 0

vspeed = ((Cf * Fc) * F)

The formula is crude, yes, but the results are pretty good if I might say.

Isn't vspeed always going to be 0 then? Since Fc = 0, then when you multiply Fc with Cf you'll get 0 leaving that to be multiplied with F, thus the variable returning to a "0" state.
In response to Haywire (#8)
Haywire wrote:
Isn't vspeed always going to be 0 then? Since Fc = 0, then when you multiply Fc with Cf you'll get 0 leaving that to be multiplied with F, thus the variable returning to a "0" state.

Not if something is modifying it. Fc doesn't always equal zero, the cycle checks collision with an object and then adds one per cycle while falling. Then, since this is the case, F is irrelavent and can be removed.

Like I said, the formula is crude and I'm still working on it. But thanks for pointing that out.
In response to ArcaneDragonX (#7)
ArcaneDragonX wrote:
Believe me, mine is also messy. If you see no problem with allowing me to browse the source code, I would be very appreciative. Also, should I implement some of your code into mine, you would get credit, of course.

Just add me to what ever messenger program you have, I don't want to reinstall BYOND.

ipaddict@hotmail.com

In response to Calus CoRPS (#10)
Calus == ip?
In response to Calus CoRPS (#10)
Mine is chasehoman@hotmail.com
In response to Jeff8500 (#11)
Jeff8500 wrote:
Calus == ip?

Yes.

By the way, I added you ArcaneDragonX. I'll try to remember to come online tomorrow and give you the source. Perhaps I can explain what the code does.
In response to Calus CoRPS (#13)
If I'm not on, just send it to my email. Figuring out code isn't that hard for me.