LÖVE

Recently, I shelved a really difficult project of mine that was getting too complicated, and decided to start something new. I finally got to use a collision library and make it actually work - in this case, it's the Tile Collision Master by Minh Ngo. Taking an ultra-prudent approach, before starting work on the actual game I made an entirely separate folder of files specifically for testing cameras and collision until I became familiar with two of the most vexing things about 2D game design for me, which for the most part is working (even if I haven't ported it out of the test yet).


The only problem is, even though the library has slopes, one way tiles, and seemingly heightmaps, the only tiles I can get to work out right are basic, completely solid, generic squares.
The title of this thread makes out like there's only one problem, but if I want to make everything I can out of the TCM I have, I'm having quite a few.

First thing I'm going to ask, and honest to all Betsies in the known universe first thing I want an answer for is: How do I use the code of "heightmaps" to create my own angle or curve for a type of slope tile? Was Minh just baiting me along when he explained heightmaps in this readme?



I've been under the impression that there is a way to create steeper slopes and even curved collideable tiles just by setting up the right surroundings and putting height values in an array like {0,1,3,4} or something. But I can't tell because I've tried numerous different syntaxes to mimic what he had in his example and it never works. I think the documentation in the readme is missing a lot of information I need to understand what I should actually do and is, frankly, unhelpful. (I have read the whole thing top to bottom twice.) The whole paragraph talking about heightmaps seems to beat around the bush about whether it's possible to "slide" across a slope when pushing into it from the top and when pushing horizontally, and to this hour I have no idea whether slopes can be slippery on more than one axis. What I mean by this is, in this "engine" I've got, when the player walks into a slope it can keep moving with only a single button still being held down while being pushed to the left or right, but for each tile type only one applicable side of arrival doesn't end in a standstill. As far as I'm concerned, it should be both or neither. Otherwise it's just inconsistent and annoying for players like myself.


(This orange slope only lets you push up against it and drift along the side when you are moving down on it.)

I'm also concerned about what happens when you walk into the flat-90 side of a slope as they are in the experiment's current state. One would basically expect that these sides would be obscured by solid blocks in the adjacent, but I'm going for a silly game here and let's be honest, I don't want to drag myself down with rules about where all slopes on the map are allowed to go. What happens is the player character basically goes right through the darned right-angled thing. This one I can probably live with. Although I wish I got why Minh Ngo put two differently coloured slopes in the library with different collision (that shouldn't even be different) but didn't even make their shapes anything other than the same.

Last thing is that there's one way tiles that are actually meant to be one way, which is good, but they're a bit buggy and one of them wasn't working at all (the blue one) until I took the strangest initiative and changed a tiny bit of code to fix it. Only thing is, I think the resulting collision (better than no collision at all, right?) is a bit janky, as the p1 square vibrates while pressing on the oppository side. Luckily, I do not necessarily need pass-through-one-way-but-then-not-return blocks, and have not made any plans yet that make use of them.

Having perfectly square, completely colliding uniform blocks is very nice, but I just can't see them comprising the entirety of the walls in all of the maps in my upcoming game, especially when my plan is about as irregular and groovy as the mock up in the picture below. Can I fix these? Am I going to make it through?

Hello.
Collisions are a hard problem... if you bodge the collision system, then you can expect all sorts of glitches.

I don't want to drag myself down with rules about where all slopes on the map are allowed to go

You most certainly should take those rules into consideration, in order to limit the scope of the problem as much as possible.
I had never even heard of this lib before and I don't want to be mean, but the code doesn't look super impressive.
Also, note that curved slopes/arches are extra hard, so you're probably going to need something more sophisticated like Box2D (possibly using chain shapes).

You mean this, right?
https://github.com/markandgo/tile-collision

It isn't called "Tile Collision Master", it's just "Tile Collision", the word master is only there because you downloaded from the default branch on github.

As for the lib's code itself, i looked at it, though i can't really form an opinion on it, since i never really coded much collision stuff before.

zorg wrote: ↑Mon Jun 26, 2017 11:29 am You mean this, right?
https://github.com/markandgo/tile-collision

It isn't called "Tile Collision Master", it's just "Tile Collision", the word master is only there because you downloaded from the default branch on github.

As for the lib's code itself, i looked at it, though i can't really form an opinion on it, since i never really coded much collision stuff before.

...Yes.
Fair enough, although in hindsight Tile Collision seems like a really poorly thought out name for a 'product' that the entirety of what it does is make tiles collide - makes it really hard to find or find information about on Google.

ivan wrote: ↑Mon Jun 26, 2017 6:03 am Also, note that curved slopes/arches are extra hard, so you're probably going to need something more sophisticated like Box2D (possibly using chain shapes).

Thanks for the input. After basically learning just now that the TC module is very unlikely to handle the range of shapes I'd like it to, I think that if I continue with my current project I really will change to Box2D for my next game, which I hope will be straightforward enough. In the meantime, I've come up with a potential purpose for one way slopes - of course in my current bird's-eye-view four directional setup it would be stupid to make do with the slopes as they are now, but that's because it's not a platformer! In a gravity-affected platformer mode, I can think of a use for both types: the horizontal colliding incline, which can be used as a slope you just walk up like stairs; and the vertical version, which can act as a slope you have no traction on and slide off like the red stairs in Slippery Climb. Although, I would feel a lot better about that if I knew how to make the top point align towards the left.

It isn't called "Tile Collision Master", it's just "Tile Collision", the word master is only there because you downloaded from the default branch

Yea, still "The Collision Master" is kind of a cool name.

really poorly thought out name for a 'product' that the entirety of what it does is make tiles collide - makes it really hard to find or find information about on Google

Not all open source code is good or even close to production quality. Personally, I upload a lot of my own code experiments on Bitbucket just as a means of backup.

Box2D is in C++? What the heck?

Yes Box2D is C++ and a physics middle ware.

But if people are talking about Box2D on the löve forums. They are essentially talking about love.physics which is using Box2D under the hood and therefore uses the same type of collision filtering and elements (Body, Fixture, Shape, World, Contact).

erasio wrote: ↑Fri Jun 30, 2017 5:59 am They are essentially talking about love.physics which is using Box2D under the hood and therefore uses the same type of collision filtering and elements (Body, Fixture, Shape, World, Contact).

Oh, sweet. Things sound much more hopeful to my ears now. Welp, time to read up on love.physics!