Support for Tilemaps objects (tilesets and Tiled files)

[blurymind]

See also the card on the roadmap on Trello

If you're interested in implementing this, read the discussion so far. In particular, there are important decisions to be made about which library to use, how to integrate this in the editor and how to ensure performance.

Thanks, @4ian

below is the original post/discussion:

---

With the new ide we are still missing a very important object- the tilemap. Its important because it would help reduce the memory the game is using- allowing is to make much bigger maps. The workflow of using tilesets and tilemaps is also much nicer and is a standard for 2d games.

My proposal is to allow to import tilemaps made in tiled- since that is now an open source industry/indie standard when it comes to 2d games. Most other game engines support it too (godot,defold,phaser,unity, etc) and has a wide use in the gamedev community. https://www.mapeditor.org/ https://steemit.com/gamedev/@tensaix2j/tutorial-part-6-how-to-create-a-html5-game-using-tiled-map-editor-js-and-canvas

What's great about going this way is also that we dont have to start from scratch! Since tiled is such a popular tilemap editor and file type, it already has an implementation for pixi.js and cocos https://github.com/riebel/pixi-tiledmap https://github.com/pixijs/pixi-tilemap

NPM: https://www.npmjs.com/package/pixi-tiled https://www.npmjs.com/package/pixi-tiledmap https://www.npmjs.com/package/tiled-to-pixi https://www.npmjs.com/package/tiled-utils and many more... https://www.npmjs.com/search?q=tiled%20pixi

There are also many tiled files ready to be used for testing here: https://github.com/bjorn/tiled/tree/master/examples We can even use them in example gdevelop projects :D

Tiled exports both to json and xml btw in terms of formatting- making it great for an html5 engine. http://docs.mapeditor.org/en/stable/reference/json-map-format/

example of rendering a tiled file in phaser https://phaser.io/examples/v2/loader/load-tilemap-json

So why reinvent the wheel. This will give us the basic tilemap object inside gdevelop5 plus all the perks of being able to use tiled- an editor that has smart autotiles and many advanced features that have been developed for many years. Later on we can add ability to create and author the tilemaps inside the newIde - but with laid groundwork for how these objects are structured and the perk of having support for this industry standard

There is a bounty on this feature https://www.bountysource.com/issues/58876395-support-for-tilemaps-objects-tilesets-and-tiled-files

EDIT: 2 years later the starter of this issue ticket learned javascript and implemented it himself. Pr still pending of course :)

PR here: https://github.com/4ian/GDevelop/pull/1901

[blurymind]

found this repository, which could also be useful https://github.com/kittykatattack/tileUtilities

[4ian]

Hey 👋 I've put this issue on the roadmap (so that anyone can vote for it!) there: https://trello.com/c/vJacNvXq/65-support-for-tilemaps-objects-gdevelop-5-html5-games

I'm closing this issue as open issues on Github is now be dedicated to bugs only :) (But it's still possible to continue the discussion on this issue even if it's closed)

[blurymind]

there is a cool html5 tilemap editor here: https://github.com/less-xx/tile-map-editor but unfortunately it can not import tiled files (xml or json) it does both standard and isometric maps.

One thing that I would like to see improved upon gdevelop4 is having the tilemap editing happen inside the scene editor and not as a separate window. I found that to be a bit inconvenient in the implementation of tilemaps in gd4

[blurymind]

The developers of rpg maker mv have actually contributed a tilemap renderer to pixi.js and it is an officially in the pixi git: https://github.com/pixijs/pixi-tilemap

A potential problem of using it would be any imposed limitations/dependencies from rpg maker mv. At least for now it looks maintained - with the last update being a week ago. Rpg maker mv does have a huge userbase

[4ian]

pixi-tilemap could be interesting. Ideally we can find something that is well maintained, or at least with an implementation that have a good quality. Two things that may not be handled and so we'll have to check how to do it is:

• Collision handling.
• For really huge tilemap, we would ideally avoid to render all tiles if they are not displayed on screen.

[Lizard-13]

Zero time to work on this one, but for tiles we can store a lot of sprites in a common PIXI container or a particles container for more speed. Then always hide all the sprites/tiles but leave visible the ones in front of the camera. For extra performance, it should be possible to store the tiles in a 2D array, and map the camera top-left and bottom-right points into array indices. I did something like this in python years ago.

Also, because the permissive PIXI rendering system we can use arbitrary Z-orders for each layer in the same tilemap. I mean we can create a tilemap object with three layers, and put one layer at Z-index = -1, other at Z-index = 0 and the other at Z = 100 (instead of creating three different tilemap objects).

Finally, I like the in-scene object editors idea, An object editor should be able to define custom panels on the editor, and instances should handle clicks, drags, end clicks, etc. A lot of work but a nice long-term goal.

[4ian]

Finally, I like the in-scene object editors idea, An object editor should be able to define custom panels on the editor, and instances should handle clicks, drags, end clicks, etc.

Yep, I think it's fair :) Ideally we would have an easy to use API (not too large/not too permissive) to allow edition from the scene editor.

[blurymind]

I was trying to build a new gdevelop demo from a free set that is on itch.io - for the showreel video. But realized that the character sprites and map elements are all on tilesets. https://ansimuz.itch.io/sunnyland-woods

This made me realize how limited we are when not having this in the editor. One way this can be tackled in a lower hanging fruit kind of a way is to simply add the ability to set a visible area of a sprite object. That way what I can do from there is add a tileset importer that imports the tileset as a single resource, adds it to a number of frames, then on each frame sets the visible square area. This is how godot does both tilesets and animated sprites btw.

If the game engine side supports setting a square visible area for sprites, I can start working on adding a tileset import/cutter and a mask visible area editor to the newIDE as a first stepping stone.

[blurymind]

@4ian we can reuse the functionality of the collision masking editor to set visible area of a sprite inside a tileset. see for example how godot does this in that way, but with an area rect https://www.gamefromscratch.com/post/2015/04/28/Godot-Engine-Tutorial-Part-8-Tilemaps.aspx

If gdevelop.js allows that for sprite resources, I can create an importer for the newIde that generates the masks automatically or generates area rects. An area rect is basically just x1,y1,x2,y2

We could from there on make it so that for example the collision masking editor could optionally just let you use the visible area mask as collision bounds as well.

[blurymind]

Edit hitboxes can be repurposed to edit visible areas and expanded to be used to set the areas of a tileset like this: in the example I am setting the visible area of frame#1

by default the visible area could be the bounds of the image,unless the image is a tileset. In that case the visible area can be generated by the importer code, which sliced it

[zatsme]

To me this seems closely related to spritesheets which are also missing from GD5. Maybe this can be implemented so both tileset and spritesheets are added.

[blurymind]

I think this will be the best way to do it if we are to reuse whats already in gd5's ide.

The hitbox editor's UI can be improved too - I would like to give it more area for showing bigger images, add zoom in/out/pan.

[4ian]

The hitbox editor's UI can be improved too - I would like to give it more area for showing bigger images, add zoom in/out/pan.

Yep, that's something that is asked for a lot: https://trello.com/c/kPRc19zV/147-add-support-for-zooming-in-out-when-editing-points-hit-boxes-or-in-a-preview-of-a-sprite-in-the-sprite-editor

Feel free to give it a try :)

For using spritesheets, Pixi.js supports setting a frame/area on the texture that is displayed - this is I think the "official" Pixi.js way of using spritesheet so that would make sense to expose it in GD.

If gdevelop.js allows that for sprite resources, I can create an importer for the newIde that generates the masks automatically or generates area rects. An area rect is basically just x1,y1,x2,y2

I'm not sure how it would work, do we really need a new "Sprite Resource"? Resource should represents "physical" files that the game rely on. So a Spritesheet would be one resource (an image, like other textures), even if we can have editors to ease the selection of the areas in the spritesheets :)

[4ian]

This being said, both features of spritesheet and tileset/tilemap are relatively independent. They are in two different cards by the way on the roadmap: https://trello.com/c/dmElE214/103-support-for-spritesheet-textures https://trello.com/c/vJacNvXq/65-support-for-tilemaps-objects-tilesets-and-tiled-files-gdevelop-5-html5-games

From what I can see, people are more asking for now for tilemaps - so this would be for now a more impactful addition to GDevelop.

[blurymind]

@4ian I need to have the pixijs functionality somehow exposed to the engine right? I mean once a visible area is set in the editor, the engine itself needs to respect that too

I think that we dont need new type of resource, just the ability for the current game objects to have a visible area mask

[4ian]

I mean once a visible area is set in the editor, the engine itself needs to respect that too

Yes of course :) This is at which point you should inspect how gdjs.SpriteRuntimeObject is done to see how images are used and in particular gdjs.SpriteRuntimeObjectPixiRenderer which is responsible for creating and updating the PIXI.Sprite of the object. This is where support for displaying some area of an image should be added. For now, images are loaded using gdjs.SpriteRuntimeObjectPixiRenderer.getAnimationFrame from the image manager, but without any information about area.

I think that we dont need new type of resource, just the ability for the current game objects to have a visible area mask

Yes. Though I've just seen in Pixi.js that there is a PIXI.SpriteSheet that is a helper class that can be given a JSON (see http://pixijs.download/dev/docs/PIXI.Spritesheet.html) and load all the textures from the spritesheet (using the same base texture, i.e, the same image file): https://github.com/pixijs/pixi.js/blob/dev/src/core/textures/Spritesheet.js#L238

So maybe you were right when speaking about resources, every sprite in a spritesheet could be a different resource (we could enhance ImageResource to have not only the file, like now, but also the area). Ideally we would support importing json from TexturePacker, Shoebox or Spritesheet.js like PIXI.SpriteSheet. This could be a tool that open the JSON and create the associated resources.

If we do this, we still need to study if this will work with other objects (i.e: will a ImageResource with an area work for a TiledSprite/PanelSprite?).

[blurymind]

Interesting, the pixi spritesheet object supports loading the mask data from a json file. Thiswill be particularly useful when we want to load it from something like texturepacker

See example: atlasExample.zip

[blurymind]

Another thing I could do to approach this is to add something like https://www.npmjs.com/package/unpack-texturepacker to the editor - to allow unpacking atlases and spritesheets

and https://www.npmjs.com/package/tileset-slicer

slicing a tileset into files has two downsides:

• you are de-optimising the game
• you are creating more files

It will be the easiest way to approach importing tilesets with no need to touch the engine- just the editor

I can add this as a command to the resourcemanager if you are interested :)

[HarshRajSinghania]

Please do it as fast as possible..... It would be amazing.....

[roracle]

I am going to come in and say this is a feature I really need. Linked here is a 64bit version (Linux and Windows) of the game I've been working on in Construct 2, and I would love to be developing it in GDevelop, or even then if I end up finishing it in C2, I'd eventually like to do all my projects in GDevelop, as it's easier to keep up with.

In order for this whole system to work, I have about 5 layers of active graphics, 1 that is invisible, the bottom being the water, the topmost being anything above the player, and other layers for ground, type, and solids. Plus another for the player themselves.

I hope to see tilemap support, including painting, implemented. IF IT CAN BE DONE LIKE RPG MAKER where the main tile is your bg fill (water, for example) and you select a grass icon, and it automatically uses the 9 tiles like system to fill the edges, that would be even better.

https://drive.google.com/open?id=1LYlSTF-t2ncgbQYKD2PrzV8aWjba6ufq

[blurymind]

Rpg maker uses a concept called autotiles. It is something that also Godot already has. There are a few JavaScript implementations of autotiling I've seen before http://blog.rpgmakerweb.com/tutorials/anatomy-of-an-autotile/

On Fri, Sep 6, 2019, 6:31 PM roracle notifications@github.com wrote:

I am going to come in and say this is a feature I really need. Linked here is a 64bit version (Linux and Windows) of the game I've been working on in Construct 2, and I would love to be developing it in GDevelop, or even then if I end up finishing it in C2, I'd eventually like to do all my projects in GDevelop, as it's easier to keep up with.

I hope to see tilemap support, including painting, implemented. IF IT CAN BE DONE LIKE RPG MAKER where the main tile is your bg fill (water, for example) and you select a grass icon, and it automatically uses the 9 tiles like system to fill the edges, that would be even better.

https://drive.google.com/open?id=1LYlSTF-t2ncgbQYKD2PrzV8aWjba6ufq http://url

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/4ian/GDevelop/issues/503?email_source=notifications&email_token=ABRRWVO3TUGRWA2FBJ3TXDLQIKAVPA5CNFSM4FB4DSFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6DLXMY#issuecomment-528923571, or mute the thread https://github.com/notifications/unsubscribe-auth/ABRRWVJMR6N5IUOLJNBIOVTQIKAVPANCNFSM4FB4DSFA .

[Silver-Streak]

I see this was closed but with no note, so it may have been lack of activity.

I posted this over on trello, so I wanted to at least throw it on here too.

It looks like some folks have already done Tilemap and Tileset support for PixiJS https://github.com/pixijs/pixi-tilemap

Which may help with a lot of the work needed to implement this.

[4ian]

Yes this library is a strong contender to be the one used to implement a tilemap object.

This object is more complex than others because it needs changes in the IDE so that you can paint the map directly in the scene editor and it needs particular attention to collision handling and performance. In particular, collision handling is being slightly reworked in GD, work can start after on this object :)

[Silver-Streak]

I'd like to post a bounty on Bountysource for Tileset and Tilemap/Atlas support, It seems like this issue is the most descriptive/filled out issue GDevelop has on it.

Any chance this could be reopened so I could post the bounty, or should I post a new issue to cover it?

[4ian]

Re-opening the issue for this then :)

[Silver-Streak]

I have posted a $50 USD bounty for this on Bountysource. https://www.bountysource.com/issues/58876395-support-for-tilemaps-objects-tilesets-and-tiled-files

For anyone looking at the bounty, my biggest hopes for this are:

Really must haves:

• Full Tileset (Sprite Atlas) support. -- This would likely be through importing Tileset files from Tiled (.tsx or json export) (preferred, I think), or importing a tileset/atlas file directly and manually defining each tile (less preferred/more complicated)

• Collision handling for Tilesets. -- We would need to be able to define the collision/hitbox of each tile as needed. It should at least define basic hitboxes upon import of the tileset (Just basic square around each tile). In a perfect world it would define polygon hitboxes over each tile based off the visible pixels, but that may be asking too much. -- We should be able to add/disable behaviors for a tile just like we can for sprite based platforms. This is to ensure we can enable/disable platform behavior, as well as do thing like moving platforms/hang from ledges/etc.

• Individual tiles need to be addressable just like sprite objects. -- This would mean we should be able to address a specific instance of a tile and assign instance variables as needed.

Good to have:

• Tile Map support -- The ability to load Tiled .tmx/json tilemap files to preload maps in addition to laying them out manually in the editor. This would speed up new users migrating from other engines that already support Tiled tilemap files, and allow for easier migration between projects.
• Tile identifiers -- As mentioned in some of the related issues on Trello: https://github.com/4ian/GDevelop/issues/44 and https://github.com/4ian/GDevelop/issues/54 it would be fantastic if it was possible to test against specific instances of a tile.
• Chunk/chunk map support -- Culling is already in the engine to some extent, but having it more fully implemented as mentioned here would be beneficial: https://github.com/4ian/GDevelop/issues/381

Thanks to @4ian for reopening this, and anyone that takes a look at this ask.

[blurymind]

I think I can implement this if all the editing happens in tiled and GD5's ide just renders it and possibly anything (data wise) set in tiled's editor is exposed to the event sheet. Collision editing is all done in tiled. Game logic all done in gd's event sheet. Maps are previewed in the gd5, but not very editable in gd5. To make tilemaps or tilesets and edit them, use: https://www.mapeditor.org/

Then the approach in GD would be to to use the pixijs library to render it in the IDE+Runtime and expose its functionality to the event sheet via the jsextension api. Using a well established/official library to do that instead of writing a new one from scratch please. What we want here is a wrapper - something for the official library to interface with gdevelop https://github.com/pixijs/pixi-tilemap Using the one on pixi's git repo requires upgrading the engine to pixi5 first, so we have a blocker if that is to be used (i believe rpg maker mv uses a pixi4 branch that might be a bit outdated). Not sure how complete it is at parsing tiled files- that needs to be researched first - not all tiled functionality might be supported.

A nice touch would be to allow opening the map resources in tilded directly from gde5's electron app. All you would need to do that is run tiled's executable path + the path to the tiled file that GD is using as a resource. We can kind of already open files from within the resource manager, but it only sees specific types of files.

A more elaborate implementation of course would be to be able to edit the imported tiled file maps directly in GD5, but that would require tons more work to do

Last time we had a bounty for dragonbones if I remember right - similar to this was rewarded to @Lizard-13 , but his implementation couldnt even load the example dragonbones files and had enough issues to be taken out.

Before an award of a bounty is given, I think its pr really needs to be tested against official files and approved/awarded only if it is likely to hold up in the long term. Lets be careful this time.

I dont know if I will be able to free up time soon, so if anyone else is interested in implementing this, please dont let my interest stop you. Just let us all know in advance :)

Perhaps @Bouh might want to give it a stab?

[Silver-Streak]

I'm happy to test as needed on this.

I think using Tiled itself as the map editor is fine/valid, although I think there are still benefits to utilizing tilemaps/atlases in GD5 is SUPER beneficial from an optimization/resources standpoint. Or is that the thought process? Tiled would generate map JSON, an Atlas is added to the game resources, and it the engine uses the JSON to read/use the atlas?

[Bouh]

• Do you remember GD4 ?

• For me the most important thing is the animation on tile.

• An mostly universal file format for import/export.

• Support of layers (already existing in GD4)

• Transparency of tiles.

• Edit hitbox with polygons.

• Add instances/objects variables on specific tile.

I don't know how the engine will manage all tiles, he merge the tiles and make one unique ? Or all tiles are individual sprites, like if we add yourself sprites objects on scene?

@blurymind I would like finish what I started, I've the guidelines to continue. But first I want finish the PRs I have opened. One for "searching in comments/groups" and "change the order of the function parameters".

[Silver-Streak]

To be clear, there's no timeline on the bounty, I just wanted to give incentive for people to work on this. It seems like the most requested thing on Trello.

If I had been going on personal preference, I would have put up a bounty for Multiple Canvases instead, but this one already had so much traction here as well.

I never used GD4, so I hadn't seen this functionality before.

Overall, Tilemap Atlases (one image with all possible tiles) Is supposedly better for a engine size/performance perspective, but I don't know if that's easier/harder from a code perspective.

Agreed on universal file for import/export (I think the Tiled formats would assist with that, or maybe Tiled-formatted JSON? (https://doc.mapeditor.org/en/stable/reference/json-map-format/))

Transparency options are definitely a must if it is being built in GD5, although tiled already addresses transparency if building the map there.

But I may just be repeating what Bouh called out. Either way, thanks to anyone who works on this. :D

[blurymind]

The main goal of this issue is support for the tiled editor format. Can Gd4 use tiled files? Yes it would be nice if we can edit them in the ide like gd4, but that would be a bonus imo. Tiled is a very well funded and maintained project. It's a better editor for maps than what gd4 could do

On Thu, Jan 30, 2020, 1:25 AM Silver-Streak notifications@github.com wrote:

To be clear, there's no timeline on the bounty, I just wanted to give incentive for people to work on this. It seems like the most requested thing on Trello.

If I had been going on personal preference, I would have put up a bounty for Multiple Canvases instead, but this one already had so much traction here as well.

I never used GD4, so I hadn't seen this functionality before.

Overall, Tilemap Atlases (one image with all possible tiles) Is supposedly better for a engine size/performance perspective, but I don't know if that's easier/harder from a code perspective.

Agreed on universal file for import/export (I think the Tiled formats would assist with that, or maybe Tiled-formatted JSON? ( https://doc.mapeditor.org/en/stable/reference/json-map-format/))

Transparency options are definitely a must if it is being built in GD5, although tiled already addresses transparency if building the map there.

But I may just be repeating what Bouh called out. Either way, thanks to anyone who works on this. :D

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/4ian/GDevelop/issues/503?email_source=notifications&email_token=ABRRWVIBW5LCA3JQ2SC5AALRAIT7RA5CNFSM4FB4DSFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKJLYEA#issuecomment-580041744, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRRWVMPPDLWE2HNL7VUMA3RAIT7RANCNFSM4FB4DSFA .

[blurymind]

@Bouh here is the wiki of how to edit tilesets in tiled: https://doc.mapeditor.org/en/stable/manual/editing-tilesets/ :) it has a collision editor already

I propose to use tiled for all the tileset and tilemap editing as a start and get the data it exports to GD perfectly rendered. Then after that all works, gradually make the data editable in GD, while keeping with the file format and spec that tiled uses. That way GD might one day become an online version of tiled. People would be able to use it to prototype maps in GD and export their tiled data from GD to other engines if they want (all the other engines that can parse tiled data)

Tiled has all the stuff GD's collision editor has, but with better interface and more features. We can focus on getting the runtime features instead of recreating the interface first. Those are more valuable imo

Its good to know that the json format that is exported from tiled also contains the tileset data. A tiled file can contain many tilesets https://doc.mapeditor.org/en/stable/reference/json-map-format/

[Silver-Streak]

If we're looking at this from an approach of "backend first, GD5 direct editing second", I bet the Riebel github posted above is probably a good resource. https://github.com/riebel/pixi-tiledmap

I also found this one, which seems to take and convert tmx files into a Pixi container? It looks like the github version of the NPM one above. No idea if that's more effective/compatible or not: https://github.com/Reynau/tiled-to-pixi

Obviously, I'm not a dev anymore in life, or in regards to GD5, but reading their documentation it seems like these are the closest.

Long term I'd love the GD4 style full integrated tilemap/tileset editor, but using Tiled to manage that and still getting the json tilemap support (and sprite atlas for optimization) would still be a huge win.

[blurymind]

I am considering taking this on if nobody else picks it :) but will wait a bit to see. Might do some research over the weekend. It's getting a lot of requests

[blurymind]

Might do this next if nobody claims it before my PR here is merged https://github.com/4ian/GDevelop/pull/1408

My angle for this is that I really want to use pro-motion to make my tilemaps and tilesets and that exports tmx files. Construct and Godot both support import of tmx files, it is by far the most popular format for tilemaps and tilesets https://www.youtube.com/watch?v=KzVBk4VNgrI

I still havent decided on which library to use to parse them, but for now my focus is definitely on solely being able to load them and set them, not edit them yet. I think since this is a huge feature editing should be done as another pr.

Perhaps I should wait a bit more to see if its picked up by summer of code students first though. I really hope it is, its an awesome feature

One thing we should try and avoid is repeating the awful editing UI GD4 had for editing tilemaps. Instead of editing them inside the scene editor, you had to open this horrible modal pop up dialog

[4ian]

I think since this is a huge feature editing should be done as another pr.

Yes :)

One thing we should try and avoid is repeating the awful editing UI GD4 had for editing tilemaps. Instead of editing them inside the scene editor, you had to open this horrible modal pop up dialog

Yes, editing should be integrated in the scene editor. This means extending/refactoring/reworking the scene editor to allow extension/objects to define custom brushes/buttons on the scene editor. A super interesting project, but this might come as a later work (or a Summer of Code project).

For the implementation, it's roughly in this order:

1. I'm in favor of going for a well defined and already used format (TMX/Tiled looks nice).
2. The library for rendering them might depend on the format. Ideally something maintained or where we can contribute. If there is one that is well maintained but not supporting TMX, then better still use it but write an adaptor for this library for TMX
3. In addition to rendering, we'll have to think about efficient collisions.
4. As said previously, the edition in GDevelop can come after.

Note that Summer of Code is not starting before a bit of time (March/April). As this is a very popular request and would be very useful, I'm all for us to start working on this. If it's interesting for a GSoC student, i'm sure there will be tons of things still to do/improve there (and tons of other projects too anyway!)

[blurymind]

So a better look at the libraries https://github.com/pixijs/pixi-tilemap the one hosted on pixi is just for rendering tilemaps. It doesnt actually do any tmx file parsing

https://github.com/Reynau/tiled-to-pixi seems like a nice one, eventhough its last update was 15 months ago, the API for it appears to be freindly. It lets you build a collision layer easily, although need to look at what GD uses for collisions exactly and how to optimize it

https://github.com/riebel/pixi-tiledmap is very similar. Last updated 9 months ago.

They both use tmx-parser it seems , which is a bit old but does the job.

I wonder if we should handle parsing ourselves with tmx parser and use it with pixijs/pixi-tilemap .. or should we use one of the two that do both rendering and parsing? I want to investigate what Construct3 does for theirs, but that might be tricky since its not open source. The rpg maker mv guys are way more open, their whole js engine is open source btw

[Silver-Streak]

Just to add on for this conversation, here's a project that seems to automatically make Atlases.

I actually wonder if this could help GDevelop optimization even outside of Tilemaps/tiled sprites: https://github.com/gameofbombs/pixi-super-atlas

Edit: One more relevant project, potentially to help with changing resolutions on Tilemaps (Although reading through this, it seems like it might be beneficial for all GDevelop sprites in general and resolution changes): https://github.com/davidfig/rendersheet This one is probably more of a GSoC thing, though.

[blurymind]

Yes this is actually another separate feature for the game exporting process. Ideally we would want gdevelop to pack all resources into one or more atlases, create a json file that contains the data how to slice them, then the exported game would have much less draw calls, leading to huge optimisation gains.

The thing is that while tilesets benefit from that optimization, refactoring all the game objects to use an atlas resource is much more complicated of a refactoring than making a new tiled map object. Making one game object that uses an atlas is a nice start though.

My strategy for now is:

• Parse the tmx file format using the tmx-parser library
• Use the parsed data to render 1 pixi object using the official pixitilemap library
• Create gd collisions from the parsed data. My understanding is that the gd game engine has its own method for creation and handling of collisions which is what must be used. Once I have something rendering, I will have to figure out the collisions

On the topic of atlases: I think that in order to support them, we must either come up with some automatic export optimisation or add a proper atlast editor - similar to the one in Defold or unity. Either way that is another huge feature which can not be packed with this one imo. You would need another resource type - atlas, a way to pack images into an atlas, an atlas editor.. its a rabbit hole of stuff

[4ian]

Automatic export of resources in multiple "atlas" files (to increase rendering performance and reduce the number of files to load) is indeed both an interesting feature and a quite big one to do because you need:

• A great algorithm to smartly put the right images in the right atlas
• Rework all the object and the game engine resource manager to be able to load texture in an atlas.

Nothing impossile, in particular because Pixi already kind of support this :) But the first part might be the more difficult, especially if you want to expose controls to the user to do this.

But this is a different feature than Tilemap (let's discuss more here: https://trello.com/c/tLdGpCiD/199-bundle-images-in-a-sprite-atlas-on-export)

For tilemaps:

I wonder if we should handle parsing ourselves with tmx parser and use it with pixijs/pixi-tilemap

That's a good strategy. I would feel confident having a library that is battle tested like the one used by RPG Maker MV (which would mean it's already used by dozens of games - so hard to make it more battle tested :)). I'm not sure about how complicated it is to import/load TMX files.

For collisions, once you have a working Tilemap object, either we...

1. Stop there :) After all, we can always use invisible objects for the obstacles.
2. Implement collision. For this, your object need to redefine updateHitBoxes. This method must update this.hitBoxes, which is an array of gdjs.Polygon.

Then the game engine will take care of handling collisions. The downside is that if you create a single gdjs.Polygon for each tile, and that your tilemap is huge, this will create a looot of collision check (because your object is huge, so the game engine can't optimize and skip collision testing).

I've started working on collision optimization, but even with this having a single big object is a bit problematic.. we'll maybe think about a different approach.

[blurymind]

Rpg maker mv does not really support loading tmx files, it is however using a library that plans to add support for tmx files.

The rpg maker mv community has created an addon to load them https://github.com/Archeia/Tilemap-MV The rpg maker mv devs have a renderer that is both optimized and battle tested. Its the one that lives on pixi's repository. So my plan is to use tmx parser to parse the file's data, then feed that to the renderer (the rpg maker mv one). In that regard my tiled extension will be using two external libraries.

An alternative approach is to use a library such as https://github.com/Reynau/tiled-to-pixi which has both of those things wrapped in a single library. That option would be easier, but it wont have as strong of a support from the official pixi devs.

In terms of collision performance - tiled lets you put collisions on each tile, but it also lets you draw collision polygons directly ontop of the tilemap instead. All of that data can be fed back to gdevelop to create collision polygons. Having one big one is certainly way more performant for sure! If we had some sort of a method to detect box collisions that are next to each other and lump them into one big shape automatically, that would improve performance for the on per tile approach

[Silver-Streak]

Super excited as I read this discussion. Atlas/super atlas being a separate request makes total sense from the explanations here. And I'll throw the libraries I linked into that trello post.

Parsing tmx from tiled, rendering it as a single object (or at least as an object per layer depending on implementation), and pulling in Tiled collisions seems like an admirable effort and more than meets the minimum needs of what I was hoping for with the bounty. Thanks for the detailed discussion and effort around this.

[Wend1go]

ct:js uses "maxrects-packer" for packing the atlases, which works pretty well. Since the licenses of GD and ct:js are identical, the code might even be borrowed.

[blurymind]

@Wend1go I was sort of looking for inspiration for dragonbones at the same engine :) https://github.com/ct-js/ct-js/blob/d24d108405b1b5af359addaf3dbb4493900f042f/app/data/ct.release/res.js#L62 https://github.com/ct-js/ct-js/search?q=dragonbones&unscoped_q=dragonbones

Will obviously need to adapt the code to fit gdevelop's architecture

Going offtopic a bit, sorry

[blurymind]

Found a few more pixi libraries https://www.npmjs.com/package/pixi-tiled-utils https://codepan.net/gist/9cb3058fd8c27d346bdcc97f440a3c35

https://github.com/eXponenta/pixi-tiled

another tmx parser https://github.com/praghus/tmx-tiledmap

https://github.com/praghus/tmx-tiledmap

There are just a lot of options to investigate https://www.npmjs.com/search?q=tiled

[blurymind]

I am starting to lean toward https://github.com/riebel/pixi-tiledmap but will test more with the others

There is also this one: https://github.com/Reynau/tiled-to-pixi which has proof a concept game https://github.com/Reynau/the-game

Both support alot of features and access to all the tmx data. I am testing for animated tiles and other things from example tmx files. If anyone has example tmx files,please feel free to share :)

I like riebel's more because its in typescript and is smaller when minified (under 700-800kb). I think most of the size comes from the parser tbh

I will keep throwing tilemap examples at it and see if it breaks. So far works like a charm.

One thing to note is that each tilemap (tmx) xml file also points to an image file (usually in the same folder). You just need the tmx tilemap and the image resource. Thats it. Then the parser and the library make a neat pixi object for us that does most of the work. Its a bit like the multistyle-text-library

[4ian]

Are you sure about the "production readiness" of these? I've not looked at them but they seem not maintained anymore. Are we sure it's battle proofed?

I would rather have a first implementation that is not as feature complete but that works well rather than spending weeks fixing issues on "real" games. For example:

• do we know about the performance to show a 3000x3000 tile map? Is it possible to show more than one with good performance?
• Can we animate the tiles?
• Is there any memory leak if I use 200 of them in my game?
• Is there a good community using this library and ready to help?
• Most important questions: are there games working with this?

If not, we will have to deal with breakage and we will have to fix and maintain the library. I'm not sure we want to go this path. At least I recommend to be very cautious and have a strong rationale in case we're using an unmaintained library not used in any released game.

[blurymind]

They seem to be the best ones available atm. The one on pixis git can't parse tiled files. It's just for rendering purposes. The last update on these in 8 to 15 months ago. Looking at their source code, they arent doing anything fancy that might break

On Sun, Feb 16, 2020, 7:02 PM Florian Rival notifications@github.com wrote:

Are you sure about the "production readiness" of these? I've not looked at them but they seem not maintained anymore. Are we sure it's battle proofed?

I would rather have a first implementation that is not as feature complete but that works well rather than spending weeks fixing issues on "real" games. For example, do we know about the performance to show a 3000x3000 tile map? Is it possible to show more than one with good performance? Can we animate the tiles? Is there any memory leak if I use 200 of them in my game? Are there games working with this? If not, we will have to deal with breakage and we will have to fix and maintain the library. I'm not sure we want to go this path. At least I recommend to be very cautious and have a strong rationale in case we're using an unmaintained library not used in any released game.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/4ian/GDevelop/issues/503?email_source=notifications&email_token=ABRRWVKSAUU4W4B2SBLWPHTRDGETRA5CNFSM4FB4DSFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL4PIEY#issuecomment-586740755, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRRWVJPAXWUSQWRGT7C7SDRDGETRANCNFSM4FB4DSFA .

[Silver-Streak]

I think some of the aging is likely due to Tiled and TMX files being around for over a decade now, I believe.

If you're writing a parser not much changes are needed once you have squashed all the bugs in the parsing process, correct?

[Bouh]

What about compatibility with pixijs, knowing that we're in 4.8.6 and that it would be nice to change for a version 5 and more 🤞. I mean if this is added in next month, migration to a new version is possible?