Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(+1)

As long as you're planning to make SOME sort of platformer, you'd probably get some use out of this project, it's easier to remove / hide things you don't need than to make something new from scratch. The system to carry things like shells and companion cubes around seems like a nice fit for a Klonoa-style game, for instance - all you'd need to add in is a grab attack that turns enemies into "liftables" on contact, and some code that lets you jump again in mid-air if you're holding something.

Harvesting individual systems could get a bit harder, since there's a lot of dependencies between things (like the jumpthrough-platform and moving platform code being an essential part for both player, enemies and throwables since they all are affected by those platforms) so you might end up having to frankensteining a lot of unexpected code into your existing physics; it might be easier to do it in reverse (add your unique quirks into MariaEngine) depending on the scope of the projects.

(+1)

Thank you so much for the response! Considering how basic my physics are as is, I don't think it should be too hard to append my systems onto the Maria engine or vice versa, so long as it's easy to tell what's dependent on what. I do worry about the matter of scope, as you mentioned, however; I'm hoping to add on a lot of unique setpieces that would be hard for any pre made engine to account for, so I'm going to try messing around with what I've already got some more before making any purchases. Again, though, thank you!

It occured to me to ask another question - you already explained how to adapt the collision system to a larger set of sprites elsewhere, but would the engine have any issues regarding processing speeds and such with, say, a 64 X 64 sized character + 32 X 32 tiles?

(+1)

Game Maker's collisions default to rectangles that are pretty simple maths checks, and they're completely unaffected by sprite size, so this shouldn't have any noticeable effect on performance.

Alright, just one more question and then I'm done: could the system be modified to allow for slopes?

(1 edit) (+1)

It would need a bit of work, but it doesn't seem impossible. player_inertia_x already sort of supports 1-pixel slopes (to solve edge cases where you could get stuck in jump-through platforms, if I recall correctly). If you replaced this hardcoded code with a loop that checks a range of values, it'd allow for slope support. (My preferred approach is to start the loop at y+SLOPESIZE when you're on ground, y+0 when you're in mid-air, and in both cases sequentially check values until y-SLOPESIZE; this lets you smoothly follow slopes down, but you won't get sucked down at massive speeds if you try moving left/right in the middle of a jump because the game thinks you're on an invisible slope)

Don't forget that you will also need to change the rectangle_free script so that it uses precise collisions instead of bounding box only, and give all slope objects a sprite with a precise collision mask.



As an example for how the improved inertia function would look like, here's the corresponding code from my SoulsVania engine:


(+1)

Alright, thanks again for your help! Definitely gonna buy this now, if only because your customer service is so on-point.