next »

[MondayHopscotch]

I've just been reading through a lot of your posts (again  ) and had another question that falls more into the nitty-gritty of your collision stuff.

I'm going to use terms from other physics engines like box2d and the like.

Static bodies (level geometry and that sort of thing) are pretty straight forward: Other bodies colliding with static bodies are 'stopped' and are able to sit against them.
Examples:

• Player hitting the ground
• Player hitting walls
• Objects resting on ground

Kinetic bodies (I believe you just refer to them as moving platforms) are similar to static geometry - they behave pretty much the same (all of the above listed interactions apply), but they have a couple special properties. Namely, the 'parenting' thing you discuss.

The part of my curiosity comes from Dynamic Bodies. This is what I'm calling all of the things like players, enemies, items, etc.

In my past projects, I've had quite the time trying to handle dynamic vs dynamic collisions. An easy example is a stack of boxes:

• 0 - Boxes in free-fall about to collide with the ground
• 1 - Box positions are predicted. Only the red box has a collision initially
• 2 - The red box collision is resolved, but this leads to a new collision between the red and blue boxes
• 3 - The blue box collision is resolved, leading to a new collision between blue and orange
• 4 - The orange box collision is resolved and now everything is good

These steps are sort of the 'ideal' or possibly 'realistic' results. I've tried tackling this in some other projects that are aimed for a more retro feel (meaning I'm not shooting for super realistic physics, but I did have some ideas that primitive multi-object collision resolution would have made for some fun mechanics) but have gotten a little stumped on how to prevent a couple weird situations. Namely, keeping bodies from being pushed through the floor / other objects. I tried having the notion of a 'finalized' state that bodies can be in once they are resolved against static geometry to keep them from being pushed back into the ground/walls/etc. That had it's limits, though.

How have you addressed this in your engine? Watching some of the animations you've uploaded and hints from various videos, it looks like you may have avoided this entirely. A good example of this is your object test image:



The spike mines don't actually seem to try to resolve, they instead "respond" to the collision by bouncing. Are there any situations where multiple dynamic objects try to come to a rest against each other? If not, how did you approach this situation and how has your choice with this influenced your level design?

[Ishi]

Hi all!

First pass Waterfalls

I'm part way through experimenting with a new mechanic - waterfalls for a mid/late game rainy level.



The water pushes things downwards and is blocked by solid objects. Bubble Leilani can float through the water though she still falls faster than normal.

Potential uses include forcing Leilani to face off against an enemy within a waterfall so she can't just jump over it - maybe she has to make better use of nearby objects and roll them into the enemy. Or by having moving platforms overhead, effectively turning the waterfall on and off, introducing a timing element.

Also thinking about trying something similar but with upwards/sideways wind, or rising hot air. For example I love the idea that destroying some blocks could allow hot air to rise through the hole and give Leilani enough lift to make a long jump.

Question

I've just been reading through a lot of your posts (again  ) and had another question that falls more into the nitty-gritty of your collision stuff.
...
How have you addressed this in your engine? Watching some of the animations you've uploaded and hints from various videos, it looks like you may have avoided this entirely. A good example of this is your object test image:



The spike mines don't actually seem to try to resolve, they instead "respond" to the collision by bouncing. Are there any situations where multiple dynamic objects try to come to a rest against each other? If not, how did you approach this situation and how has your choice with this influenced your level design?

Thanks for the questions! I intend on eventually covering this in part 4 (I think it was) of my collision system devlog posts. They took a while to write and I haven't got round to continuing yet. I can answer some brief questions on it now, though.

Non-platform objects

For small objects like the mines and coconuts in that gif, the simple answer is that I don't bother with any kind of "realistic" physics. The objects react to each other by bouncing off each other - simply settings their x/y velocity - depending on the situation. The most important factor in determining what happens when two such object collide, is deciding if one object is bouncing on top of the other, or if the two objects are nudging into the side of each other.

The objects can easily end up overlapping each other or intersecting with each other in a slightly weird way, but should never end up embedded in the static collision of the level.

In gameplay typically the number of objects is relatively limited. The aim is to have objects react to each other in a fairly predictable way, so if you kick a coconut on top of an enemy you can guess how it's going to bounce.

Moving platform objects

There are some objects which move, and are also considered platforms (they provide solid collision for other objects to rest on). I do use a parenting solution for this which does the job.

I don't think I do anything specific to handle the kind of stacking situation that you described, so I wouldn't be surprised if there's the occasional frame where they overlap each other. In gameplay terms these objects will only be stacked up or interacting in fairly controlled circumstances so it shouldn't stress the system out too much.

These objects do behave a bit more simply e.g they don't bounce when they land (a coconut hitting the floor will bounce upwards, but a crusher (see gifs below) just slams onto the floor and sticks there). This definitely helps to avoid too many complicated physics interactions in a set of stacked objects!

I became interested so I set up a couple of tests to see how it handled it. These crusher objects are essentially big platforms that move towards Leilani once she gets near to them.







Obviously there's something weird going on in that last one :D I'm not too concerned though!

[MondayHopscotch]

Once your crushers are stacked, they are sort of going through the stages of my picture each physics step (steps 0-4 were meant to be one 'step' of the physics world, not necessarily 4 separate frames).

Each physics step, the stack of crushers as a whole is trying to move downward due to gravity. (feel free to cut me off if my assumptions start drifting from how your physics engine works )

I think my sort of curiosity (and my past struggles) are that once the bottom crusher is resolved based on the ground, that should cause a new overlap between it and the next crusher above it (like step 2 in my diagram). How do you know to resolve this new collision to say "blue box (crusher on top) resolves up" as opposed to saying "red box (crusher on ground) resolves down"? In my projects, I've run into ambiguous situations where I get the wrong resolution and the bottom object gets pushed back into the ground by the objects on top of it. Your engine seems to handle it well

I have realized that I may be making some assumptions based on my physics engine attempts. They have typically behaved where if a collision is found, the collision detection/resolution loop is re-run before returning to ensure that the resolutions applied did not cause new collisions. So one call to step the physics world may run the collision logic multiple times for a given time-step. In my diagram above, 0 would be the state before stepping the physics engine, and 4 would be the result once it had returned. 1-3 would all happen internally.

As for that last gif with the strange behavior, I'm guessing it's an unintended consequence of this little drifting interaction where you push objects into the wall to allow for good feeling wall slides (note how Leilani gets slightly pulled with the block after falling off of it):



Combined with your implementation of horizontal soft collisions that you talk about in collisions part to (here https://forums.tigsource.com/index.php?topic=46289.msg1387138#msg1387138):



That's just me speculating because I'm enjoying thinking about all this stuff.

[qMopey]

Your waterfalls are great! One suggestion: once a block moves out from under a waterfall, have the water animate downwards as opposed to instantly extending to the floor. An animated fall of water will fit in very well with your animated fall when a block moves under a waterfall. The difference in each scenario, as is, is jarring.

[JobLeonard]

This somehow gave me flashbacks of Nam trying to solve the free-falling chain problem in classical mechanics.

[beetleking22]

I love the waterfall mechanics. You have so many creative ideas and they seems to work nicely. Is this your hobby project or are you working on this game full-time? Can you also tell something about your level design philosophy? Are you following the Mario design philosophy where you introduce new concept in safe environment and then later you start to establish the concept further with different challenges and twist? Or do you have your own level design philosophy?

[Ishi]

Once your crushers are stacked, they are sort of going through the stages of my picture each physics step (steps 0-4 were meant to be one 'step' of the physics world, not necessarily 4 separate frames).

Each physics step, the stack of crushers as a whole is trying to move downward due to gravity.

Yep!

I think my sort of curiosity (and my past struggles) are that once the bottom crusher is resolved based on the ground, that should cause a new overlap between it and the next crusher above it (like step 2 in my diagram). How do you know to resolve this new collision to say "blue box (crusher on top) resolves up" as opposed to saying "red box (crusher on ground) resolves down"? In my projects, I've run into ambiguous situations where I get the wrong resolution and the bottom object gets pushed back into the ground by the objects on top of it. Your engine seems to handle it well

Each crusher only does its collision resolutions once. Since they're already stacked, they form a chain where they are parented to each other, with the bottommost one not being parented to anything. There's some logic which makes the parent move and check its collisions first. So the bottommost crusher moves down due to gravity, collides with the floor and moves back up.

It doesn't care that it's now clipping into the crusher above it, because it never had any upwards velocity this frame.

The second crusher in the stack will be the next one to update, so it moves downwards and collides against the bottommost crusher, moving up. This continues up the stack until they're all neatly stacked on top of each other again.

It works for simple cases, it's not super robust as you've seen but I don't plan on stressing this code out too much in the final game. I think you're probably right that the soft corner collisions may be partly responsible for the weirdness, as it causes objects to suddenly snap to places they probably shouldn't be.

... actually I just tried turning off all the soft collisions for the crushers. It certainly seems way more stable! Thanks!

Your waterfalls are great! One suggestion: once a block moves out from under a waterfall, have the water animate downwards as opposed to instantly extending to the floor. An animated fall of water will fit in very well with your animated fall when a block moves under a waterfall. The difference in each scenario, as is, is jarring.

Thanks! Yep I need to add more polish in terms of animations and stuff, I'll show that off next weekend!

I love the waterfall mechanics. You have so many creative ideas and they seems to work nicely. Is this your hobby project or are you working on this game full-time? Can you also tell something about your level design philosophy? Are you following the Mario design philosophy where you introduce new concept in safe environment and then later you start to establish the concept further with different challenges and twist? Or do you have your own level design philosophy?

Thank you this is a hobby project.

I'm still learning when it comes to level design. I do try to find a way to teach new mechanics through the level design in a safe area. I've previously tried following that four-step level design idea quite rigidly, but I tend to hate the result if I design levels while strictly trying to structure the level. So far I've found it best to just block out a level without trying to hard - it's way easier for me to test and tweak a bad level until it turns good, than to fill a blank canvas with something good to begin with.

I hope that answers your question - my level design skills still feel lacking and I don't know if I'm very good at pushing myself to improve them, but I am confident in being able to see flaws in the level layouts and keep improving them until they're eventually good.

Maybe in the future I can try to write something about the progress of a level from initial blockout to final version, if I'm organised enough with recording gifs along the way.

[JobLeonard]

Each crusher only does its collision resolutions once. Since they're already stacked, they form a chain where they are parented to each other, with the bottommost one not being parented to anything.

I KNEW IT!

I think you're probably right that the soft corner collisions may be partly responsible for the weirdness, as it causes objects to suddenly snap to places they probably shouldn't be.

... actually I just tried turning off all the soft collisions for the crushers. It certainly seems way more stable! Thanks!

Oh so it's not an energy problem then. NVM.

(for those not in the know, if you try to solve the equations for a chain fixed at one end and do so naively, you end up predicting an insane amount of momentum in the last link as it whips around)

this is a hobby project.

Are you kidding me?!

[airman4]

Truly awesome !!! I missed this devlogs it seems , i love the graphics !

[Ishi]

this is a hobby project.

Are you kidding me?!

Well there's a reason it's been nearly 5 years in development so far it's a big hobby project that's just taking a very long time.

Truly awesome !!! I missed this devlogs it seems , i love the graphics !

Thank you!

[Ishi]

Waterfalls - Update, New Types

I've continued work on the waterfalls this week.

I've added some effects to the waterfall when it collides with something or when the flow is interrupted, so it looks a bit smoother now. The visuals should still be considered mostly placeholder though - I haven't really spent much time on the animations or effects yet. But the main thing is that they're in the game, and easy to replace in the future.

I've also added two new types of waterfall. One is lava. The other isn't really a waterfall at all, it's an updraft of air - but it's still a waterfall as far as the code is concerned

Lava



This hurts Leilani. Bubble Leilani bounces off it (this is the case with anything damaging - the bubble protects Leilani from the hit but leaves her vulnerable after).

Fire Leilani can go in the lavafall, plus it heats her up so she can launch into her fireball-roll immediately (normally it needs to be charged up by rolling a certain distance).

Updraft



The updraft makes Leilani fall more slowly, although Bubble Leilani can be lifted upwards by it.

Collision



This shows the collision effects added to the normal waterfall. The lava and updraft versions don't have their own effects yet, so they look kinda odd spawning water particles, but never mind.

Since the updraft is moving upwards, it can pass through jump-through platforms without being obstructed.

Missile



A little test to show that the different waterfall types will also affect enemies in different ways. I haven't done a lot of extensive testing of this with different enemy types yet.

[JobLeonard]

Ooooh, that last gif is

I love environmental interactions like that

[ProgramGamer]

Looking good!

For some reason, and I don't know if I've said this before, but every time I look at one of your "in development" GIFs with those square tiles I get a wave of nostalgia for Mario VS Donkey Kong on the GBA. Probably not quite what you're going for, but it still reminds me of that game.

Still very impressed at your dedication to this project btw

[Ishi]

Not too much to report this week - I've been steadily fleshing out the waterfall entities and thinking about ways to use them in levels.

Some examples of new behaviours in a gif:

• Waterfalls can be attached to moving platforms
• Waterfall can dig through soil blocks
• Water hitting lava creates floating lava rock platforms

This was all using existing mechanics. I already had a system for attaching entities to moving platforms (so things like spikes can reliably be fixed to moving platforms) - luckily this worked for waterfalls without any hassle.

The soil blocks already existed, getting waterfalls to dig through them simply required the waterfall to send the "dig" interaction to any entities beneath the water flow.

I'd also already implemented platforms that float on water, so I altered them to add a single-tile-wide version of the platform. The body of lava spawns the blocks in a similar way that something like a cannon would spawn cannonball entities (it has a pool of inactive entities to pull from that can be spawned in any position).

So this week felt quite productive, mainly thanks to re-use of existing assets and systems. I've always hoped that development of new mechanics would continue to get faster as I get through the project, maybe it's finally coming true!

[JobLeonard]

Water hitting lava creates floating lava rock platforms

Permanent, or do they melt after a while?

[Ishi]

Water hitting lava creates floating lava rock platforms

Permanent, or do they melt after a while?

Right now they're permanent, but I'm about to make them temporary on a time limit. There's a limited number of their entities available, and they despawn when they go off screen anyway, so it feels like it makes more sense to make them fully temporarily, with crumbling animation etc.

[Ishi]

Challenge mode

Development keeps ticking along, and I have a new feature to show!

Challenge levels: these are short, standalone levels, with an objective, and a medal ranking system depending how well you did. These are inspired by a similar challenge mode in New Super Mario Bros U which I enjoyed.

The levels are dressed up as a computer simulation that you can access via computer terminals the enemy has built on the island. Each challenge has a predetermined powerup to use (e.g. one level might start with the bubble powerup), and these powerups don't carry over into the rest of the game. So there are no consequences to trying and failing a challenge - no progress in the "real world" side of the game is lost.

The purpose of adding challenge mode is:

• More gameplay variety: It might be nice to take a break from the game's normal levels to try these quick, optional challenges.
• Higher (optional) difficulty: Since these levels are optional, and are quick to retry with no consequences for failure, I can make the later ones pretty much as hard as I like. So it should help to broaden the range of difficulty in the game.
• Give meaning to the chip collectables: Each level in the game has three computer chips to find, but I previously didn't have any use for these. Now they are used to unlock additional levels in the challenge simulation.
• More content, for cheap: These levels will pad the game out a bit more, but don't take much effort for me to make. Since they all have the virtual simulation idea, I can get away without having unique backgrounds or making them look fancy. It feels appropriate for them to be visually quite simple.

Enough talking, it's gif time!

Opening the challenge menu and beginning a level:



(There are just two levels in the list right now, but this will be added to later.)

Selecting a level shows a description of the goal and a little preview image.

Finishing a level:



Whether failing or succeeding at the challenge, this same UI is shown, to give the player another opportunity to look over the goal and the medal targets. It's super quick to retry - the player can skip the medal animations here if they don't care about seeing them and just want to play again.

I've added new UI at the top of the screen during gameplay, including a level timer for timer-based challenges, and a medal progress display in the middle, which shows the medal you're currently on track to achieve.

Another level:



(Note the yellow tiles in this level are placeholder art.)

At the end, because all bronze medals and all silver medals have been achieved, two more computer chips are earned. So like with normal levels, each computer terminal also has three chips to achieve. I thought it was best to give the player more computer chips for finishing a set of challenges, rather than adding a new 'currency' to indicate how many challenge terminals have been beaten.

[bynine]

that's a great idea! they should be a fun change of pace... although, completing the last simulation needs to get you something besides more chips, or you'll have nothing to use them on!!

[Ninety]

I really like the idea of the challenges, looks fun

[JobLeonard]

Challenge mode

Development keeps ticking along, and I have a new feature to show!

Challenge levels: these are short, standalone levels, with an objective, and a medal ranking system depending how well you did. These are inspired by a similar challenge mode in New Super Mario Bros U which I enjoyed.

The levels are dressed up as a computer simulation that you can access via computer terminals the enemy has built on the island. Each challenge has a predetermined powerup to use (e.g. one level might start with the bubble powerup), and these powerups don't carry over into the rest of the game. So there are no consequences to trying and failing a challenge - no progress in the "real world" side of the game is lost.

The purpose of adding challenge mode is:

• More gameplay variety: It might be nice to take a break from the game's normal levels to try these quick, optional challenges.
• Higher (optional) difficulty: Since these levels are optional, and are quick to retry with no consequences for failure, I can make the later ones pretty much as hard as I like. So it should help to broaden the range of difficulty in the game.
• Give meaning to the chip collectables: Each level in the game has three computer chips to find, but I previously didn't have any use for these. Now they are used to unlock additional levels in the challenge simulation.
• More content, for cheap: These levels will pad the game out a bit more, but don't take much effort for me to make. Since they all have the virtual simulation idea, I can get away without having unique backgrounds or making them look fancy. It feels appropriate for them to be visually quite simple.

Enough talking, it's gif time!

Opening the challenge menu and beginning a level:



(There are just two levels in the list right now, but this will be added to later.)

Selecting a level shows a description of the goal and a little preview image.

Finishing a level:



Whether failing or succeeding at the challenge, this same UI is shown, to give the player another opportunity to look over the goal and the medal targets. It's super quick to retry - the player can skip the medal animations here if they don't care about seeing them and just want to play again.

I've added new UI at the top of the screen during gameplay, including a level timer for timer-based challenges, and a medal progress display in the middle, which shows the medal you're currently on track to achieve.

Another level:



(Note the yellow tiles in this level are placeholder art.)

At the end, because all bronze medals and all silver medals have been achieved, two more computer chips are earned. So like with normal levels, each computer terminal also has three chips to achieve. I thought it was best to give the player more computer chips for finishing a set of challenges, rather than adding a new 'currency' to indicate how many challenge terminals have been beaten.

that's a great idea! they should be a fun change of pace... although, completing the last simulation needs to get you something besides more chips, or you'll have nothing to use them on!!

I really like the idea of the challenges, looks fun

EDIT: Pagination.

So basically taking a page from Super Mario World's design where finishing the "main" game is doable, finishing all the star road or equivalent levels is much, much harder. Sounds like a good idea!