New Features Experiments for Enhancements

[andre-lima]

I'm working on some new features for Kontra and I'd like to put them here for discussion.

They currently solve some issues I have and I guess they could become plugins or modules in the future. We'd just need to figure out how to make them more flexible.

You guys can see a running demo here:
https://kontra-experiments.netlify.com/

And the repo is here:
https://github.com/andre-lima/kontra-experiments

Here are the experimental features developed.

Depth Sort

You can add objects to a depth sort list, and it'll take care of rendering them in order, based on a parameter.

By default, we sort by the y value. If the object is closer to the bottom of the screen, it's rendered on top of the others.

Collision Mapping

It'll get the tiles data, rows, width and height parameters and put it in an object to be used for the Raycasting feature.

Raycasting

To check if the one object has a direct line of view to another point, we can use the Ray class to cast a ray and check if it hits the collision map or a sprite. If it doesn't, we know the 2 points have a direct line.

Directional Collider

Based on an e-mail exchange with our lord and savior @straker, I created a way to check from which side a collision occurred.

Since I check this by having a "thin" sensor object stuck to each side of the object, I had issues where the object would enter a little bit inside the wall, making 3 of the sensors touch the wall at the same time.

The size parameter is used to avoid the object being stuck in a wall. By testing, I found that if the size value is the same as the speed the object is moving, we don't have this issue.

Helper functions

Used to configure the canvas and do some vector math.

Log Dashboard (WIP)

A way to log quickly changing values without freezing your browser.

[straker]

Lot of awesome stuff here! I know depth sorting has been asked for a few times (#94). I'll take an in depth look at the code over the holiday break.

[andre-lima]

Awesome. Let me know if something is not clear and I'll try to explain my implementation a bit better.

[wini3d]

Thanks for this. Yes, this is awesome and it covers a lot of game features.

Would you by any chance know how to add or implement a tile based movement for this experiment or as new feature?

https://haxeflixel.com/demos/GridMovement/

[andre-lima]

It should be straight forward to translate their grid movement controller ( https://github.com/HaxeFlixel/flixel-demos/blob/master/Input/GridMovement/source/Player.hx ) to Kontra, and put it in place of the current controller code.

I can try to do it when I have some time next week, unless you beat me to it.

[wini3d]

Thanks. Can the directional collider code be also applied on moving objects like entity on entity?

Ideally I was hoping that the grid based movement will include NPCs and without overlapping the entities or stop on collision as I mentioned.

[andre-lima]

The current implementation only allows collisions with a tile layer, but it shouldn't be too hard to make it work with other objects.

I'm adding this to my todo list.

[wini3d]

Thanks @andre-lima. I am also hoping for a javascript version that I can edit and not using or scrambled by tsc. Any tips on how to do/convert this with your helpersand js scripts? or just wait for the javascript version since you are proposing these features for inclusion.

[andre-lima]

To update to JS, remove all protected/public/private variable declarations and put them in the classes constructor.

public body;
constructor() {}

becomes:

constructor() {
    this.body = 123;
}

Whenever you see a type marking, remove it.
let body: Sprite; becomes let body;

Then rename your files to .js and that should be enough.

If you get some errors, check the console and debug and let us know what worked so the next guy can check it out too.

[wini3d]

I have not tried it yet, but thank you for this!

[andre-lima]

@wini3d I just pushed to master the implementation for the grid movement. Check the snapped.ts file.
It didn't work very well with the Controller interface and the collider, but it's a first step.

Here's the link again. Use WASD to move the yellow square.
https://kontra-experiments.netlify.com/

[wini3d]

@andre-lima This is awesome and smooth!

It didn't work very well with the Controller interface and the collider, but it's a first step.

I see that, but it is a great step! It would be a great addition to the engine once these issues are fixed.

I would assume the grid base system has its own simple collision checking and just check only 4 directions which only depends on where the next player or entity move is.

btw, I didn't notice any issue with the controls, so curious what is the problem with the Controller interface.

[wini3d]

earlier I stumbled upon this pseudocode related to collision checking between moving objects and also static entities.

https://stackoverflow.com/questions/36505567/xna-tile-based-game-checking-collision-between-2-objects-using-their-grid-posit/36506354#36506354

just thought this might be useful or as reference.

[straker]

Alright, so I've had some time to look over this and here are my thoughts:

• z-ordering: super simple to implement, and now that I have scenes into v7 I could add this as a helper function you can use to sort the children of a scene.
• directional collider: calculating the direction of a collision is pretty hard (as you found out if the sprite moves too far into the wall in a single step). I tried doing it for my Arkanoid game and I could never correctly determine which side of the block the ball hit. I ended up using something in the Phaser library that look good enough but that I didn't understand how they calculated it. Another problem we'll have is rotation of sprites and trying to determine side of collision (which I forgo trying to calculate at all and leave it to the user to implement). Because of these issues I'm not sure this is something I want to bring into the library as is.
• raycasting: awesome to see it working. I'm curious if you considered making the Ray a Vector itself. We could add magnitude/size function to Vector and that would get you all the information you needed for direction (x,y) and length, then just use the collision checker part. The lineStep is an interesting problem. I'm also wondering if we would need to make it work outside of a TileEngine. I'm not sure what you'd use it for, but as is it's restricted to TileEngines only.

[andre-lima]

The ray is defined by 2 points that could be represented as Kontra Vectors, but aren't right now.
The helper/index.ts and ray.ts files have direction and length functions, but it would make sense to use kontra vectors if they had these already.
Ray collision with Sprites are possible with the collidesWithSprite method.

I'm currently starting a simple rpg with Kontra, and I'll start bringing everything I need from the Experiments project to the new one. While doing this, i'll do some refactoring.

[straker]

I just added direction and length to Vector for v7.

[andre-lima]

Nice. Lot's of new features coming in v7 apparently. Would we also get TS typings with it?

[straker]

Yep! https://github.com/straker/kontra/blob/v7/kontra.d.ts

[wini3d]

Hey @andre-lima any updates on the grid movement controller and collider?

[andre-lima]

Nope. Sorry, but I won't have the time to work on it for a while.