supertux icon indicating copy to clipboard operation
supertux copied to clipboard

[Feature Request]: tilemap.cpp should group tiles

Open swagtoy opened this issue 1 year ago • 4 comments

Feature Details

Allows for random noise parameter rerolling, allows deleting entire sectors of tiles in the level editor with ease, allows swapping tiles. Removes burden of level editor needing to deal with autotiles. Allows moving groups of tiles, maybe optimize collision and and allow for vertice pulling (but this is kind of nothing amd i have no clue what im talking about really).

POSSIBLE: Allows manipulation of tile groups using scripts, rotation, and other cool gimmicks.

How it works is that the level editor does the autotuiling on the fly but what should happen is that shouldn't happen.

I'm happy to tackle this ,just jotting down if anyone wants to trackle it.

Feature Purpose

fsdsfsd

It will improve the gmae

Concept Screenshots

No response

Guidelines For Reporting Issues

  • [X] I have read https://github.com/SuperTux/supertux/blob/master/CONTRIBUTING.md#bug-reports.
  • [X] I have verified this isn't a request that's already been submitted as an issue.
  • [X] I have verified this isn't a discussion, or an issue with the game, but rather an actual feature request - a currently non-existent, but desired feature.
  • [X] In this request, I have only included details about one (1) desired feature.
  • [X] If I make a mistake while submitting this request, I agree to use the "Edit" feature to correct it, instead of closing this issue and opening a new one.

swagtoy avatar Oct 09 '24 07:10 swagtoy

Worth mentioning, by moving groups of tiles, or simple "pulling them" together, we have a chance to optimize the size of the file (i.e., a 16x16 group of tiles can be pulled into a single 16*16 chunk of a single block), and optimize how collision works (i.e. check collision with a "group" of tiles instead of for each tile).

There are benefits to this outside of fancy level-editing stuff, even if we aren't doing "auto-tile".

The only place where this couldn't be applied would be noise; the level editor would have to internally put "unique" tile textures over-top of each other, while keeping the 16x16 grid. This is for user-defined noise though, otherwise, we would allow for generating/re-rolling noise per level (and MAYBE even per-level-load)

When I say noise, I mean randomization of tiles, like tiles with rock chips in them.

swagtoy avatar Oct 10 '24 15:10 swagtoy

Hi! My university group is interested in implementing this feature, and we'd be happy to take it on and contribute a pull request.

Before we begin, we’d like to clarify a few things:

  • Should the tilemap grouping happen automatically during level creation, or should users be responsible for creating and managing these groups?

  • Will these groups be visible to users in any way, either in gameplay or within the level editor?
    You mentioned the editor being able to manage them (e.g., swapping, erasing), so I assume yes.
    If that's the case, perhaps users could select a completed square chunk and perform those operations — unless the game already supports that (as far as I know, it doesn’t, but feel free to correct me).

Any guidance would be appreciated so we can align our implementation with the project's expectations.

VaLLeX8 avatar May 09 '25 07:05 VaLLeX8

I'd advise you choosing a different issue. I have trouble understanding what's going on myself. Except the parameter re-rolling, I don't understand anything at all. It seems like there are actually multiple loosely related ideas, each of them being an extreme pain to implement. So unless the OP describes the idea properly (which is unlikely to happen considering their activity), I suggest this idea to be closed.

Hypernoot avatar May 09 '25 13:05 Hypernoot

All right. Thank you.

VaLLeX8 avatar May 10 '25 10:05 VaLLeX8