Tile-Based Worlds is my work-in-progress collection of scripts for creating and using abstract vertex/edge/face data structures as a foundation for tile-based games.
Update 2016/04/08: It has been accepted onto the Asset Store: Get it here!
As an offshoot from a planet generation prototype I created last year, these scripts will provide utilities for defining a wide variety of regular and irregular tiled surfaces, and for integrating them with any tile-based game mechanics and user interface elements needed for your game, such as placing units on tiles, efficient mouse picking, and path finding.
The bulk of the scripts are raw C# classes and structs, meant to provide the data structure backbone for game mechanics, rather than drag-and-drop functionality from within the editor, though the more common functionality will certainly be provided as easily usable components when possible.
Evolving from a planet generation background, spheres were the first type of surface that I implemented, but other common surfaces are also planned. Flat projections for topologies that optionally wrap around at the edges will definitely be supported also, and will have access to same range of creation and interaction utilities that go well beyond simple square- or hex-based tiling systems.
These alternate tiling patterns can easily be used to reinvent new variants of existing games, so as this example with Go:
Currently Implemented:
-
Spherical topologies generated from triangle/square subdivisions of tetrahedrons, cubes, octahedrons, and icosahedrons.
-
Planar topologies supporting both square and hex grids, capable of wrapping around on the horizontal edges, vertical edges, both, or neither.
-
Randomization of tiles to produce an irregular topology. Particularly good when paired with spherical topologies where there would otherwise be predictably placed tiles with a different number of sides than the majority.
-
BSP tree generation for enabling efficient mouse/ray picking.
-
A* path finding, supporting whatever cost calculations and heuristics are applicable to your game.
-
Dynamic mesh generation, with submeshes automatically generated whenever the vertex count goes over 64K.
-
Random adjacent visitation of faces, used in the examples above to generate the colored regions by randomly flood filling the entire surface starting from a fixed number of seed faces.
-
Vertex/Edge/Face attribute calculations (face centroids, face/vertex normals, edge midpoints/lengths, face/vertex areas, et cetera).
-
A clean API for navigating through topologies no matter how complex they are.
-
Convenient UI for generating assets from the editor, with most of the actual generation API accessible during run-time also.
The following tutorial video walks through some of the core functionality to create a hex-based work with mouse picking and path finding:
Planned Features:
- Flexible movement rules, such as distinguishing between 4-direction and 8-direction movement on a square grid, or the more complex movement rules of chess.
- Mesh generation for region outlines, paths, and any other line-based visualizations associated with a topology.
- Voronoi-based tile generation.
- Advanced planet generation demo.
- Automatic wrap-around world rendering through integration with another upcoming asset for working with wrap-around worlds generally (both tile-based and not).
Questions for the Community:
- Is this something you could use?
- Does it motivate you to want to build a tile-based game using some of the features that go beyond a simple square grid?
- Does it look like it could make any of your past, current, or future projects easier? Or does it mostly reimplement functionality that you think would be easy enough to implement yourself, with any additional functionality being stuff which you wouldn’t care to use?
- Are there any features which you think would be a natural extension to this tool set which I haven’t mentioned?
- Would you have any preferences for how you would interface with the tool set? Through code or through the editor and component inspectors? If the latter, what type of components would you envision, and what type of flexibility would they expose through the editor?