Building a Dynamic Tile-Based Inventory System

Originally when creating this system I had some basic goals and parameters, as I kept developing the game and came across new use cases and design ideas I had to expand the inventory system to cover all use-cases. Here you will find a technical break down of my programming and design decisions.

Concept and Design Goals:

The purpose behind the inventory system was to create a dynamic "heavy" mechanic where the player had to carefully choose what to pick up and what to leave behind. The inventory should feel physical, items hsould have shape rotation and limitted space. Dredge was a huge inspiration for this as the inventory in that was incredibly robust and thematic.Similarly, I wanted to create objects that the player wants to discover, to look at, and to learn more about. I was also incredibly inspired by the shape rotation puzzles where the player has to carefully piece together different items to fill out a desired shape, unlocking a hidden interaction.

Design Considerations:

• Tactile and spatial: Items should feel like physical objects with shape and rotation, not abstract icons in a list. 
• Thematic coherence: The limited space mirrors the game’s themes of scarcity, resourcefulness, and scavenging. 
• Meaningful choice: Inventory management should be a strategic constraint, players must decide what’s worth keeping. 
• Readability: Despite complexity, the layout should remain clear and easy to read at a glance. 
• Environmental storytelling: Each item should have descriptive data (name, image, text) to build the world’s narrative. 
• Modular design: The system needed to support both the player’s backpack and special in-world inventories (e.g. machine sockets). 
• Visual polish: Items should align neatly, highlight interactively, and feel cohesive with the UI’s minimalist aesthetic.

Mechanical Requirements:

• Dynamic grid sizing: Must scale based on screen resolution and adapt to different inventory dimensions.
• Tile-based placement: Each item occupies multiple cells defined by its shape data (Vector2Int[]).
• Rotation support: Items can rotate in 90° increments, updating both their shape and pivot alignment.
• Collision checks: System must detect overlaps and restrict placement within grid boundaries.
• Drag-and-drop logic: Allow intuitive mouse interactions — clicking to pick up or place items.
• Held item rendering: Items being dragged must appear above the UI layer (handled via a separate DragCanvas).
• Restricted cell logic: Certain inventories allow placement only in specific cells (used for machine puzzles).
• Persistence: Inventory data must save and restore correctly across scenes.
• Information display: On hover or selection, an inspection panel shows item art and description.
• Inter-grid communication: Placing an item in a specific grid or slot can trigger in-game events via SendMessage.

These design considerations shaped every aspect of the inventory system, from the way items snap into place to how players interact with them visually and mechanically. Each choice — whether for spatial realism, narrative weight, or modular flexibility — informed the code and structure of the system. With these goals in mind, I structured the inventory around a dynamic, tile-based array system that could handle rotation, placement, and interaction across multiple contexts. The following sections break down the system step by step, starting with how the underlying array and data architecture was implemented.