ldtk icon indicating copy to clipboard operation
ldtk copied to clipboard

[Suggestions/Questions] Would love to switch over to LDtk full time, but I'm having issues solving some workflow problems with the current feature set

Open FaultyFunctions opened this issue 2 years ago • 1 comments

I find myself coming back to LDtk over and over hoping I can switch over to it, but there are just some things preventing me from making the switch fully. To give context I am programming a 2D top-down zelda-like game similar to Minish Cap. There are some workflow issues that I can't come up with good solutions for when working on a project like this. Some of my issues/questions are listed below.

How would one go about the workflow of creating an overworld map/levels with different areas/biomes in LDtk?

Here is the world map for Minish Cap: Image

As you can see there are different areas/biomes with each using a different tileset. Would it be best to use different project files for each biome of the game? Is this something that would be solved with the eventual realization of the experimental "Multi-Worlds" feature?

There are two ways I can see achieving this goal of building an overworld like this.

Using one project file

If you were to use one project file, with the current feature set of LDtk, this would end up getting very cluttered. There is no real way to specify which layer belongs to a certain level. For example, if you have a ground layer, then you'd need 8 different ground layers for each biome/area. These would all show up in the layers list in the editor view. You could manually go through and check "Hide in list" option for all the layers you currently don't need, but that would be a huge pain and also it doesn't prevent the hidden layers from rendering. Obviously with the current features of LDtk, the more viable option is using multiple project files for each area/biome, though that comes with its own questions/challenges.

Proposed Solutions

  1. Add tags to layers. Then you can add an option on levels to only use layers based on tag, or exclude layers based on tag. Similar to how you exclude/only include entities from entity layers, you'd be excluding/only including layers from levels.

Using multiple project files for each area

This is the more sustainable method as far as layers is concerned (and probably performance?), but this way brings up issues with entities and enums. If we split the project into multiple projects for each area, creating layers, tilesets and all that isn't a huge issue for each project. However, you now have to copy & paste any and all entities or enums that your game systems/levels rely on. This can get to be A LOT of work. I suppose you could have a template project that you duplicate when starting a new project/world, but now if you need to add something after the fact, you need to go into each project and add that entity/enum anyway. Is there something I'm missing, or is this just what is expected?

Proposed Solutions

  1. Let us define template projects that we can import and will sync up and update projects when changes are made. For example, let's say I have some layers, entities, enums, & tilesets that I want to be in every single project. I can load up a new project and add all of those to this project. I can then use Save As Template... to save a file that only has those defined. The sole purpose of this file is for use in other LDtk project files. I can then go to my project settings on my actual project and link that template file. This will add all the layers, enums, entities & tilesets defined on the template file to my project and keep it synced up. Similar to how you can use Haxe source code to import enums, except realized to its fullest potential. These resources from the template file would be in a separated listing from the regular project resources in their respective lists/menus, but would retain all tags and options from the template project.

Why are these changes needed?

If any of the above proposed solutions are considered it would make designing and creating more complex levels/games with LDtk vastly streamlined. I work on a team and I'm the only programmer and I also build the levels, however I'm not the only one that designs the levels. Making the jobs of designers easier who might be less tech savvy is always a huge plus. LDtk already does an amazing job of that with its other features.

Just for the record, I am in favor of the proposed solution under the "Using multiple project files for each area" section. I feel like this would provide the most flexibility to designers and programmers. Although I do acknowledge that one is a lot more work.

Other Questions/Thoughts

Is there a contribution guide or is one planned? I would love to contribute to the project but have absolutely no idea what I'm doing in Haxe or how the project works/is structured.

Thanks for reading and sorry about the HUGE wall of text, I hope you can take these suggestions into consideration as I think it would really push LDtk to be unrivaled in level design tools.

FaultyFunctions avatar Apr 05 '22 15:04 FaultyFunctions

HMM someone pointed out to me that you CAN actually change the tileset PER level. It's the drop-down when you select the tile layer in the editor view. This is a huge revelation.

It would still be SUPER helpful to get some sort of template system like I mentioned or the ability to exclude/include only certain layers for specific levels, but the fact that you can change the tileset per level means that LDtk might be entirely usable for me now!

I'm going to keep this open since I feel like discussing these potential changes is still important and would be nice to see realized.

FaultyFunctions avatar Apr 05 '22 22:04 FaultyFunctions