Coder Legion - Recent posts tagged devlog

Evening the Terrain & the construction of Road Infrastructure | UE5 Devlog

Wed, 14 Oct 2026 23:23:34 +0000

In this devlog, I continue shaping Kazuhara Resort by evening out the terrain and building its road infrastructure in Unreal Engine 5. The focus is on preparing the ground and creating routes that connect the resort’s different areas.

I showcase the Flatten and Smooth tools to level uneven surfaces and soften transitions, the Ramp tool to connect different elevations, and the Landscape Paint tool to define the road surfaces. These changes help establish the resort’s layout and make the terrain more practical for further construction.

DevLog 20261007: A Detective Story - First Satisfying Full Playable Build

Wed, 07 Oct 2026 17:56:21 +0000

Overview

I've always wanted to develop a video game — in fact, many of them. A Detective Story is far from the first attempt at Methodox; several earlier projects stalled along the way (you can still catch a glimpse of one in Codename Wayhome).

As we set out to build Divooka — a general-purpose visual programming system — the ability to create even a simple 2D game became an essential touchstone. So the game was never just a game.

Motivation

The idea for A Detective Story grew out of our work on Methodox ChatGateway, a RAG-based knowledge engine we were running as an online service. Behind the scenes we were also spending a lot of time with locally hosted LLMs and general knowledge-base applications. The underlying technology isn't new, but none of the existing solutions quite met my requirements. Most are poorly organized and extremely heavy in (Python) dependencies. I could talk about my complicated relationship with Python for hours — the love and, mostly, the hate — but one principle I value above almost everything else is portability and compactness in local software.

A complete RAG knowledge-base solution shouldn't be much larger than the knowledge source itself. That's the bottom line.

As with so many other things we build for Divooka, the best way to prove what the platform can deliver is to find a real application for ourselves and push it as far as we can. That led us to the idea of Crime Engine.

On a Reusable, Configuration-Based Detective Story Game Engine

Crime Engine is a 2D detective-story game engine with fully configurable maps and characters. Players interrogate suspects using natural language, powered by locally hosted models through llama.cpp.

The setup is deliberately lightweight. It supports the major flavours of GGUF-based SLMs and includes built-in RAG. On the gameplay side we have map navigation, fully functional menus, story backgrounds, interrogation rooms, and a verdict screen for concluding a case. There are also interactions with NPCs on the streets in map view, item discovery, and item exchange.

The item-exchange system turned out to be the trickiest piece. It may simply be a limitation of current local models, but I still don't find locally hosted LLMs reliable enough for consistent tool use.

The Development of A Detective Story

We announced the Steam “Coming Soon” page with a trailer back on 6 March, yet we never felt confident enough to release. Three main challenges kept holding us back:

Graphics quality — Much of the art was AI-generated with manual adjustments, but the overall integration still fell short of the standard we wanted.
NPC behaviour and tool use — The item-exchange mechanic is genuinely interesting, but relying on an LLM for reliable outcomes proved difficult. We eventually solved this by scouting a stronger SLM.
Plot completeness — Closely related to the point above: because LLM responses are hard to control tightly, it was tricky to guarantee that players could smoothly finish the game with all the necessary clues. Of course, Divooka remained our primary focus, so we couldn't pour unlimited effort into fine-tuning the plots.

Plot Work

This is still an experimental game and a tech demo for the engine, yet we wanted it to feel like a coherent little story we could build on later — expansions, a series, that sort of thing. As we kept working, the characters became more polished: Ronan, Jack, Lady Garba, Helen, and the rest. It turns out it's simply fun to dwell in fiction once in a while.

Even though it's a small 2D title, we ended up planning a surprisingly large set of graphics assets and subplots worth exploring. We originally sketched a gigantic cast of almost 500 NPCs, then deliberately shifted toward fewer, more personalized characters instead of a generic population.

Release

Major improvements since the earlier builds include:

Significant engine work — better NPC stability, improved tool use, and far more thorough internal (automated) testing.
Noticeable graphics upgrades.
A full GUI overhaul using our proprietary framework ShadowGUI. All Divooka users will benefit from this soon enough.

I did a final playtest today and, for the first time, the game felt genuinely enjoyable, smooth, and fun. It's almost ready to go.

We plan to release A Detective Story first while we continue polishing Crime Engine itself. It will be a while before CE is generally available.

References

2026-10-03 Graphics Update Announcement

Ragdoll Physics Issues | UE5 Devlog

Tue, 06 Oct 2026 14:02:45 +0000

While implementing player death and ragdoll physics, I ran into a persistent Chaos physics issue. The death system and ragdoll activation work correctly, but once the body hits the ground, it begins violently twitching, bouncing, and rotating, sometimes appearing to push through the Landscape.
I tested several potential causes, including terrain collision, CCD, impact velocity, physics simulation nodes, modular mesh collision, damping, collision presets, and constraints, but the instability remained.
During debugging, I also discovered that I had initially been troubleshooting the wrong Physics Asset. After switching to the correct one, the issue still persisted.
The current investigation is focused on the Physics Asset's collision bodies and whether overlapping or conflicting bodies are causing Chaos to continuously apply forces to the ragdoll.
Death system: working
Ragdoll activation: working
Possessed inflatable tube-man physics: still under investigation

Player Illumination Systems | UE5 Devlog

Tue, 29 Sep 2026 18:01:15 +0000

In this devlog, I’m showcasing the Flashlight, Lantern, and Battery Systems I’ve built for my game in Unreal Engine 5 using Blueprints.
Both light sources are fully integrated with the inventory system and can be equipped, used, dropped, and swapped. The flashlight and lantern each maintain their own battery level, while the UI displays the remaining charge of the currently equipped light.
The system also handles switching between the flashlight and lantern, including correctly shutting down the previous light, stopping its battery drain, and transferring control to the newly equipped device.
Systems showcased:
Flashlight system
Lantern system
Battery consumption
Independent battery levels
Battery UI and status display
Inventory integration
Flashlight to Lantern swapping
Equip and unequip logic
Light activation and deactivation
Battery drain timers
This is part of the ongoing development of my game, where I’m building the gameplay systems step by step in Unreal Engine.
More development updates and system showcases are coming soon!

Interaction Awareness System – Custom Depth & Icon Widgets | UE5 Devlog

Tue, 29 Sep 2026 18:01:01 +0000

In this development log for Life of Alex, I’m showcasing the interaction awareness system I’ve built to help players identify objects they can interact with naturally while exploring the world.
The system combines icon widgets with custom depth shaders, allowing interactable objects to provide clear visual feedback without overwhelming the screen or breaking immersion. Icons help communicate available interactions, while the custom depth effect highlights relevant objects and makes them easier to distinguish from the surrounding environment.
This system is part of my ongoing work on making exploration and interaction in Life of Alex feel intuitive, responsive, and visually consistent.
Life of Alex is currently in early development, so everything shown is still subject to change as the project continues to grow.
Follow the development journey for more systems, environments, gameplay mechanics, and behind-the-scenes progress.

DevLog 20260919: Upcoming Fantasy Planet Painter 2.0 and the Making of It

Sat, 19 Sep 2026 15:03:37 +0000

Fantasy Planet Painter

Whole-planet-scale fictional world-building: continents, mountain ranges, rivers, valleys, and features as small as individual hills. Maybe eventually trees, buildings, houses, roads, and cities too?

That has always been roughly the idea behind Fantasy Planet Painter (FPP).

Making a good-looking fantasy map is one part of the goal, but the longer-term idea is more ambitious: making an entire fictional planet something you can actually author, organize, inspect, render, and use.

With the upcoming Fantasy Planet Painter 2.0, we are finally starting to build more seriously toward that idea.

The Beginning

FPP had a rather humble origin: I needed to create a world map.

Naturally, I started with GIS software. First ArcGIS, then QGIS, and along the way I learned my way through map projections, layers, coordinate systems, GeoServers, and all the other fun stuff that comes with GIS.

GIS is incredibly powerful, but for making a fictional planet from scratch, the workflow was not particularly efficient. I wasn't really trying to analyze an existing world; I wanted to sit down and make one.

Eventually I came across Torben Mogensen's planet program (planet.exe on Windows). It was rather eye-opening because the program works on an entire spherical planet at once instead of treating the world as just another flat image.

The underlying terrain generator uses recursive tetrahedral subdivision to produce planetary terrain, and it can render the generated planet using many different cartographic projections. That became the technical foundation from which FPP originally grew. We later ported the original code to C# and gradually modernized and extended it.

The Start

The first practical problem was obvious: planet.exe is essentially a command-line program, and custom maps are represented through text-based input.

That is powerful if you already know exactly what you want to type, but not particularly convenient if you are trying to draw a world.

Before FPP, I even made several small command-line utilities for operations such as moving and scaling cells around. It technically worked, but authoring by repeatedly modifying parameters, rendering an image, looking at the result, and trying again was painfully inefficient.

So the first major goal became exposing all of this through a much more usable graphical interface.

That took much longer than expected.

The original code is quite old and was never designed with this kind of interactive editing workflow in mind. Adding a GUI was therefore not simply a matter of putting some buttons around it. Rendering, state management, editing, visualization, save files, projections, cross-platform support, and eventually performance all had to be integrated around the original generator.

Version 1.0 was really the beginning of that process rather than its end.

Over time we added higher-resolution authoring, more output options, brushes, polygon editing, region selection, map themes, improved rendering controls, and substantial performance work. By v1.4, techniques we had been developing for Divooka - erosion, terrain processing, procedural coloring, texturing, and rendering - also started finding their way back into FPP.

The Road Map

Once you start thinking seriously about authoring an entire planet, a lot of other problems immediately appear.

Some of the major ones are:

Location and region management
Local and regional maps
Countries, cultures, biomes, settlements, etc.
Different levels of detail
Map rendering and map serving
Exporting the same world into other tools and applications

This is why I don't really think of FPP as only a procedural map generator.

A nice-looking map is important, of course. But a fictional world can easily contain thousands of named places and many completely different scales of information. A mountain range visible on a world map may contain hundreds of valleys, rivers, lakes, roads, towns, and individual terrain features that should not even exist at the resolution of the original world map.

That creates an interesting authoring problem.

A single giant bitmap is clearly not the answer. At the same time, splitting everything into unrelated maps loses the fact that they all belong to the same world.

Our original public roadmap already described Version 2 as Advanced World Editing, beginning with location management, followed eventually by better brushes, color control, biome editing, 3D worlds, roads, and cities. The exact implementation has changed quite a lot since that roadmap was written, but the overall direction has not.

The important part is that FPP needs to gradually move from "a program that generates a picture of a planet" toward "a program that understands the things making up that planet."

Feedback and Improvements

There haven't been many direct comments on the Steam community page so far. FPP is still a small and fairly niche product.

Refund information, however, gives us another source of feedback, and the pattern is fairly understandable: people want more power, more detailed editing, and more features.

None of those are particularly surprising.

They correspond closely to limitations we were already aware of in Version 1.x. FPP became quite good at quickly establishing the large-scale shape of a planet, but there is a substantial gap between sketching continents and actually authoring the world inside those continents.

That feedback has helped us decide which parts of the longer-term roadmap should move closer to the front.

Version 2.0

There are three big areas we want to address at the beginning of Version 2.0:

World regions
A new custom spherical tetrahedral-subdivision system with real-world physical units
Major mapping, editing, theming, and rendering improvements

The first one is perhaps the most important structurally.

Regions give us a way to start treating parts of the world as actual objects rather than just pixels or height values. Once regions exist properly, a lot of other ideas become much easier to build around them: locations, countries, biome areas, local maps, selections, metadata, exports, and eventually much more detailed world-building information.

The second area goes much deeper into FPP's original foundation.

The new subdivision system is also closely tied to another important change in 2.0: the metric system. FPP now operates using real physical units, with distances and elevations represented in meters rather than abstract map values. A planet can have an Earth-scale radius, mountains can genuinely be several kilometres high, and distances between locations can be measured and discussed precisely.

This sounds like a relatively small change, but it makes world-building much more practical. Terrain, regions, local maps, roads, settlements, and eventually buildings can all exist within the same physical frame of reference instead of relying on arbitrary scales that change depending on context.

The tetrahedral subdivision approach has served FPP very well, but we are now experimenting with our own spherical subdivision implementation and data structures. Having control over this level of the system lets us build that real-world scale directly into the geometry while also making it easier to integrate editing, generation, resolution changes, region handling, and future algorithms without constantly working around assumptions inherited from the original renderer.

And finally there is everything users actually interact with every day: mapping, editing, theming, and rendering.

Version 1.x accumulated many useful features, sometimes rather experimentally. Version 2 gives us a chance to reorganize some of those ideas around a more coherent model instead of continuously extending what was originally a relatively simple world-map painter.

These three areas should provide a much better foundation for extending FPP going forward.

The W2B Project

A surprisingly useful side project in all of this has been World to Beyond, or W2B.

It was originally proposed mostly out of curiosity.

I sometimes play Beyond All Reason with my friend. Well, nowadays he is so good - even though I was the one who first got him into the game - that he no longer plays with me 😟.

At some point he looked at FPP and said that its maps kind of looked like BAR maps, so: couldn't FPP make one?

Visually, the answer seemed like it should be "yes."

Technically, of course, it was considerably more complicated.

BAR uses the Spring RTS engine, and producing an actual playable map means much more than exporting a nice-looking heightmap. Terrain needs to work from a gameplay perspective. You have textures, metal distribution, grass, water, features, map metadata, engine-specific formats, reachability, and all kinds of details that don't really matter when the final output is only an image.

So we made a first attempt, but never really published much around it.

People on Discord also quickly pointed out some obvious weaknesses, particularly the lack of convincing erosion and proper texturing.

Conveniently, those were exactly the kinds of problems we had independently started working on in Divooka.

Over the past year, our terrain work in Divooka has expanded from basic noise generation into erosion, hydrology analysis, masks, terrain coloration, texturing, and eventually PBR terrain rendering. FPP has already started benefiting from some of that work.

So when we returned to W2B, we were in a rather different position.

The new W2B has now been rewritten from scratch. Earlier prototypes required users to provide a template extracted from an existing map, which was awkward both technically and from a redistribution/licensing perspective. The current implementation writes the core Spring map files - .smf, .smt, and mapinfo.lua - itself.

The authoring process has also grown into several distinct stages: source terrain, terrain setup, metal, grass, water, features, and final output. In other words, it is slowly becoming an actual map-making pipeline rather than an FPP export button.

And this experiment is useful for FPP itself.

It forces us to deal with questions that don't appear when creating a world map purely for viewing: Is this terrain navigable? What happens when we look much closer? Where does vegetation belong? How do large-scale shapes survive when converted into local terrain? How should a procedural world turn into something another application can actually use?

Those questions are very relevant to where we want Fantasy Planet Painter to go.

With all the work that has gone into FPP, Divooka, procedural terrain generation, and the first W2B experiment, we are much better equipped this time around.

And the new W2B is already much more powerful - and, importantly, much prettier - than the original attempt.

Going Forward

Fantasy Planet Painter started from a relatively simple problem: I wanted a convenient way to draw a fictional world map.

That problem turned out to contain a surprisingly large number of smaller problems.

Some are mathematical. Some are GIS problems. Some are rendering problems. Some are UI problems. And increasingly, some are really data-modeling problems: how do you represent an entire fictional world in a way that remains editable from the scale of a planet down to individual regions - and where those scales correspond to actual physical measurements?

With 2.0, an Earth-sized world is actually Earth-sized, mountains can be described in kilometres, and distances between places have a concrete meaning. That gives the rest of the world-building system a much more practical foundation.

Version 1.x gave us a functional planet painter.

Version 2.0 is where we start taking the "world-building" part much more seriously.

There is still a lot to figure out, and some of the ideas described here will certainly change as we implement them. But the pieces developed over the past year - especially the work on terrain generation in Divooka and experiments such as World to Beyond - are starting to connect together rather nicely.

We will share more as 2.0 takes shape.

References

DevLog 20260731: FPP v1.4.0 and Divooka Explore Demo Updates

Sat, 01 Aug 2026 18:44:44 +0000

Overview

The past few months have seen several Divooka Explore Demo releases, with our efforts focused on rolling out procedural terrain generation features. These include random noise-based terrain generation, procedural and simulation-based terrain processing, natural effects such as erosion and hydrology analysis, procedural coloration and texturing, and, more recently, improved 3D previews of generated terrains directly within the Divooka visual programming environment.

One small lesson from this cumulative effort is that there always seems to be more academic material, papers, tutorials, online examples, and even source code snippets to discover and use to improve existing systems. That is a shiny silver lining, since we are still fairly new to this domain and desperately need broad exposure to existing techniques.

Another useful lesson is that, although many papers approach these subjects from a real-time rendering perspective - such as the old GPU Gems articles - the same techniques are often equally applicable in a pure-CPU regime.

Procedural Terrain Generation in Divooka

As mentioned, we have made quite a large number of functions available in this area, and the subject definitely warrants much more detailed treatment. Documentation and comprehensive video guides are dearly needed.

To recap, we have moved from very basic noise-based terrain generation to custom heterogeneous multifractal terrains, functional erosion - although there is still plenty of room for improvement - various masking techniques, practical procedural coloring using either masks or SQL queries, and preliminary texturing support.

The terrain generation is only the first step, and there is still plenty of room for improvement despite we have achieved useful basic implementation for now.

Once we became comfortable with generating functional procedural terrains, we could move on to coloring, texturing, and eventually shading.

At this point, I realized a fundamental limitation of heightmaps and image textures. They may be able to represent distant views of terrains spanning 8–64 km when viewed from above, but for ground-level rendering, procedural shading techniques are a must.

The 3D rendering work is still new, and there is a long way to go. We started with basic baked shadows, moved on to experimental texture mixing, and eventually reached full PBR rendering.

PBR rendering is the holy grail. Once we figure out how to dynamically populate terrains with trees, grass, and rocks - and generate ripples across reflective water - we will be able to share all of it through Divooka as reproducible workflows!

Below is an intermediate result so far. It uses simple slope-based texturing, which we plan to replace with mask-layer-based materials in the next attempt.

We have learned so much and cannot wait to share more about the specific techniques once we have more spare time!

The Fantasy Planet Painter v1.4.0 Update

While the eventual goal is to support whole-planet procedural generation and content management, we began with basic Earth-like world map generation. At the moment, our work is mostly focused on improving the existing editing experience. The previous update significantly improved the multithreaded generation performance of the tetrahedral subdivision method.

The 2D cell-based height-value canvas is an interesting medium. It allows us to sketch the desired elevation levels quickly at a high level while the program procedurally populates the remaining details.

There has also been some experimental exploration into using this medium for direct 2D terrain editing, as seen in our previous video, World to Beyond (BAR map export from FPP). Although BAR export is still in its early stages, the potential of this kind of authoring technique is indeed interesting.

Following the advances in procedural terrain generation within Divooka, we have gathered quite a collection of useful tools and made them available at a high level in the latest FPP update.

The results are very interesting, and I am glad that we are moving beyond practical utility toward generating worlds that - at least in my eyes - are also visually appealing.

Conclusion

That is a brief recap for today. I have been busy diving headfirst into all the nitty-gritty work, which has left less time for DevLog updates and for sharing the techniques and progress behind them.

Still, let us look forward to the day when new results are ready to shine, when we are comfortable placing an early-access version of Divooka into the hands of users, and when we can talk in much greater detail about the road that led us there!

DevLog 20260319: Towards OOP - Document-Level Default Module and Module-Level Members and Behaviors

Thu, 19 Mar 2026 20:31:07 +0000

Revisiting Flappy Bird – The Pain Point

Remember our Flappy Bird example from mid-2025?

The long chain of variable initializations was needed for two main reasons:

No way to declare variables before using them
More critically - no way to define custom data structures that could group related values together and be instantiated with a single node.

In retrospective it seems obvious: we just need proper structured data containers. But building the scaffolding to support this properly in a visual, node-based system is a bit more involved.

Searching for a Solution

I spent a long time trying to bring OOP concepts into Divooka. A huge amount of effort went into DiOS (Divooka Open Standards), with the hope that a complete standard would naturally solve these kinds of problems. But standardization work is slow and deep - just like making Divooka itself feature-complete.

Then, while working on something completely unrelated and taking a short break from this topic, it suddenly clicked.

The key insight: start simple and approach it from a functional/declarative angle first, before jumping into inheritance, encapsulation, polymorphism, and all those good stuff.

I'm really excited - we finally have meaningful progress.

The Divooka Way

To claim our goal as "everything is a node" is a bit too strong, but I strongly prefer keeping almost everything on the graph.

This aligns with how we already handle structured primitives - direct value setting of compound inputs. That way, there's still hope that users can drop down to raw node programming when they need full control (and thus keep everything programmable).

Traditional property panels (like Unreal Blueprints' object definition GUIs) are out - they break the pure graph paradigm.

Instead, the solution is declarative, similar to how TerraGen works: the mere presence and connection of certain nodes defines meaning.

This feels awesome for several reasons:

We can make full use of the 2D graph layout - place things exactly where we want them visually
It stays completely coherent with Divooka's graphical paradigm
No need for separate "class editor" UIs

What's Been Implemented So Far

Current working pieces:

Graphs can now act as modules
Support for module-level data members and behavior members
A main module tied to the document, with existing graphs serving as associated behaviors

Module-scoped instance node – in Events context

Module-scoped instance node – in Dataflow context

Top-level module behavior graphs

This immediately unlocks:

Clean access to (top-level) module instances
Shared event and dataflow instance data
A unified programming and document model for subgraphs (still a work-in-progress)
In procedural contexts (Glaze! especially): we now have proper data containers - no more awkward giant variable lists or forced tuples! (Compare to the old Flappy Bird screenshot)
Much simpler and more natural state storage/access in Glaze! and procedural graphs

This is a big deal - for a system that's gearing up for real production use, it feels like crossing a major milestone in usefulness and core abstractions.

Current Limitations & Remaining Work

Still plenty to fix/polish:

A bunch of bugs and edge cases
Proper serialization support
Smooth context switching between graphs
Subgraph consolidation / better nesting UX

Looking Ahead

This is a solid foundation, but there's still a long road:

Full modularization support
Modules inside modules (nesting)
Module inheritance / composition patterns / polymorphism
Base DOM exposed as the "main module" for metaprogramming API
Detailed documentation: how it all fits together, recommended usage patterns, expected behaviors, pitfalls
Module-level scoped instances (deeper/finer control)

Overall - I am very happy with the direction. It feels like Divooka is finally getting the abstraction power it deserves while staying true to its visual, graph-first philosophy.

I am hyped for what we will achieve.

References

DevLog 20260224 Divooka - Node-Level Automatic Dispatch (Runtime Execution Behavior)

Tue, 24 Feb 2026 22:22:17 +0000

Overview

Anything useful done with a program eventually involves file I/O and some form of repetition.

In Divooka, the dataflow context already makes it very easy to "just get a single thing done." That part feels good. But handling loops? That's where things start to get awkward.

One challenge lies on the GUI side — especially around lambdas and subgraphs. We do have foundational support (as shown here and here), but let's be honest: it's not smooth yet.

So the question becomes: how do we make repetition feel natural without introducing heavy conceptual overhead?

The Plan

There are several well-established ways to achieve looping behavior in a functional or visual programming context:

Subgraph context - Used in tools like Blender, vvvv, and Houdini. A specialized node group or frame defines loop entry and exit boundaries.
Lambda callbacks - Evaluation is handled via callback-style execution.
Expressive recursion - As seen in text-based functional languages, requiring explicit termination conditions to avoid stack overflow.

All of these approaches are powerful and necessary in certain contexts. But they also introduce additional constructs into the language model. For advanced workflows, that's fine. For simple operations, it can feel unnecessarily complex.

I wanted something lighter.

Array Coercion

Divooka already supports Array Coercion — a scalar value can be passed into an input expecting a collection.

This avoids the need to manually "wrap" a scalar into an array just to satisfy a function signature - I still remember the pain of handling arrays in Unreal Blueprint.

Scalar-to-array coercion keeps graphs clean and avoids clustering.

To take this to the next level, I've been giving it much thought on how the reverse might work: if we can coerce scalars into arrays — what if we also let nodes automatically dispatch when arrays are passed in?

Automatic Dispatch (Node-Level)

The core design question was:

Should an array input implicitly turn the entire downstream chain into a loop?
Or should the dispatch behavior stay localized to the node itself?

Eventually it seemed localizing things to the node made far more sense.

For example:

string String.Replace(string, string, string)

If any input is provided as an array instead of a scalar, the node automatically promotes itself to:

string[] String.Replace(string[], string[], string[])

The node executes element-wise.

Now, I can rename a folder of files with roughly three nodes:

Enumerate files
Regex replace
Rename file

No explicit loop node. No subgraph. No lambdas.

In this example, Duplicate as Array returns a strongly typed string[], enabled by generics support.

One important rule: All array inputs must align in size with the source array. The dispatch is index-based and deterministic.

Full Example

What used to require explicit iteration logic now becomes implicit behavior at the node boundary. The graph remains readable. The mental model stays simple.

Conclusion

This is still early work. Integration with the rest of Divooka's features is ongoing, and edge cases are being worked through.

So far so good.

DevLog 20250728: Multi-graph Navigation GUI

Tue, 29 Jul 2025 17:19:46 +0000

Overview

From the beginning, we've expected Divooka documents to support multiple graphs for efficient daily use. I consider this essential for scripting purposes, as dealing with file system entry references should be the last thing on our minds when trying to get something done quickly.

However, implementing this isn't straightforward. Several interesting and foundational features are required first: serialization, file format support, editor refactoring - and graph referencing, which we may discuss in a future entry.

In traditional programming languages, especially object-oriented ones, similar functionality is often achieved by allowing multiple classes per file. In C#, for example, it's even possible to define partial classes across separate files, which can become confusing if not managed carefully.

Objective

When working with multiple graphs in a single document, the experience should feel similar to working with separate documents that each contain a single graph. At the most basic level, the editor should allow quick and seamless switching between graphs. More advanced features will come later. For example, storing multiple graphs within a single document should eventually enable referencing those graphs or documents from other documents.

Implementation Progress

Today's goal was to support navigation and switching between different graphs in Neo.

Preliminary work on refactoring the graph editor into a reusable component was already completed earlier. This refactor is also crucial for enabling the subgraph editing window.

To maintain context when switching graphs, the current viewport remains unchanged. We've also implemented a mini-map to help users quickly identify their location within the graph.

Minimap Behavior

The math behind the minimap is a bit tricky, so it's worth documenting:

When switching between graphs, the editor should either preserve the current viewport (location and zoom) or reset the view to the center of the new graph.
A "world boundary" must be calculated that encompasses all nodes in the graph.
A "viewport boundary" should also be calculated to represent the currently visible area of the canvas.
The minimap scale (typically less than 1 to represent downscaling) should be the minimum of:
- minimap size / world size, or
- minimap size / viewport size, if the viewport is larger than the world (e.g., when zoomed out).

Other Matters

The Neo graph editor is taking noticeably longer to load lately. We may need to investigate and address performance issues soon.