Hooked on Systems: When a Simple Fishing Game Became an Exercise in Beautiful Complexity

There’s something inherently appealing about fishing games. Perhaps it’s the illusion of acquiring resources without traditional effort – a sensation that resonates with my own philosophy toward manual processes.

Obviously it’s not free as you’re spending a lot of time, but it feels free because you pluck a fish from the void and put it in your pocket.

This connection between idle games and automation aligns perfectly with my workflow preferences. I created this idle/incremental fishing game in Godot 4 partly because of this philosophical alignment.

I do not do manual. I don’t like manual processes at all and if I can automate it, I will usually.

This is the story of how my simple fishing game evolved from a straightforward idle clicker into an intricate system of interconnected mechanics—and why it remains in development limbo.

The Lure of Simplicity: The Initial Vision

The concept seemed straightforward: create a 2D idle fishing game where players would passively collect fish, unlock new zones, and experience the satisfaction of completing collection logs. I was inspired by games like Placid Plastic Duck Simulator, where the core loop involves watching ducks spawn every few minutes and “collecting” them simply by witnessing their arrival.

But there was a problem. In Placid Plastic Duck Simulator, the entertainment comes from watching ducks with physics-enabled movement splashing around in 3D space. My 2D fishing game would only have… progress bars.

A progress bar isn’t particularly engaging to watch. This realization led to the first of many system expansions: RPG elements.

Feature Creep or Feature Leap? The System Expansion

What began as a simple collection game quickly transformed. I started adding systems:

1. A multi-zone fishing system with unique fish in each location
2. Skill trees for each zone with persistent upgrades
3. A dynamic loot system based on Wave Function Collapse
4. Artifacts providing passive benefits
5. A collection log tracking progress across all zones
6. Garbage items that could be converted into resources
7. A prestige system using Fish Tokens

The skill trees became particularly elaborate. Since an idle game offers limited player interaction, I wanted to introduce meaningful agency through procedural skill trees with dynamic generation inspired by popular games.

I built a whole system for SkillTreeLayouts so I could test different kinds and the vision was to have a procedural skill tree, kind of like Dead by Daylight’s blood web system, but a hybrid approach between that and Path of Exile.

This led to creating different layout algorithms, like the ClusteredCircleLayout that would position skill nodes in organized clusters, connecting them based on proximity and logical relationships.

Each zone had its own progression system, with skills that persisted even after prestiging. The zones themselves were visually distinct environments, from the peaceful Starter Creek to the treasure-laden shores of Pirate Paradise.

The AI Asset Pipeline: Crafting Digital Ecosystems

One of the most enjoyable aspects of development was creating the visual assets and game content using AI. This might seem at odds with my preference for automation—after all, prompt engineering and curation is still manual work—but it created a new kind of craftsmanship that I found deeply satisfying.

Take the Longbeard Oracle fish, for example. This fish was meant to be a Gandalf-inspired legendary catch in the Misty Mountain zone (itself a Lord of the Rings reference). The creation process involved multiple iterations:

The first iteration was based on a prompt that described “an aged, wise-looking fish with a body that fades from a deep, earthy brown to a pale, off-white on its belly” with “a long, flowing beard of algae.” The result was serviceable but lacked the magical quality I wanted.

The second attempt leaned more into the wizardly aspect, with a prompt describing “a venerable fish with a body that fades from a deep, slate grey to a bright, almost blinding white” and a beard “occasionally crackling with small sparks of arcane energy.”

The final version took a more fantastical approach, describing “an ancient, ethereal fish with a body that shimmers with an opalescent, pearlescent sheen” and eyes “like twin galaxies, swirling with nebulae of light.”

This iterative process was repeated for dozens of fish, each with their own unique characteristics and visual identity. The zone backgrounds went through similar refinement:

Behind these visual assets was a sophisticated data-driven system. JSON files defined each fish, artifact, and skill, with detailed attributes that would be loaded into the game at runtime. This allowed for rapid iteration and easy expansion of the game’s content.

{
  "lucky_charm": {
    "name": "Lucky Charm",
    "description": "Every 10th catch is instantly reeled in!",
    "rarity": "common",
    "passive_boosts": [
      {
        "type": "instant_catch_periodic",
        "catch_interval": 10,
        "description": "Every 10th catch is instant."
      }
    ]
  }
}

Wave Function Collapse: A Square Peg in a Round Fishing Hole

I really just wanted an excuse for using WFC in a project, so I kind of shoe-horned it in. It’s not super appropriate for loot systems as it’s normally for tile-based decisions where you look around this tile for valid options based on rules.

WFC is typically used for procedural generation of spaces—creating tile-based worlds with coherent patterns. Adapting it to serve as a loot system required some creative thinking. The goal was to create dynamic loot collections that could adapt based on player upgrades and artifacts.

For example, if you obtained an artifact that gave you two fish when you caught one, or that converted garbage into fish tokens under certain conditions, the WFC system could incorporate these rules without requiring hard-coded logic for every possible combination.

This created a more organic feeling of progression, where new artifacts and skills could genuinely change how the game systems interacted with each other.

The Unfinished Symphony: When Systems Outpace Completion

The project is at a point where I’m done building the fun systems, now I’d need to finish polishing and testing and tweaking and fixing and it’s less attractive.

The remaining tasks—implementing Steam SDK, setting up achievements, creating store pages, marketing—lack the intrinsic satisfaction of designing elegant systems. They’re the necessary but “unsexy” parts of game development that stand between a cool prototype and a shipped product.

The difficulty in finishing the project highlights an interesting dilemma in my development philosophy. While I want to ship a completed game, the final steps present a psychological barrier.

I do want to ship a finished game, the problem is most of that part is not attractive. It would be implementing something like the Steam SDK, adding achievements (fun part), testing achievements (not fun part), setting up the store page, doing marketing, gaming wishlists etc.

There’s an irony here that isn’t lost on me. As someone who abhors manual processes and loves automation, I created a project that would ultimately require significant manual effort to complete. The very systems I built to avoid tedium created new forms of necessary work.

Lessons Learned: Value in the Unfinished

Despite not reaching the finish line (yet), this project taught me invaluable lessons about game design, data structures, and my own creative process:

1. Loot systems have many implementation approaches: The experiment with WFC opened my eyes to alternative methods of creating dynamic loot tables that respond to player progression. Rather than relying on simple weighted randomization, I discovered ways to create context-aware loot that changes based on both the player’s choices and their environment. For example, in one area, the system would generate more garbage items when fishing near certain visual elements, while in another, a persistent skill might increase the chance of rare fish appearing when you’ve already caught a certain number of common ones.

2. Data-driven design simplifies iteration: Building a robust data layer that powers game objects made adding new content remarkably straightforward. By moving all fish, artifact, and zone definitions to JSON files, I could add a new legendary fish or artifact without touching a line of code. This pattern extended to the zone backgrounds and descriptions as well—adding a new fishing location was as simple as creating a JSON entry and generating the associated graphics. When balancing the game, I could tweak drop rates and progression curves by changing a few values rather than hunting through code.

3. UI subsystems need careful architecture: Creating interfaces like the skill tree required sophisticated subsystems, including a separate SubViewport with its own camera for zooming and scrolling. This taught me about Godot’s rendering pipeline in unexpected ways. The skill tree camera needed independent movement controls from the main game, with its own input handling layer that wouldn’t interfere with other systems. This same pattern ended up being reused for the collection log view, saving development time and creating a consistent feel across both interfaces.

4. AI asset creation requires its own workflow: What began as an attempt to automate content creation evolved into a specialized craft of prompt engineering and curation. Working with multiple generations of fish required developing a systematic approach: create initial prompts with Gemini, refine them based on results, then experiment with style variations. For the Misty Mountain zone’s fish, I created a family of related prompts that ensured the fish from that zone shared visual elements while remaining distinct. This required developing prompt templates, tracking successful prompt patterns, and creating an organized tagging system to link AI-generated art with its corresponding game assets.

5. Self-knowledge is the most valuable outcome: Perhaps the most important realization was understanding my own creative tendencies and what motivates my development process.

I think I’m honestly just a system builder and need either someone else or some other kind of impetus to finish the unsexy parts of projects.

There’s a certain beauty in unfinished projects. They represent pure creative exploration unconstrained by market demands or user expectations. While I still hope to eventually complete this game, I recognize that the systems I built and the lessons I learned are valuable regardless of whether it ever appears on Steam.

In the meantime, I’ll continue to be fascinated by the paradox at the heart of idle games: the satisfaction of getting something for nothing, earned through the considerable effort of building complex systems that create the illusion of effortlessness.

The Cutting Room Floor: AI Art Bloopers

While the final fish designs underwent careful selection, the AI art generation process produced plenty of curious outcomes along the way. For every polished creature that made it into the game, there were several that… well, let’s just say they took a different evolutionary path.

These “creative interpretations” highlight both the power and peculiarity of AI image generation. Sometimes the models would misinterpret prompts in fascinating ways – adding extra eyes, merging concepts unexpectedly, or creating anatomically improbable creatures.

While they didn’t fit the cohesive aesthetic I was aiming for, these oddities became a cherished part of the development process – little breadcrumbs marking the path of artistic exploration and happy accidents that sometimes sparked ideas for entirely new creatures.

More of Me

Sometimes I write about things I've built and topics that interest me. This is how you get more of that.

Subscribe