My Sidescroller Engine starring our favorite Janitor "Eario"

[Jasoco]

NEW VERSION FOR SEPTEMBER 26TH

Side Scroller.love

(159.81 KiB) Downloaded 999 times

Alpha 2

Screen shot 2010-09-26 at 6.02.09 PM.jpg (72.47 KiB) Viewed 9717 times

I have finally done it. After brainstorming I finally discovered a Löve-friendly way to do collision detection and fake physics in a 2D side-scroller without using Box2d.

It hit me yesterday that it's easiest if I determine the x and y bounds every frame and clip the players x and y to it. This keeps the player inside an ever-changing "bounding box". The bounds (Upper, lower, left and right side) are determined every frame by checking (Ray-tracing kind of) for a solid tile until it finds one in all four directions. Then when the players position is changed, it first checks to make sure the X or Y is inside that box. If it goes out, it will be clipped and the player.x, player.y are updated to the new checked and corrected coordinates.

Confusing to explain, but it works.

It also has "on floor" detection. "On wall" detection for wall jumps. "Hit ceiling" detection for checking for solid blocks. Wall jumps aren't in place yet and the fake physics isn't perfected. Jumping is nice but not the best right now. Neither is gravity.

There is a bug though where if you land on a corner, like exactly on a corner and continue holding the direction you get stuck until you let go. I am looking for a fix, but it only happens if it's an exact landing. I will fix it. Don't worry. Another bug is slowdown of jumps if your computer slows down for a second or two. I am looking into this because it makes jumps shorter for some reason which could really be a pain. As I said, the fake physics need work, but they work!

It is a WORK IN PROGRESS. My goal is to first emulate as much of how Mario feels, then add more Mario-style feelings and other side-scroller gimmicks as time goes on. I appreciate your feedback. I want this to be usable even for "Knytt Stories" or "Cave Story" style games too. There are no enemies yet. No objects or powerups besides coins. I plan on adding powerups (To make you bigger) and enemies soon.

Oh, and by the way, the main character is Eario. Not Mario. He's the janitor of the Mushroom Kingdom and my new favorite non-cannon Mario character.

4zL3f.png (371 Bytes) Viewed 1168 times

(I made this image based on the colors on part 3 of the comic)

Without further ado, here is the demo!
[Replaced]

Here is an early shot of it with the bounding boxes drawn. Not very impressive after seeing what it is now.

Early on in the process...

Screen shot 2010-09-24 at 6.49.34 PM.jpg (35.19 KiB) Viewed 9815 times

[bartbes]

About your jumping issues, it might be useful to simulate in small fixed timesteps instead of just dt, this will make sure every part of the jump is simulated.

EDIT: Forgot something important: congrats!

[Tesselode]

Do you get to sweep under the thwomps?

Also, I think you should implement variable jumping.

[Jasoco]

About your jumping issues, it might be useful to simulate in small fixed timesteps instead of just dt, this will make sure every part of the jump is simulated.

EDIT: Forgot something important: congrats!

Thanks!! Took me forever to figure out the right method.

So how do you mean? can you give an example? I need to also make it so, like Mario, the longer I hold Jump the higher I go and the faster I am running the higher I go as well. While at the same time I want it to be like real gravity.

I don't understand why DT is being a problem though. Shouldn't DT make it so it doesn't mess up? I had thought that was the whole point of it.

On my computer I get 60FPS most of the time, but when something slows it down for a second all goes haywire with the timing.

[bartbes]

I mean something like

Code: Select all

local small_dt
do
    small_dt = math.min(0.1, dt)
    simulate_physics(small_dt)
    dt = dt - small_dt
while dt > 0

(untested, and you probably want to copy dt first)
This is because physics simulations generally work best in very small timesteps.

[vrld]

Fells really nice. Well done.

[Jasoco]

I'm working on a new jump physics engine in a separate sandbox that I will probably incorporate tonight. So far it works great.

But I'm still having the problem where if my computer does something to slow the framerate, my jumps become shortened. This shouldn't happen. That's the whole point of DT! To compensate for slowdown! I don't get it!

[bartbes]

Yes, but physics calculations are fairly inaccurate, well, wrong really, but they work for very small timesteps, so did the code I provide help?

[Jasoco]

Nope. Still slows down. Best way to test this on OS X is to have desktop pictures cycle. Whenever it does its fade, it slows the framerate. (Set it to 5 seconds to really see the problem)

This really shouldn't be happening because dt is supposed to compensate for this.

It makes the players X velocity variable smaller for some reason causing him to move slower and thusly jump shorter.

But that is the least of the problems right now and will only be a problem when you're playing a game and need to make a long jump.

I had contemplated making an arc in a table then moving the player along it like I did with my boomerang at one point in my Adventure engine, but that won't let me play right since jumps would not be controllable. They'd be on rails. So that wouldn't work. Unless I draw the arc until it hits something. Then close it and when the player reaches the end give control back. But that is too complicated and I'll figure it out later.
No.. that wouldn't work either. Since I wouldn't be able to create the arc until after I figure out the jump power, which determines how high you'll jump based on how long you keep the jump button down. Damn.

[Jasoco]

New version! Quick upload before my girlfriend comes over.

What's new now?

Moving Platforms: Three types. Horizontal, Vertical and Vertical continuous elevator.
> Horizontal moves back and forth between two points with a pause between each trip.
> Vertical behaves the same way except up and down.
> Elevator works exactly like it does in SMB. (See 1-2) The elevator will move up from the lower point to the upper point (Or vice versa) and when it reaches the end it will move to the beginning indefinitely. There is no wait unless you want one.
When the player lands on one he is attached to it until he jumps or walks off so he moves with it. I will be adding in more types later. Diagonal movement, falling platforms that wait for you to land and maybe scales and some others from later games. I hope to make ones that follow tracks eventually too like in SMB3 and SMW. (The track would be a series of points and it would move along them.)
Bugginess: 1%

Object System: The player, all enemies and all moving powerups, basically anything that needs to have collision detection and physics will be an object with its own behaviors. The player will be the first one, and everything else is after it. They will be checked against each other to detect collisions if need be. (Some items will go through things, some will collide) Hypothetically I could make a second player that you can control at the same time. Only problem is that the camera would currently only follow Player 1. So it would take work to make a NEW Super Mario Bros Wii. style gameplay. Also "Stomping" is in place. But it only pops you upward right now.
Bugginess: .5%

New, but still buggy, collision system: Still needs work. A lot of work.
Bugginess: 17%

Press G to simulate the three power-up stages. Power-ups aren't in place yet, but you can simulate it. Small Eario can't break bricks while Super Eario and Pink Eario can.

I added sound effects too to make it seem more fun while testing.

It started as a prototype but will eventually blossom into a full grown engine. I hope to see people using it for their own platformers one day. (When it's ready)

New version in first post.