Grid-based Game Development in Godot: Learn grid data, visualization, interaction and more!

Summary

The video builds a reusable grid system in Godot, starting with basic 2D grid math and ending with grid visualization, gameplay queries, and integration into a larger 3D tactics-game project. The grid remains two-dimensional in its data model, even when displayed in 3D.

Why Use Grids?

• A grid turns continuous space into discrete cells that are easier for developers to store and reason about.
• It can make movement, range, and placement easier for players to understand: they can count tiles rather than judge exact distances.
• These techniques are useful for tactics games, roguelikes, city builders, and puzzle games. They can also apply to 2D games; a true 3D voxel grid requires additional work.

1. Grid Coordinates and Data Storage

Converting Positions to Cell Addresses

• Give each cell a fixed size.
• Convert a screen-space position to a grid address by dividing its coordinates by the cell size and flooring the results.
• Grid addresses are integer-based: an entity is in a cell rather than partway between cells.
• Convert an address back to a position by multiplying it by the cell size.
• Keep gameplay data separate from its visual representation. For example, store a character’s grid address as data, then update its sprite or model from that value.

Checking Map Bounds

• Define a map size and check whether an address is within the allowed range before reading or writing data.
• This prevents clicks or movement from accessing cells outside the map.
• For grids with an origin away from (0, 0), include that origin in the bounds calculations.

Two Complementary Storage Approaches

• Flat array: Store one entry per cell, which works well for dense data such as terrain types.
  • Flatten a 2D address into a single index using the row width: index = y * map_width + x (adjusting for the map origin where needed).
  • Convert back by dividing by the width to get the row and taking the remainder to get the column.
  • A flat array avoids nested-array access and can make indexing more straightforward.
• List of addressed objects: Store only objects that exist, each with its own grid address. This suits sparse data such as a small number of characters.
  • It also allows multiple objects to share a cell.
• These approaches can be combined: use a dense array for terrain and a list of objects for units.

2. Interacting with a Grid in 3D

The grid data is still 2D, but the game world is 3D.

• Place a collider over the grid and cast a ray from the camera through the mouse position.
• Use the ray intersection’s world position to determine the clicked cell.
• For a horizontal grid, the relevant world coordinates are X and Z; the vertical Y coordinate is generally not part of the grid address.
• Convert those coordinates to integer grid addresses using the same position-to-address logic as in 2D.
• Configure the collider and ray’s collision mask consistently. The example also uses a special “non-tile” address to represent a ray that hits no valid grid cell, since (0, 0) is a legitimate address.
• If the game supports multiple heights, deciding which height a click refers to is an additional design problem.

3. Visualizing Grid Cells with a Shader

Rather than creating a separate mesh for every cell, the tutorial uses a shader on a large mesh to draw grid lines.

• The shader receives configurable values such as cell size, line color, and transparency.
• It passes each vertex’s world position to the fragment stage, which uses the XZ coordinates to determine where the pixel lies relative to the grid.
• Fractional-coordinate and derivative-based calculations locate cell edges and help soften them through anti-aliasing.
• The presenter notes that the shader math is specialized graphics work and focuses on applying and adjusting it rather than deriving every part from first principles.

4. Data-Driven Shader Overlays

The shader can show information about cells as well as their boundaries.

• Create an image with one pixel per grid cell and a corresponding texture.
• When a cell’s state changes, write its color to the matching image pixel, update the texture, and let the shader sample it.
• Account for the grid’s origin when converting cell addresses into image coordinates.
• This provides a compact way to show states such as a cursor location, movement range, danger, or passability.

Multiple Channels

• Store separate boolean data for each highlight channel, alongside a color assigned to each channel.
• This makes highlights non-destructive: clearing one channel does not erase data held in another.
• Give channels a priority order. When multiple channels are active for one cell, the first active channel in that order determines the displayed color.
• Track which cells have changed in a “dirty cells” collection. Refresh only those cells instead of rebuilding the full grid texture after every update.
• The example uses a small debug view of the texture to help verify which cells are being written.

5. Using GridMaps to Drive Gameplay Data

Godot’s GridMap places models on a grid, but the tutorial treats it primarily as a way to build a level—not as a complete gameplay-data system.

• Create a tile-type library that maps GridMap item names to custom resource entries.
• Give each entry properties needed by gameplay, such as whether the tile is passable. Other possible properties include movement cost or damage.
• Look up the GridMap item at an address, translate its item ID into a tile name, and use the library to retrieve its data.
• Iterate over map cells and use the resulting properties to populate visualization channels. The example colors passable and impassable terrain differently, and treats empty cells separately.
• This separates level construction from the rules the game applies to each tile.

6. Querying Ranges, Shapes, and Continuous Directions

The tutorial demonstrates several ways to produce collections of grid addresses for gameplay.

• Range query: Visit cells and keep those whose distance from an origin falls between a minimum and maximum. The example uses distance to create a range indicator; using floating-point limits allows more precise diagonal ranges.
• Shape query: Define a shape as a list of integer offsets from an origin. Add the origin to each offset to place the shape on the map.
  • Convert offsets to vectors, rotate them in 90-degree increments around the origin, then round back to integer coordinates.
  • This works for footprints, placement patterns, and shapes such as an L-shaped piece.
• Directional query: Step outward from an origin in one or more directions, collecting cells until a blocking or impassable tile is encountered.
  • The example checks diagonal directions, similar to a bishop’s movement in chess.

These queries can return address lists for rendering, targeting, movement, or other game logic. Pathfinding is mentioned as a future extension: Godot’s A* classes can work with grid addresses, but pathfinding is not implemented in this video.

7. Integrating the Grid into a Larger Game

In the final section, the standalone examples are adapted to the creator’s tactics-game project.

• Grid utilities, shader resources, tile-entry resources, and the visualizer are moved into a mission-grid feature.
• A mission context creates and configures the visualizer, then provides the services it needs, such as the camera.
• The visualizer is responsible for displaying the grid and exposing grid-related interactions; signals are prepared for hover and selection addresses.
• The integration establishes the structure for gameplay to communicate with the grid without making the visualizer responsible for every game rule.

Speakers and Sources Featured

• Speaker: One presenter/narrator from the HoveringSkull channel. No additional speakers are identifiable in the subtitles.
• Sources and tools referenced:
  • Godot documentation, including material on input coordinates, raycasting, and A* pathfinding.
  • GodotShaders.com, referenced as a source of shader code and examples.
  • Chesshouse.com, credited for the chessboard image used to explain flattened grid indexing.
  • K-Kits dungeon assets, used for example GridMap tiles.
  • The creator’s own 3D tactics-game project and related course repository.