Create a Tilemap Plugin

[ilexp]

Tilemaps are an incredibly easy way to create game worlds in 2D games, used in platformers, topdown games, strategy games, etc., so it might be worth considering to create an "official" tilemap implementation - especially since it has often been asked how to do this.

Some early (personal) notes on the topic as a reminder for myself:

Sorry for the bad image quality - I will transcribe the most vital information into (generally) readable text when requested or while iterating on it.

[ilexp]

Progress:

• Created a tilemap-wip branch.
• Created all required projects and maintenance infrastructure for this feature, including core and editor plugins, as well as a sample / testbed project and nuspec files.

[ilexp]

Thoughts on Tilesets

A Tileset defines a set of tiles. (Well, obviously.) This does not include any actual visuals / pixel data. All pixel data is stored in distinct Pixmap resources, which are referred to by the Tileset.

Visual Layers

A single tile can have multiple visual layers, which can be used by the renderer later as needed. Examples are {diffuse, normal, specular}, {regular, snowy, wet} or similar. The tileset doesn't care or define what to do with each layer. There is one Pixmap for each visual layer, not for each tile. A tile's visual representation always consists of the same combination of visual layer parts - think of them as the different textures in a tileset material, although their actual usage will be entirely up to the renderer.

A visual layer is configurable using the following data:

• Referenced Pixmap.
• Width / Height of a single tile in that layer. (Different resolutions for different layers when needed)
• Spacing around each tile in that layer.
• Name (friendly, human-readable)
• ID (internal)
• Filtering mode
• Data type (for storage on the GPU)

Metadata

A tileset also defines metadata about each tile. Certain kinds of metadata are fixed an required by the system, but it is important to allow users to specify their own metadata as well - for game-related code and general customization. In general, tile meta information should be stored as a struct array to streamline access and storage.

System metadata (see below for more info):

• AutoTiles
• Collision Data

Custom metadata can be added to each tile as a tag. The actual tags should be stored in a distinct array, whereas each tile just contains an index to the tag array. This allows users to easily modify tags centrally and is potentially more GC friendly as a bonus.

Collision Data

There are various ways to define collision data and integrate collision detection with Duality. The easiest way for integration would be to define collision data in the Tileset generate RigidBody shapes from the actual tilemap. This allows for physical interaction without specialized code. How should this collision data look like?

Primitive / Boolean

Each tile is either passable or not. This approach is insufficient for more complex tiles.

• Trivial
• Easy to define in an editor.
• Doesn't allow complex passability.
• Doesn't allow diagonal slopes.

Four-Direction Passability

Each tile defines passability for all of its four edges separately. This allows "corridor" tiles that allow to move in one direction, but block paths in another. It's also what RpgMaker does, to name one example. This approach is a step in the right direction, as it allows more flexibility.

• Easy to define in an editor.
• Allows complex passability
• Doesn't allow diagonal slopes.

Corner-Fill Solidify

Each tile defines whether each of its four corners is solid or not, as well as a general "fill" flag on whether the specified shape is filled or just a set of edges.

• Easy to define in an editor.
• Potentially harder to implement
• Allows complex passability
• Allows diagonal slopes.

It also allows a limited degree of collision shape interaction between tiles when their corners overlap, resulting in two adjacent near-impassable tiles joining together to form one solid impassable one.

This approach is likely to be preferred.

Vertex-Fill-Solidify

Building up on the previous approach, more vertices could be added to allow more sophisticated slopes and passability. However, this is probably too much.

• Not that easy to define for users.
• Hard to implement
• Allows complex passability
• Allows diagonal slopes and more complex geometry.

When more complex collision shapes are required, users can always tag their tiles and write a custom Component that expresses these complex shapes.

AutoTiles

The plugin should use the Extended AutoTile pattern for user convenience. Internally, each AutoTile (3x4) should be expanded into 47 distinct tiles for quick and generalized access. This affects both visual layers and collision information and can be done as an OnLoad step.

The original AutoTile block no longer needs to be included explicitly in the final expanded tileset.

As it becomes apparent when thinking about the implication of this expansion and editor support, tilesets need to think about two kinds of tiles: Conceptual tiles and actual tiles. While all permutations of an AutoTile are each an actual tile (as stored in the tilemap), they are all the same conceptual tile (as seen by the editor for user experience).

Serialization

With tilemap support in mind, it becomes even more important that the serialization of struct arrays is as efficient as possible. Check this.

[ilexp]

Progress:

• Improved support for binary serialization of value type / struct arrays. They no longer repeat redundant type information for each element, but instead derive it directly from the array's element type. Default elements can be omitted.

[ilexp]

Note: A tilemap should be configurable as to whether it should apply Z offsets (actual Z or vertex offset) to each subsequent row of tiles, and how exactly to apply them. This is required for perspectives like the one seen in typical retro RPG games, where characters and mapped objects can span multiple tiles and need to be z-sorted correctly.

See the characters being behind the palm tree - if they walked around it, they should properly appear in front of it.

There could be different modes of Z offsets, and individual tiles could allow specifying additional Z offset data, for example to adjust the Z layer of higher palm-tree tiles, so the renderer can match their Z offset with the root's and they appear on a single Z layer. How "high above the ground" a tile begins is an information that would be defined in the tileset as well, and not primarily the tilemap - although it should be considered to allow tilemaps to specify this information as well, so the same wall-tile can be "stacked" Z-correctly.

[ilexp]

Note: There probably should be some way to handle heights in a non-hacky way. See this for reference, especially the sideways stairs. All of this can certainly be done with some scripting / hacking power, but if there is a clean, generalized way to handle this, it could be part of the equation. Reconsider this later.

[ilexp]

Dialog with one of the Crosscode guys about their tilemap implementation, to get some inspiration on how to handle heights:

The above approach of allowing to specify height offsets per tileset item and per tile in a tilemap, as well as a flat / upright distinction should be enough to allow tilemap renderers to handle this with proper per-vertex Z offsets.

[hsnabn]

For collisions, you could include the primitive (boolean) collision by default, and allow users to choose any other included types as well.

Some tiles wouldn't need any other sort of collision detection logic, such as completely impassable tiles (chasms etc).

[ilexp]

For collisions, you could include the primitive (boolean) collision by default, and allow users to choose any other included types as well.

Some tiles wouldn't need any other sort of collision detection logic, such as completely impassable tiles (chasms etc).

Yep, certainly true!

The current plan of using the "Corner-Fill Solidify" approach would still allow boolean passability by simply specifying a tile to be completely solid, so this is essentially a matter of how comfortable the editor for this will be.

Since I plan a distinct Tileset / Tilemap editor, rather than relying only on the default Object Inspector editing, this shouldn't be a big problem. I'll have the workflow in mind and will try to not force users to use a more complex approach than they require.

[ilexp]

Progress:

• Added a rough first draft for a Tileset's Compile method, which transforms the specified source Pixmap data of each visual layer into internal target data to be uploaded into an internal texture. This step can later be used for AutoTile expansion, added spacing or similar OnLoad-processing.

[ilexp]

Testing Resources

Tiles with spacing: AutoTile Template: All 47 permutations of an expanded AutoTile:

• Always look at the center tile of each 3x3 quad.
• Grass tiles represent "Tiles not equal to center".
• Flower tiles represent "Don't care"

[ilexp]

Okay, so this issue has been mostly a random stream of thoughts, ideas and concepts. This needs to change, as it already becomes apparent that this will be a bigger task to do. Progress posts should use an "immediate todo" footer, so it's always clear what's next on the list and a general overview remains.

In order to generate a feedback loop during development, the first goal should be to create an operational implementation of Tilesets, Tilemaps and TilemapRenderers. This will enable test code to set up Resources and GameObjects that are directly visible in the editor and testbed. From there, new features can be added continuously.

Immediate ToDo:

• Create a first operational Tileset implementation.
  • No advanced features (AutoTiles, etc.)
  • Compile should create target textures.
  • Design an API that can be used to access all required tile data.
• Create a first operational Tilemap implementation.
  • Basic grid data, that's it.
• Create a first operational TilemapRenderer implementation.
  • Should support all basic rendering features, including rotation and proper tilemap culling.
  • Cached vertex array as usual, reasonably performant.
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.
• Implement editor support.
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
  • Tilemap editor
  • CamViewState
    • Might need to be refactored so there is no SelObj code when not required. Object Movement / Selection / Basic transformation should be an optional component. Maybe move it to a distinct class?
  • Unique docking widget and tools for tilemap editing.
    • Pen, Rect, Circle
    • As a source for drawing, both the docking widget and the actual map can be used (Tile picker)
  • Half-transparent display of all non-selected tilemaps

[ilexp]

Progress:

• Improved class / concept naming for Tileset inputs. They're no longer visual layers, but rendering inputs. This avoids the ambiguity between actual tilemap layers and different visual representations of the same tile definition.
• Tilesets now generate atlas textures during compilation and dispose them again when no longer needed.

Immediate ToDo:

• Create a first operational Tileset implementation.
  • No advanced features (AutoTiles, etc.)
  • Design an API that can be used to access all required tile data.
• Create a first operational Tilemap implementation.
  • Basic grid data, that's it.
• Create a first operational TilemapRenderer implementation.
  • Should support all basic rendering features, including rotation and proper tilemap culling.
  • Cached vertex array as usual, reasonably performant.
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.
• Implement editor support.
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
  • Tilemap editor
  • CamViewState
    • Might need to be refactored so there is no SelObj code when not required. Object Movement / Selection / Basic transformation should be an optional component. Maybe move it to a distinct class?
  • Unique docking widget and tools for tilemap editing.
    • Pen, Rect, Circle
    • As a source for drawing, both the docking widget and the actual map can be used (Tile picker)
  • Half-transparent display of all non-selected tilemaps

Tilemap API

• Since Tilemaps will be required to notify other Components about changes in their tile data, there needs to be an API that allows to track changes. Accessing grid data should be straight-forward.
• They could expose their internal grid in a public property using a new IReadOnlyGrid interface for intuitive / convenient read access.
• For modifying tile data, a method-based API can be defined. It doesn't need to be 100% bulletproof, it needs to be intuitive, fast and not get in the way.
  • Simple BeginUpdate / EndUpdate API with optional spec of the modified rect in EndUpdate? Begin returns the internal Grid<T>, End emits change events.
  • Simple SetTiles API for copying a source grid onto the existing tilemap.
  • Simple AssumeRect / Resize / Clear API.
  • 100% safe LockRegion / UnlockRegion approaches are probably slow because of copying. Avoid.

[ilexp]

Progress:

• Created a first, operational Tilemap implementation. Only basic read / write access and an API that allows to monitor changes, so other Components can be notified.

Roadmap:

• Create a first operational Tileset implementation.
  • No advanced features (AutoTiles, etc.)
  • Design an API that can be used to access all required tile data.
• Create a first operational TilemapRenderer implementation.
  • Should support all basic rendering features, including rotation and proper tilemap culling.
  • Cached vertex array as usual, reasonably performant.
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.
• Implement editor support.
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
  • Tilemap editor
  • CamViewState
    • Might need to be refactored so there is no SelObj code when not required. Object Movement / Selection / Basic transformation should be an optional component. Maybe move it to a distinct class?
  • Unique docking widget and tools for tilemap editing.
    • Pen, Rect, Circle
    • As a source for drawing, both the docking widget and the actual map can be used (Tile picker)
  • Half-transparent display of all non-selected tilemaps

[ilexp]

Progress:

• Created a first TilemapRenderer implementation. No texturing yet, but culling and basic rendering works.

Roadmap:

• Create a first operational Tileset implementation.
  • No advanced features (AutoTiles, etc.)
  • Design an API that can be used to access all required tile data.
• TilemapRenderer should render actual tiles from the Tileset
• Improve Tilemap Serialization by using an internal storage wrapper object, which implements ISerializeExplicit similar to PixelData. Store all tilemap data as a compressed byte[]. Right now, a 1000x1000 Tilemap with just indices takes about 160 MB in XML and 26 MB in binary. The optimal (uncompressed) size with the current data (one int32) would be about 4 MB.
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.
• Implement editor support.
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
  • Tilemap editor
  • CamViewState
    • Might need to be refactored so there is no SelObj code when not required. Object Movement / Selection / Basic transformation should be an optional component. Maybe move it to a distinct class?
  • Unique docking widget and tools for tilemap editing.
    • Pen, Rect, Circle
    • As a source for drawing, both the docking widget and the actual map can be used (Tile picker)
  • Half-transparent display of all non-selected tilemaps

[ilexp]

Progress:

• TilemapRenderer now renders textures tiles.
• Tilemap now uses a new TilemapData object to store its tile data, which implements a specialized compressed byte array serialization. A 1000x1000 with a simple pattern can now be stored in 27 KB XML, rather than 160 MB.
• Tileset now supports different source and target tile spacings. It will use source spacings for the mapping and fill up target spacings with the nearest tile pixels color. That way, filtering artifacts can be prevented despite using an atlas texture.

Roadmap:

• Optimize TilemapRenderer culling with regard to object and camera angle.
  • If they're the same, render just the minimal rect. If they're offset in a 45° angle, render the maximum rect (which is used by default in the current implementation)
  • If possible, get smart about this and use trigonometric stuff to come up with the exact rect that is required for the current relative angle between object and camera. Should be the same as finding the bounding rectangle of a rotated rect.
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.
• Implement editor support.
  • Recompile Tilesets when a source Pixmap changes.
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
  • Tilemap editor
  • CamViewState
    • Might need to be refactored so there is no SelObj code when not required. Object Movement / Selection / Basic transformation should be an optional component. Maybe move it to a distinct class?
  • Unique docking widget and tools for tilemap editing.
    • Pen, Rect, Circle
    • As a source for drawing, both the docking widget and the actual map can be used (Tile picker)
  • Half-transparent display of all non-selected tilemaps

[ilexp]

Progress:

• TilemapRenderer culling was optimized to calculate the exact (object-local) rectangular region of tiles to render, reducing the number of actually rendered tiles by up to 50%, depending on the setup.

Roadmap:

• Implement editor support.
  • Recompile Tilesets when a source Pixmap changes.
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
  • Tilemap editor
  • CamViewState
    • Might need to be refactored so there is no SelObj code when not required. Object Movement / Selection / Basic transformation should be an optional component. Maybe move it to a distinct class?
  • Unique docking widget and tools for tilemap editing.
    • Pen, Rect, Circle
    • As a source for drawing, both the docking widget and the actual map can be used (Tile picker)
  • Half-transparent display of all non-selected tilemaps
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

Progress:

• Refactored CamViewState to not include object editing functionality and moved it into a distinct ObjectEditorCamViewState class, which derives from CamViewState. This was a preparation step for implementing the Tileset editor later.

Roadmap:

• Implement editor support.
  • Recompile Tilesets when a source Pixmap changes.
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
  • Tilemap editor
  • CamViewState
  • Unique docking widget and tools for tilemap editing.
    • Pen, Rect, Circle
    • As a source for drawing, both the docking widget and the actual map can be used (Tile picker)
  • Half-transparent display of all non-selected tilemaps
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

Public Domain / CC0 testing tileset with actual content: Taken from here.

[ilexp]

Progress:

• Implemented a first rough sketch of a Tilemap Editor CamViewState, including selection and simple drawing logic.
• Added a custom toolbar and buttons for each Tilemap editing cursor mode, as well as a first sketch of the internal cursor action logic.

Roadmap:

• Implement editor support.
  • Recompile Tilesets when a source Pixmap changes.
  • Tilemap editor
  • Implement Tools for tilemap editing.
    • Select, Brush, Rect, Circle, Fill
    • Implement all of them with a simple solid fixed index first.
  • Implement highlighting code for arbitrary sets of tiles.
    • (Optimized) Quads for content, LineLoop for outline. Don't get all sophisticated with outline polygons and convex decomposition. Something simple will likely be enough.
  • Tile Selector (docking widget)
    • As a source for drawing, both the docking widget and the actual map can be used (Tile picker)
    • Interface to query source tiles from.
  • Tile Minimap (docking widget)
    • Shows the currently selected Tilemap in a one-pixel-per-Tile kind of way
    • Also displays the camera viewport and allows to drag it around
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

Progress:

• Implemented tilemap editor highlighting code for arbitrary sets of tiles.
• The tilemap editor now maintains the current set of active tiles and the action to perform as an explicit state, enabling action previews.
• Moved the tilemap culling algorithm to a distinct static helper class so it can be easily used by different parts of the system. It's also self-contained now, so third-party projects can easily use the code when required.

Roadmap:

• Implement editor support.
  • Recompile Tilesets when a source Pixmap changes.
  • Tilemap editor
  • Implement Tools for tilemap editing.
    • Select, Brush, Rect, Circle, Fill
    • Implement all of them with a simple solid fixed index first.
  • Tile Selector (docking widget)
    • As a source for drawing, both the docking widget and the actual map can be used (Tile picker)
    • Interface to query source tiles from.
  • Tile Minimap (docking widget)
    • Shows the currently selected Tilemap in a one-pixel-per-Tile kind of way
    • Also displays the camera viewport and allows to drag it around
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

Progress:

• Implemented Brush, Rect and Circle tools, including undo/redo support and previews.

Roadmap:

• Implement editor support.
  • Recompile Tilesets when a source Pixmap changes.
  • Tilemap editor
  • Implement Tools for tilemap editing with a simple solid fixed index first.
    • Fill tool
  • Tile Selector (docking widget)
    • As a source for drawing, both the docking widget and the actual map can be used (Tile picker)
    • Interface to query source tiles from.
  • Tile Minimap (docking widget)
    • Shows the currently selected Tilemap in a one-pixel-per-Tile kind of way
    • Also displays the camera viewport and allows to drag it around
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

Progress:

• Implemented Flood Fill and optimized the tilemap editor in various places to allow live previews of flood fill operations at acceptable performance when editing large maps.
• More optimizations to tilemap editing with regard to very big tilemaps.
• Refactored Tilemap editor tools into a more object-oriented scheme. Each tool is now a self-descriptive implementation of a base class and all tools are dynamically discovered using Duality's plugin / reflection infrastructure. This allows plugins to add custom tilemap editing tools.

Roadmap:

• Implement editor support.
  • Recompile Tilesets when a source Pixmap changes.
  • Tilemap editor
  • As a source for drawing, both the docking widget and the actual map can be used (Tile picker)
  • Tile Picker (tool)
    • Also available at any point while holding the ALT key.
    • Selects a rectangular region which is highlighted in a different color.
    • This region will act as the source for drawing tiles. It is buffered before beginning each editing operation.
    • Should be possible across different tilemaps.
  • Tile Selector (docking widget)
    • Interface to query source tiles from.
    • Uses the original tileset layout, so block selections make sense.
    • Defaults to block selections via click+drag
    • Can actually do arbitrarily shaped selections using the CTRL key
  • Tile Minimap (docking widget)
    • Shows the currently selected Tilemap in a one-pixel-per-Tile kind of way
    • Also displays the camera viewport and allows to drag it around
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

Progress:

• Added help system integration to the tilemap editor and provided basic docs on all the tools.
• Implemented a Tile Picker tool.
• Defined and integrated a tile drawing source abstraction.
• Optimized the overall help system, as well as various editor-wide tweaks that were necessary for the desired tile picking tool behavior (help, ALT key, ...).

Roadmap:

• Implement editor support.
  • Recompile Tilesets when a source Pixmap changes.
  • Tilemap editor
  • Tile Selector (docking widget)
    • Interface to query source tiles from.
    • Uses the original tileset layout, so block selections make sense.
    • Defaults to block selections via click+drag
    • Can actually do arbitrarily shaped selections using the CTRL key
  • Tile Minimap (docking widget)
    • Shows the currently selected Tilemap in a one-pixel-per-Tile kind of way
    • Also displays the camera viewport and allows to drag it around
  • Tileset editor
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
• Implement advanced features.
  • AutoTiles
  • TilemapRenderer Z Offset Generation
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

Progress:

• Added the skeleton of a tile palette docking control that automatically opens when using the Tilemap Editor CamViewState.
• Added a first draft of a TilesetView control, which will be used to display and select tiles, and potentially for the Tileset Editor later as well.

Roadmap:

• Implement editor support.
  • Recompile Tilesets when a source Pixmap changes.
  • Tilemap picking should take into account fully (or nearly) transparent tiles and treat them as non-solid during picking operations.
  • Tilemap editor
  • Tile Selector (docking widget)
    • Tile selection via click-drag, display selected tiles (fill + border)
    • Make all of the selection and hover code in TilesetView opt-in, potentially move to distinct subclass to maximize reusability in the later Tileset editor.
    • Tweak background pattern / colors to blend in better with the overall editor visuals.
  • Tilemap Settings (non-tool action)
    • Resizing the tilemap.
    • Moving the tilemap (wrap-around offset)
    • When the Tilemap Editor gets focus on or selects an empty Tilemap, the resize dialog should pop up with some default values.
    • When explicitly opening the dialog while no Tilemap is selected, it should turn into a "New Tilemap" dialog for initial setup. Could also support a quick "Create N layered Tilemaps" macro.
  • Tile Minimap (docking widget)
    • Shows the currently selected Tilemap in a one-pixel-per-Tile kind of way
    • Also displays the camera viewport and allows to drag it around
  • Tileset editor
  • Opens on double-click?
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
• Implement advanced features.
  • AutoTiles
  • Also, have a way to not use AutoTiling in specific cases, or use specific AutoTile-versions on mapper's choice, see here.
  • TilemapRenderer Z Offset Generation
  • Specify Z range / depth of a single tile. Defaults to zero.
  • Where Z-0 will be is implicit based on the renderers origin.
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

For reference on the Z sorting / height / depth handling of tilemaps, this is how RMXP handles it:

Basically the same as the above mentioned "height offset" idea for tilesets.

[ilexp]

Progress:

• Improved Tile Palette selection behavior.
• Improved TilesetView background pattern and highlight color schemes.
• Tweaked TilemapEditorCamViewState to indicate active tilemap for hover actions.

Roadmap:

• Implement editor support.
  • Recompile Tilesets when a source Pixmap changes.
  • Tilemap picking should take into account fully (or nearly) transparent tiles and treat them as non-solid during picking operations.
  • Tilemap editor
  • Tile Selector (docking widget)
    • Tile selection via click-drag, display selected tiles (fill + border)
    • Make all of the selection and hover code in TilesetView opt-in, potentially move to distinct subclass to maximize reusability in the later Tileset editor.
  • Tilemap Settings (non-tool action)
    • Resizing the tilemap.
    • Moving the tilemap (wrap-around offset)
    • When the Tilemap Editor gets focus on or selects an empty Tilemap, the resize dialog should pop up with some default values.
    • When explicitly opening the dialog while no Tilemap is selected, it should turn into a "New Tilemap" dialog for initial setup. Could also support a quick "Create N layered Tilemaps" macro.
  • Tile Minimap (docking widget)
    • Shows the currently selected Tilemap in a one-pixel-per-Tile kind of way
    • Also displays the camera viewport and allows to drag it around
  • Tileset editor
  • Opens on double-click?
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
• Implement advanced features.
  • AutoTiles
  • Also, have a way to not use AutoTiling in specific cases, or use specific AutoTile-versions on mapper's choice, see here.
  • TilemapRenderer Z Offset Generation
  • Specify Z range / depth of a single tile. Defaults to zero.
  • Where Z-0 will be is implicit based on the renderers origin.
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

Progress:

• The Tile Selector / Tile Palette docking control has reached a usable state and is done in first iteration.
• Also refactored the TilesetView and split it in two classes: The TilesetView base class with just the view, and a tile palette specific subclass with selection behavior.
• Tilemap picking now takes into account transparent tiles and treats them as non-solid.

Roadmap:

• Implement editor support.
  • Recompile Tilesets when a source Pixmap changes.
  • Tilemap editor
  • Tilemap Settings (non-tool action)
    • Resizing the tilemap.
    • When the Tilemap Editor gets focus on or selects an empty Tilemap, the resize dialog should pop up with some default values.
    • When explicitly opening the dialog while no Tilemap is selected, it should turn into a "New Tilemap" dialog for initial setup. Could also support a quick "Create N layered Tilemaps" macro.
  • Tile Minimap (docking widget)
    • Shows the currently selected Tilemap in a one-pixel-per-Tile kind of way
    • Also displays the camera viewport and allows to drag it around
  • Tileset editor
  • Opens on double-click?
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
• Implement advanced features.
  • AutoTiles
  • Also, have a way to not use AutoTiling in specific cases, or use specific AutoTile-versions on mapper's choice, see here.
  • TilemapRenderer Z Offset Generation
  • Specify Z range / depth of a single tile. Defaults to zero.
  • Where Z-0 will be is implicit based on the renderers origin.
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

Progress:

• Moved the old (pre-Duality) rpg prototype OriginSelector code to AdamsLair.WinForms and tweaked its visuals.
• Updated AdamsLair.WinForms dependency.
• Started drafting a TilemapSetupDialog.

Roadmap:

• Implement editor support.
  • Various Tweaks / WiP ToDo's
  • Recompile Tilesets when a source Pixmap changes.
  • Add a PreviewProvider for Tilesets.
  • The TilesetView should have a multi-column mode for when the Tileset layout (horizontal / vertical) doesn't match the view's layout.
  • Tilemap editor
  • Tilemap Settings (non-tool action)
    • Resizing the tilemap.
    • When the Tilemap Editor gets focus on or selects an empty Tilemap, the resize dialog should pop up with some default values.
    • When explicitly opening the dialog while no Tilemap is selected, it should turn into a "New Tilemap" dialog for initial setup. Could also support a quick "Create N layered Tilemaps" macro.
  • Tile Minimap (docking widget)
    • Shows the currently selected Tilemap in a one-pixel-per-Tile kind of way
    • Also displays the camera viewport and allows to drag it around
  • Tileset editor
  • Opens on double-click?
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
• Implement advanced features.
  • AutoTiles
  • Also, have a way to not use AutoTiling in specific cases, or use specific AutoTile-versions on mapper's choice, see here.
  • TilemapRenderer Z Offset Generation
  • Specify Z range / depth of a single tile. Defaults to zero.
  • Where Z-0 will be is implicit based on the renderers origin.
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

Progress:

• Completed the Resize Tilemaps dialog.
• Recompiling Tilesets when a source Pixmap changes.
• Added a PreviewProvider for tilesets.

Roadmap:

• Implement editor support.
  • Tilemap editor
  • The TilesetView should have a multi-column mode for when the Tileset layout (horizontal / vertical) doesn't match the view's layout.
  • Create Tilemap Dialog
    • Specify size
    • Create N layered Tilemaps
    • Create Collider and RigidBody?
  • Tile Minimap (docking widget)
    • Shows the currently selected Tilemap in a one-pixel-per-Tile kind of way
    • Also displays the camera viewport and allows to drag it around
  • Tileset editor
  • Opens on double-click?
  • Combo of a completely custom editor and the Object Inspector
  • Define visual layers, AutoTiles, collision info, custom tags / data, ...
• Implement advanced features.
  • AutoTiles
  • Also, have a way to not use AutoTiling in specific cases, or use specific AutoTile-versions on mapper's choice, see here.
  • There could actually be two distinct types of AutoTiles: "Invasive" AutoTiles (that actually generate new tiles internally) and "Non-Invasive" AutoTiles (that just automatically choose from a set of existing tiles depending on their surroundings).
  • For editor convenience, it could be possible to specify additional tiles an AutoTile connects to.
  • TilemapRenderer Z Offset Generation
  • Z offsets can be generated based on world Y coordinates (for straightforward character interaction) or relative to the renderers own origin.
  • Specify Z scale and / or range
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers editor-wise (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

This plugin being an optional sidetrack of Duality development, its workload should be reduced to an absolute minimum until its first fully functional release in order to shift towards parallel development. Maintaining an extra branch makes it harder to introduce bigger changes into the framework on a non-master branch.

Things that need to be done before release:

• Finishing the Tilemap Editor
• Tileset Editor
• TilemapCollider implementation
• Optional Z-Offset Generation
• Per-Tile Z Offsets with (tileset-based) height- and flat / upright info.
• AutoTiles
• Fill the sample project
  • A retro RPG-like test Scene and a character to walk around in it.
  • A sidescroller-like test Scene and some physics objects rolling around in it.

Things that are optional and can be left out for now:

• Local tile-based offsets for tileset-based height- and flat / upright info.
• The New Tilemap dialog. It's really just a rare convenience.
• Custom Data Tags for each tile.
• Anything else.

[ilexp]

Progress:

• TilesetView now has a optional multi-column mode, both vertically and horizontally.

Roadmap:

• Implement editor support.
  • Tilemap editor
  • Tile Minimap (docking widget)
    • Shows the currently selected Tilemap in a one-pixel-per-Tile kind of way
    • Also displays the camera viewport and allows to drag it around
  • Tileset editor
  • Opens on double-click?
  • Combo of a completely custom editor and the Object Inspector? Depends, actually. First draw a few sketches and define layout and functionality of the editor - then see what's really needed.
  • Define visual layers, AutoTiles, collision info, potentially more stuff later.
  • Multiple tab pages?
• Implement advanced features.
  • AutoTiles
  • Also, have a way to not use AutoTiling in specific cases, or use specific AutoTile-versions on mapper's choice, see here.
  • There could actually be two distinct types of AutoTiles: "Invasive" AutoTiles (that actually generate new tiles internally) and "Non-Invasive" AutoTiles (that just automatically choose from a set of existing tiles depending on their surroundings).
  • For editor convenience, it could be possible to specify additional tiles an AutoTile connects to.
  • TilemapRenderer Z Offset Generation
  • Z offsets can be generated based on world Y coordinates (for straightforward character interaction) or relative to the renderers own origin.
  • Specify Z scale and / or range
  • Height Offsets, Flat / Upright Tiles
  • Collision Info
  • Support for multiple layers editor-wise (e.g. one for characters, different one for ships. Arbitrary distinction.)
  • TilemapCollider
  • Tilemap listener interface for triggering ingame and editor updates on changes.
  • Incremental updates, no "rebuild all, every time" - except if it's reasonably cheap.
    • Profile this. Interactive editing should be possible on huge Tilemaps with multiple collision layers.
  • Shouldn't be required to be attached to the same GameObject as the Tilemap, but allow to specify the source Tilemap in an optional property.
  • Should allow to specify which collision layer(s) should be used. Singular or additive bitmask.

[ilexp]

This issue has been split up into multiple issues to keep track of progress and concept, see the referencing issues above.