Issues with dividing level up into "screens" workflow

[squircledev]

My game is screen-based, meaning each room is divided up into 144x144 pixel screens. Currently there is no way to add a secondary grid which displays a 144x144 grid on top of the 16x16 tile grid besides loading my own grid image.

Essentially I'd like the option to be able to see something like this:

Except obviously much prettier, evenly spaced, and so on. Just a quick mockup

I think even a "major" grid option where every X amount of grid lines they are drawn thicker or more opaque would be good, but I'd love to have a more grid-based workflow be possible

[deepnight]

Hi,
Why not simply using the "GridVania" world layout?
You can configure it from the World panel (W shortcut) and define the level grid size as 144x144 px there.

[squircledev]

I should've brought up various issues I have with Gridvania that lead me to ignore the feature that is obviously made for this sort of thing. Sorry about that

Here is an example of what I would be using LDtk for:

(imagine the top half is area A, the bottom half is area B)

• I can't refer to points in other levels (i.e. "warp entity that has a point to X,Y in Room 0,1"). There are workarounds I've noticed now that I'm digging around the latest dev-0.10.0 (make a "WarpTarget" entity that you refer to, since cross-level entity references are allowed) so this isn't as big of a deal but I still would like it
• I want to label each area, which having large levels divided up into screens lets you do; the name of the level is how my game knows what area it's in (with Gridvania, I would have to add a Custom Value that says what area it is, or in my game I would have to manually define which levels in LDtk belong to which area)
• I want to move groups of "levels" around sometimes, which doesn't seem to be possible? In my example, if I want to move Area A below Area B, I would have to drag each and every individual level below it right? During development I do sometimes want to reposition entire areas

And so, because of those inconveniences, I went with this "just make large levels, one for each area, and then divide them up into screens" approach because it remedies all of these problems for me. The only thing that is annoying is there's no visual screen separation, which I am working around by using a graphic for it

Let me know if there's anything I can do to remedy my issues if I've missed something

[deepnight]

1. for references between levels, this is coming in 0.10 update (see Add "Entity Reference" to FieldDefs #33 and Add "Level reference" to FieldDefs #129 ), which should be available this month.
2. for area naming, I would either:

• use a naming convention for the level identifier itself (eg. myArea_x_y)
• have an "area" Enum per level to mark which area it belongs to. This approach is a little bit cleaner because you could also use the Enum colors to change level colors (new feature in 0.10.0). So it makes visually identifying levels easier.

3. Right now, there's no "selection" logic for levels, which makes moving multiple levels a bit tedious. That's something that will change in a future update.

Please note that, depending on your timing, there's a new "multiple worlds" feature coming in a future update (#231) which will basically allow what you're looking for: having levels grouped in separate worlds inside a single project file.

[squircledev]

Alrighty, I was playing around and it does seem like what you suggested (having an area enum) would be pretty convenient. I am using dev-0.10.0 right now and it seems to work fine to just label levels with area enums (especially with the colors and Area labels, and since it alerts you if the Area label is missing, it's not too inconvenient)

The lack of ability to move large groups of levels around is very inconvenient but I think the Gridvania approach would help in my case still.

However, I do think some kind of secondary / "major" grid setting would be useful, rather than a full-blown feature. Consider this case:

I think it'd be convenient if the world grid was displayed on the level as well. Perhaps a thicker line. In this case, my game would simply shift the camera to the other half of the level, and I'd like that to be visually identifiable in the editor

[deepnight]

Sure, I agree, it could be useful to just have an optional secondary grid per layers. I can add that for 0.10 :)

[deepnight]

Be careful if using 0.10 dev branch, it's not yet production ready (even if it's quite stable as of today).
Renaming of JSON values and other breaking changes might happen to maps edited using a dev branch build.

[squircledev]

Thanks, that would be neat!

And yes I figured it is not production ready. I'm fine with that! Since you said it will be available this month, I think I'll be okay. I probably won't be mapping much of anything until next month, I am just preparing my game to accept LDtk levels. Thanks for the warning though, I appreciate it

And thanks for the work on LDtk, it's awesome and I love to use it, and now that it has entity referencing in the next stable update I will definitely be using it much much more. Closing the issue as my issues have been resolved as of the current state of dev-0.10.0 + the feature request that ended up being made is now another issue :)

[deepnight]

The new extra grid feature was added for 0.10, see #558