Day 17 — Crafting Mechanics & Input Refactors

Context

With the Crafting UI and backend structure in place, today was about testing the actual mechanics: how players interact with a crafting station, how recipes behave, and how the system responds to available materials. This was the first time all the pieces started coming together in a playable form.

Crafting Station Interaction

Players can now:

• Place (drop) a Crafting Station in the world.
• Walk up and interact with it to open the Crafting UI.
• Navigate recipe slots to see material requirements.
• Craft an item when they have the necessary resources.

The station itself behaves consistently with other item‑based objects in the game—fully supporting Drop and Pickup behavior.

UI Integration & Feedback

The UI is functional but unpolished. Still, it includes:

• Slot navigation using the consolidated input device.
• A clear indication of whether materials are available.
• Subtle feedback animations when crafting succeeds (or fails).

Scrollable slots are partially implemented—you can see up to 12 recipes, but scrolling logic still needs work.

Input System Refactor

While building the crafting flow, I had to untangle and reorganize input logic:

1. Fixed an item‑quantity bug where Drop One vs. Drop All behaved inconsistently.
2. Consolidated all UI inputs into a single UI device.
3. Consolidated all world inputs into a single world‑input device.

This simplifies long‑term maintenance and prevents input conflicts between systems.

Next Steps

• Implement scrolling for larger recipe lists.
• Add destructible properties to tools.
• Polish UI states and transitions.

---

Summary

What I accomplished:

• Made crafting stations fully interactive.
• Implemented the basic crafting flow with material validation.
• Added subtle UI feedback animations.
• Refactored input handling into unified devices.
• Fixed Drop One vs. Drop All behavior.

What I learned:

• Crafting ties together more systems than expected—UI, items, world input, inventory, and persistence.
• Unified input management reduces future complexity.
• Early UI feedback, even rough, makes feature testing noticeably easier.

Day 16 — Crafting System Foundations

Context

Today marked the beginning of one of the largest and most important systems in Island Crossing: Crafting. This feature ties together nearly every other gameplay loop—gathering, tools, resources, progression—and will become a core part of the long‑term player experience.

Rather than trying to implement everything at once, I split the work between the AI Agent and myself so progress could happen in parallel.

System Architecture & Requirements

I began by outlining the full set of requirements for crafting, including:

• Crafting recipes
• Required ingredients and quantities
• Output items
• Crafting stations
• Crafting UI flow
• Validation logic
• Inventory integration
• Placement and pickup behavior

The list is large, but defining it early will reduce rework later.

Parallel Development Workflow

To keep things moving efficiently:

• The AI Agent began implementing the backend logic and data structures.
• I focused on building the UWs (User Widgets) that will form the Crafting UI.

This separation made it easier to work iteratively without blocking on UI or logic dependencies.

UI Work

I created the early versions of the UWs that will handle:

• Displaying available recipes
• Highlighting required materials
• Showing the player’s current inventory
• Crafting confirmation flow

Most of these are placeholder visuals, but they establish the overall layout and structure the system will build on.

---

Summary

What I accomplished:

• Defined the full requirements for the Crafting system.
• Began implementing Crafting backend logic via the AI Agent.
• Created the initial set of Crafting UI widgets.
• Established a parallel workflow to speed up development.

What I learned:

• Large systems benefit from early requirement gathering to avoid rework.
• Parallel work between UI and backend is effective when the system is well‑scoped.
• Crafting will likely be one of the most interconnected systems in the project.

Day 15 — Resource Gathering & Tile Coexistence

Context

Today’s work expanded gathering mechanics and improved tile flexibility.

Resource Additions

• Branches from shaking trees.
• Wood Piles from chopping trees.
• Stone from pickaxing rocks.

Tile Coexistence

• Grass can now coexist with other tile occupants, increasing interaction flexibility.

Interaction Prompt

• Added UI prompts for interactions to improve clarity.

Asset Expansion

• Used the automation pipeline to generate icons and meshes; also purchased assets for future crops.

---

Summary

What I accomplished:

• Added Branches, Wood Piles, and Stone.
• Implemented tile coexistence.
• Added interaction prompts.
• Expanded asset library.

What I learned:

• Coexistence greatly simplifies world design.
• Interaction prompts are essential as interactions increase.

Day 14 — Trees, Rocks & Asset Automation

Context

Today focused on expanding world variety and building tooling to accelerate asset creation.

Natural Resources

• Added random trees and rocks during initial world generation.

Item Catalog Refactor

• Centralized item definitions to remove scattered Item IDs.

Asset Pipeline

• Set up Python automation to:
  • Generate concept images via OpenAI.
  • Send images to Meshy.AI to create meshes.
  • Download FBX files.
  • Compress textures.

---

Summary

What I accomplished:

• Added trees and rocks to world generation.
• Refactored item catalog.
• Built an automated asset generation pipeline.

What I learned:

• AI pipelines are powerful but inconsistent for stylized assets.
• Automated tooling pays off even if early outputs aren’t perfect.

Day 13 — Generative Grid & Grass-Cutting Loop

Context

Today focused on making the island generate itself on a player’s first session.

Procedural Grid

• Replaced the static 2,500-tile prefab with procedural generation. Initial load now creates the island, which is then saved for future sessions.

Island Size Adjustment

• Reduced the grid size by 50% to bring generation time to ~20 seconds.

Grass Cutting

• Implemented the Grass resource loop:
  • Sickle harvests grass.
  • Grass is added to inventory.
  • Dropping Grass replants it.

---

Summary

What I accomplished:

• Implemented procedural grid generation.
• Added the grass harvesting and replanting loop.
• Optimized initial load times.

What I learned:

• Procedural systems must balance performance and player expectations.
• Resource loops quickly add depth to the world.

Day 12 — Persistence Hardening & Farming Completion

Context

With the farming loop in place, today was dedicated to polishing persistence and fixing edge cases.

Inventory Improvements

• Added Stack Drop support.
• Refined smart pickups to prevent overfilling.

Crop Persistence

• Implemented a “ratchet system” to ensure crops never regress when rejoining the world (i.e., When testing, the date always resets when restarting a session…but don’t regress the crops).

Critical Bug Fix

• Fixed a major issue where updating a tile incorrectly erased its saved growth stage.

---

Summary

What I accomplished:

• Completed farming persistence.
• Added advanced inventory behaviors.
• Fixed a major tile save corruption bug.

What I learned:

• Persistence must be validated at every step.
• Multi-day systems require safeguard logic.

Day 11 — Farming Loop Foundations

Context

Today marked the beginning of the farming gameplay loop.

Tile Lifecycle

• Tiles now support the full farming lifecycle:
  • Empty → Hole → Planted → Growing

Tool Behaviors

• Shovel digs holes.
• Seeds plant crops.
• Watering Can waters planted crops.

Growth Simulation

• Crops progress using timestamps stored at planting. The world_time_component now drives multi-day growth.

---

Summary

What I accomplished:

• Implemented the basic farming loop.
• Added tool behaviors for planting and watering.
• Built time-based crop stage progression.

What I learned:

• Time-based systems need careful persistence handling.
• Tile state transitions must remain deterministic.

Day 10 — Drop/Pickup Completion & Inventory Model Redesign

Context

With the refactor complete, today focused on finishing the Drop/Pickup milestone and stabilizing the inventory architecture.

Drop & Pickup Completion

• I implemented the full priority-based tile selection for dropping items. If no valid adjacent tile is available, the system now displays a toast message to the player. Items can also be picked up and placed into the correct inventory slot.

Inventory Model Redesign

• I refactored the inventory data model to use explicit slot-based storage rather than a virtual stack count. Each slot now stores both an Item ID and Quantity. This ensures the UI, logic, and persistence layers stay tightly aligned.

---

Summary

What I accomplished:

• Completed the Drop/Pickup milestone.
• Rebuilt the inventory model using explicit slot-based storage.
• Added toast notifications for invalid drop attempts.

What I learned:

• Clear data ownership prevents subtle bugs.
• User feedback (like toasts) matters even in early builds.

Day 9 — Grid Math Refinement & Prefab Stability

Context

Refactoring continued with a focus on stabilizing grid behaviors.

Grid Alignment Fixes

• Inconsistent grid math caused tool and item misalignment. I unified these calculations.

Prefab Cleanup

• Cleaned up several prefabs to reduce Scene Graph crashes.

---

Summary

What I accomplished:

• Unified grid calculation logic.
• Improved prefab clarity and stability.

What I learned:

• Grid calculations must be centralized.
• Scene Graph can be fragile with frequent prefab edits.

Day 8 — Major Refactor & Early Asset Tests

Context

Today focused on reorganizing the project into cleaner, more modular components while exploring options for generative tiles/grid.

System Decomposition

• Large, overloaded systems were broken down into focused components.

Tile Generation Tests

• Attempts to generate 2,500 tiles at once caused editor instability (5-10 minutes to save and Push Changes).

Asset Tests

• I tested Fab assets with the Curved World material to explore stylistic compatibility.

---

Summary

What I accomplished:

• Completed a major structural refactor.
• Tested large prefab generation.
• Evaluated external assets with curvature.

What I learned:

• Prefabs can overwhelm the editor at scale.
• Strong architecture accelerates future features.