Suggestions for a successor to Quick Engine?

I am tempted to create a successor to Quick Engine which would be more focused on platformers. The current Quick Engine tries to be a simple physics engine at the same time, supporting elastic collisions, friction settings, but it only makes things more complicated.

What would be your suggestions for a better platformer engine?

For example what should be handled directly by the engine (e.g. collectibles?)

How to tell to the engine which tiles of the map are "hard" and which aren't?

Should the engine handle enemies with a set of default moving patterns that could be extended?

Should the engine offer to handle jumps, double-jump, triple-jump, sliding on walls or does the programmer handle that?

Should the engine be built on top of an ECS system?

Just asking questions as they come to my mind!

Also if you want, feel free to answer with code snippets ; that is to say, show me how your code would ideally set up the engine to create your platformer with all its desired features.

To tell whether I tile is hard or not, I think there should be a list where there you can put the tiles that you can fall through, and once you jump on a platform, it checks the list if it contains that object for example,

Quick = object
 checkTile = function(map,tile_x,tile_y)
   c = maps.[map].getTile(tile_x,tile_y)
   return list.contains(c)
 end
end

Maybe tiles could have different states? "solid", "empty", "jump-through" (you can jump up through them, but they act as a platform falling down), "crumbling" (when touched, activates a cooldown that destroys the tile after some time), etc.

I like the tile states idea. Along those line (it has been mentioned before), maybe the ability to attach those as custom properties in the editor? Tick boxes? Custom properties you could define for yourself would be the cream of it ;)

For me the key thing is proper collision handling of tiles and how they impact the player movements. I have really struggled in the past to the get a player to jump up and then be able to move between 2 tiles. In particular when everything is a perfect alignment. such as 16x16 tiles - where the character (16x16) is trying to jump between a tile above and below it. There are a few algorithms out there but I get have never managed to get anything perfect working. Either the character jump is too strong and jumped past the opening, or its too slow and judders into place.

Secondly, tile properties - What type is the tile? Background only (ignore), collectible, pass through, solid, moving, dissolvable (think Manic Miner), lethal, climbable (ladder, vine) ... and so on ..

It's probably more flexible to allow a tile to have tag or function associated to it so that it can be programmed with a property.

I am of the same opinion as TinkerSmith and JmeJuniper.

The development of the new engine could be combined with the development of the MicroStudio editor. Create a new class - TileImage, TileSprite. This class would have an id field, idGroup. id - is the number of the image type it stores. idGroup - this is the number to which group belongs (air, hard).

Now, when you want to check next to which tile the character is standing, you must make conditional "if" statements for a few or a dozen types of tiles. If there was an idGroup field - you only check

player.action [tile.idGroup]. (tile.position)

action - is an array with the address of the function to be executed when contact with the given tile. For example :

• if the ladder, you can go up.
• if the rock cannot walk (collision)

The disadvantage of this solution is that you have to connect all the elements well. If you do not add a handler for a given event in the player object or add it to the wrong number, it will all fall apart.

What I described is the plugin idea I wanted to do. The plugin was supposed to generate the appropriate text placed in the file, make sure that all objects were correctly defined. Objects would be linked when run against this text. And all sprites used in TileMap would have the id, and idGroup fields added.

If you want to add a new QuickEngine functionality and you don't want to change anything in the MicroStudio editor, try adding map patrolling by opponents.

For example

1. You place a bat on the map.
2. You place L-shaped navigation points next to it (visible only during editing - on the additional tile map)
3. The bat searches according to a given pattern (eg only along straight lines, or only in a certain area) these points.
4. Goes towards the nearest.
5. After reaching the navigation point - searches for a new point (jump to the 3rd point). If there are no points in the direction in which it was moving, it may turn.

In my opinion, you should make small changes to subsequent iterations (appearing quite often). When you get a positive answer, you do a new little piece of code. As negative feedback - we wonder how to fix it.

https://en.wikipedia.org/wiki/Waterfall_model

That makes a lot of very good suggestions! Thank you all for your contributions to this discussion.

I agree that the best is to rethink the map editor together with a new platformer engine. I think the map editor needs the addition of graphical layers and 'data' layers to store all kinds of suitable information related to the game levels. Having tile properties (rather than data layers) is another idea which is interesting too. I will keep thinking about all this. If you have more suggestions or want to provide more details on your ideas, feel free to add them here, it is still time!

As a long time user of Quick engine I love the complexity and simplisity of it. But I understand and really look forward to this successor :D

I also think I can provide some awnsers to your questions:

For example what should be handled directly by the engine (e.g. collectibles?)

I think the engine should make it posibble to create things such as collectibles, but leave it to interepretation as I found out while making various platfromers with collectables.

I also think that enemies should be also left to the programmer. I haven't dealt with them personaly, but I am planning to do at some point;)

As of today I am working on a little platformer with quick engine, and double jump is one of my favorite features to add. On this topic I am also the same opinion as the ones up top.

But with the negative part out of the way(imo) :)

I love the idea of tile data! It would open posibilities and new things to try out!

I also love the current pseudo-tile data implementation that Quick engine has. Its Fun and easy to use!

But one of the most important features I would love in the new engine, would be raycasts. I have tried making my own with Quick Engine and failed :( But I might revist that task someday :)

Also Tweens are cool :D

I've made engine for my game that's based upon quick for now i have jump-thru platforms and solid wall detection i plan to release it but since those are only changes for now i feel like i ripped original creator i gave credits thou. If anyone is interested id be happy to share it.

This is a super cool idea. If I can help in any way it would be cool. what should the name for it be? maybe it could be some kind of engine that could be used in multiple things like in micro-studio but also for an easier way to make games in Python like with PYgame to Pyglit. This is a cool idea and I would like to know if you are still interested in this idea.

Have you ever heard of the game Mario Maker? It could be something like that.

Like this one? https://supermariomaker.nintendo.com/

yeah cool idea, like a more simple 2d game engine that uses micro studio for the prosesing

prosesing*

I like style coding:

sprite = new Sprite()
sprite.name = "spr0"
sprite.gravity = 10
sprite.jump(strength)
sprite.onCollide("alien", fucntion(){})
sprite.moveTo(10,10)
sprite.move(1,-1)
sprite.animate(2,true) // animation 2, with loop

something like that..

I would like an easy way to imploment obstacles such as spikes or enemies

like for example

customMapCollision(player x, player y, player height, player lenght, map, "thing you want it to collide with")

and it would return 1 if its touching the thing you want it to collide with

so should we start working on a game engine. It could be separate from microstudio even. but run on microstudio code. Like we make a app to make games that is made in microstudio or should we just start from scratch and build the app ourself?

I'm thinking we start from scratch on this game maker/engine. making it in microstudio might get too complitcated because micro studio is meant for game making not app making and something like Python's CustumTkinter might be 20x easier to use to develop a app.

I think making a game maker that has 2d collision, drag-and-drop sprites/ground and a easy programing system. and if you like the idea of making more than just a Quick engine remake and making a full game maker inspired by micro studio then just reply saying so.

@elmosballs great idea

if anyone is interested please fill out the form and i will add you to the team google drive.

Form link:https://forms.gle/nJ4rNc2pBQ6UHqA86

The progress/fuel bar isnt working as expected and i might just leave it out because the game needs to be done by Friday night and im already behind schedule. Im showing it at a Tech game/programing showcase on saturday.