Week 56: Still more custom autotiling

There are a lot of "corner cases" to add matching logic for!
And I still need to add more interior and 27° cases!

tl;dr: I continued work on custom autotiling logic with support for internal-vs-external subtiles and for 90°, 45°, and 27° surface combinations.

What happened last week?

What is this "autotiling" thing I'm doing, and why is it taking so long??

I'm still in the middle of creating large new system for "autotiling". This system will do a lot of cool things:

• Automatically select the correct tile to render in the level when the level-author "draws" the grid-cells that should contain level terrain.
• This automatic tile selection takes into consideration the slopes of all adjacent surfaces and the art of all adjacent cells in order to render continuous shapes with smooth transitions from one tile to the next.
• Support tiles with slopes along 90°, 45°, and 27° multiples.
• Support fading from the high-contrast exterior art at the collision boundary to a solid-color for interior cells.
• And furthermore, support stretching this fade across a depth of two cells.
• This means that a cell could be exterior, slightly interior, or fully interior, and there would be different art to draw depending on the specific case.
• And finally, this system will require the tile-set author to draw a minimal set of art that can then produce the thousands of different possible tiles.

This system is taking a long time to implement, because there are so many edge cases to consider! But I think this is more than worth the time because it is a really cool tool that has never been done before, and this will be a huge time-saver for all of my future games.

Highlights

• Continue creating a new autotiling system.
• Do some prep for Global Game Jam 2022.

Laundry list

• Continue creating a new autotiling system.
• Finish adding all 90-degree, all 45-degree, and some 27-degree cases to my autotiling SubtileCorner enum legend.
• Implement logic for finding the best matching subtile for a given set of target corner types.
• Start implementing logic to calculate the target corner types to match from the tile-set for a given cell in the tile-map.
• Add a mapping for which corner-types can be matched to which additional corner-types.
• Add a flag to indicate whether custom corner-match autotiling is supported at runtime.
• Setting this to false should save some cycles and memory when actually running the game.
• Implement the four-corner-total-match-priority calculation.
• Incorporate angle-type matching to the corner-match autotiling system.
• Add more CellProximity helper methods for checking whether sides curve in.
• Continue implementing logic to calculate the target corner types to match from the tile-set for a given cell in the tile-map.
• Start adding CellProximity helper methods for internal cases.
• Diagram possible corner-neighbor topologies in order to get a sense for the logic.
• Enumerate diagrams for all the different topographies that could lead to a 27-degree subtile being converted to a 90-degree surface.
• Create logic for checking whether a 27-degree subtile should be interpreted as a 90-degree surface.
• Create generic CellProximity shape-check helper functions that can check any given neighbor (rather than the old approach of using a separate function for each possible neighbor to check).
• Clean up scattered and out-of-date notes, TODOs, and comments.
• Add support for also checking the adjacent inbound corner-types, in order to choose subtitles that can match the specific neighboring subtile shape.
• Update the subtile corner-type legend to match the current enums.
• Update 90-45 tileset art.
• Update 90-45 tileset bitmasks.
• Encode 90-degree external subtile corner configurations.
• Split-out the SubtileCorner definitions into separate files.
• Split-out the target-corner calculations into a separate file.
• Debug issues with the current corner-match autotiling logic.
• Do some prep for the upcoming GGJ game jam.
• Add some setup for easy hosting on GitHub Pages.
• Add a screenshot utility.
• Create an automated build-with-godot and publish-to-itch.io workflow using GitHub Actions.
• This triggers when creating a new release in GitHub.
• This uses a couple packages from the GitHub Actions marketplace:
• https://github.com/marketplace/actions/build-godot
• https://github.com/marketplace/actions/butler-push
• This will be really handy for my upcoming team game jam.
• However, I don’t think it’ll make sense for my individual projects.
• I usually want to release mobile builds for my individual projects.
• When creating a mobile build, Godot requires including some sensitive information in the exports config file.
• This new automated release workflow requires including the exports config file in the repositories.
• All my repos are public.
• As-is, I can’t include the sensitive info in my public repo, so I can’t use the automated workflow.
• I could probably update this to include a mostly-complete export-config template file, and do some automatic magic to fill things in and move the file around during the GitHub Actions workflow, and that should let me get around the problem--at least for just generating desktop and browser builds. But I still don’t think this would work for generating mobile builds.
• Miscellaneous:
• Submitted my Google Play Store Data safety form for Inner-Tube Climber.
• Add support for rendering tile-map cell grid positions for debugging.

Global Game Jam 2022

Also, I participated in Global Game Jam over the weekend with some friends! But I'll talk all about that in a separate post.

What's next?

• Continue creating my new autotiling system.
• I'll be refactoring it to dynamically construct Godot subtiles based on four smaller Aseprite tiles—placing a different Aseprite tile in each quadrant of the Godot subtile.
• I'll be adding more 27° cases.

🎉 Cheers!