Really cool. One question though: Do you plan on adding support for changing tiles at runtime so as to e.g. making 2D Minecraft or doing animated tiles without using sprites for it?
Also will you include ability to check if a sprite is in collision with a specific tile so I won’t have to make separate tilemap just to make spike-like obstacles?
the player should appear in front of the tree when it’s y value is higher than the tree’s and behind it if it’s lower.
That should be automatic imo. I think its how the other engines do it.
In multimedia fusion you have to use the “layer” object to get this functionality.
oh , hmm I dont know how this can be done efficiently in code. I wonder how it works out in practice. Trees would be an interesting challenge, especially when you walk behind them.I guess they will need to be split into parts. Anyways, I am glad this is being done. Having a tilemap makes a HUGE difference!
Great news : I’ve implemented the collision mask (still a simple rectangle for each tile, not customizable at the moment) and it works well with the platformer automatism.
At the beginning you can see the future tile (and collision mask) editor at the bottom-left corner of the tilemap object editor.
This demo runs at 600 fps on my computer (netbook with a good but not excellent CPU (that’s what matters the most for the collisions) ). Now I need to fix a bug : the collision mask doesn’t move with the object (still at 0;0), I thought GD moves it automatically before testing collision.
Next step : Add the possibility to make a block not collidable and modify its collision mask.
Great news! I am working on some tiles that could be used with it (plan on publishing it with public domain license so GD can be distributed with it. Because now most of art are from sites like opengameart, which is nice, but I think we could do better and make resources specially for GD.
For collisions mask, maybe you can keep it simple for you and for the user: Only have the choice between a full rectangle collision mask or 4 triangles (one for each corner if you see what I mean). (and of course a choice to have no collision mask).
I think it would be sufficient for most usage (platforms are either full, empty or cut in diagonals), and really simple to use (maybe even better than having to manually move the points of the collision mask which is quite difficult)! And it would be really very convienent to have these 5 choices if you have to change a lot of tiles.
4ian, your solution won’t accommodate all possible tilesets. See, 2.5d tilesets needs collision mask somewhere in the middle, otherwise they look weird. Not to mention slopes that aren’t 45 deg diagonals (but 30, 60 or 25 for example) which would require few tiles with slightly different collision masks, some even trapezoidal.
I think similar system to one that is used in Sprite object would be great here. It is both flexible and powerful to do any mask you want. Now that GD is open sourced, you can take a peek how editor for masks in sprite object work and use similar or even same code here.
Also what gave you idea that it would be used only for platformers? It can be just as well be used for top-down shooters like Commando. E.g. you have a rock. It doesn’t take full tile, so it doesn’t make sense using square mask. It is also big enough that making it passable make no sense as well. Also it is certainly not a triangle.
Or you have curved wall. Again, making it completely passable doesn’t make sense as well as making it completely impassable. The best you can do is make mask that fits shape of this wall well.
I think I will add buttons to set mask easily with predefined shapes but let the user modify the collision mask as he wants.
Note that the file collision mask needs to be convex.
Victor, how about adding possibility to add several mask shapes per tile, like you can do several shapes per sprite? That will make possible to do concave areas by putting several masks that complement each other, but all are convex. I think up to 3 shapes per tile would be enough.
I insist: This kind of feature is nice, but Victor should not work on it for the first version. I would even say: Victor, do not work on advanced collison mask.
We must develop this feature in a lean way:
-Have as soon as possible a minimal working object.
-Enhance it only when we get feedback about its usage.
-Prefer to do iteration, that is to say adding features in an incremental way, and above all do not build a complete but unusable feature.
The risk is to develop an object that is too complex and that nobody will use. (I’ve already made this mistake for some features inside GD!)
Really, the goal must be to have a minimal viable product that is usable as soon as possible: it’s faster, easier to develop. And then enhance it with feature that really miss.
4ian, I need to disagree with you. Virtually no people had troubles with collision masks for sprites, so same would go for tile collision masks. Also another software (Stencyl in this case) already has this “advanced collision masks” for its tilesets (although slightly differently, but not much) and nobody is complaining.
Such feature isn’t really “advanced” anyway, no more than setting masks for sprite objects are, which people using GD are actually used to and they won’t have problem with similar feature for tilesets.