Coder Legion - Recent posts tagged methodox

DevLog: 2026-10-15 A Detective Story - Making It to The Release.

Fri, 16 Oct 2026 02:41:59 +0000

Overview

A Detective Story is a compact detective simulator that brings natural conversation to the heart of interactive fiction, where you can interrogate NPCs using natural languages - as they are powered by LLMs (well, SLMs to be precise).

A murder has taken place in the sunlit seaside town of Baytown, where everyone has a story. Question suspects, explore the town for clues, and test their alibis against the evidence. You may have only three days to solve the crime - and there may be more than one murderer!

Development Experience

Making a game is very different from building an app - or any other kind of software, for that matter. I don't think I've ever worked on a software project where even the smallest incremental improvement could feel so difficult.

Ironically, even though engine and gameplay development consumed nearly 80% of the development time, I'd still call it the "easy part" of the whole endeavor. Designing the story, integrating the graphics, and, most importantly, making sure the mystery is actually solvable - those turned out to be challenges that go well beyond the usual technical maneuver.

Reception

The initial trailer, despite its relatively simple graphics by today's standards, felt quite intriguing to me. The idea of fully integrating LLM-powered NPCs into a game is certainly nothing new, but it's still rarely seen in actual games.

I even told my friends that A Detective Story might end up being more popular than Fantasy Planet Painter. Both are niche titles, but ADS seemed more approachable and appealing to a broader audience.

Reality, however, told a different story. The game attracted relatively little interest during its first few months, which eventually led me to scale back the time and effort I was putting into getting it released.

Revival of Effort

With Divooka approaching maturity and preparing for its public release later this year, it's time to revisit and refine the integrated LLM capabilities within the Divooka ecosystem, particularly features such as RAG and knowledge base management.

ADS runs on Crime Engine, which itself is built upon components from Divooka, making it a natural testing ground for these capabilities.

On a more personal note, I also have other game projects in mind for Methodox. However, Project Aegis has made little progress, and Codename Wayhome remains a prototype. At some point, I really need to get a game across the finish line. Otherwise, I'm not sure I'll have the courage to embark on yet another game project!

The Things I Am Still Not Satisfied With

I suppose this is something every creative endeavor struggles with. I wish we could polish the scenes a little more, make the story more vibrant, bring the characters to life, and make our little fictional town feel more realistic and expansive. The list goes on and on. But we can't stay hidden forever. At some point, when things are good enough, we have to let our creations out into the world and see how they fare. Perfection is a difficult goal to chase, and perhaps an impossible one to reach.

On the model side, I can't honestly say the conversation experience is optimal yet. NPCs can sometimes be overly restrictive or reluctant to reveal information, making it unnecessarily difficult for players to piece together clues and solve the mystery. I suspect the best long-term solution might be to train a custom model specifically for this kind of interaction, perhaps taking inspiration from how Character.AI approaches conversational characters. That's certainly something worth exploring further.

Remarks

I'll share more about the technical side of using AI in game development in a future post.

References

Fantasy Planet Painter 2.0

Tue, 13 Oct 2026 17:57:24 +0000

Fantasy Planet Painter 2.0 is here! This is our biggest update so far: a completely rebuilt application, a new physical terrain system, richer rendering, layered painting, fantasy world layers generation, and a much more capable World to Beyond integration.

The Basics: From a Sketch to a World

In our earlier introduction to 2.0, we shared a first look at where Fantasy Planet Painter was heading. Now we would like to take a closer look at what you can create with this release.

Fantasy Planet Painter started with a simple approach to world-map creation: paint the broad shape of a world on a cell grid, and a procedural algorithm generates the details. A creator focuses on where continents, oceans, and mountains belong without having to draw every terrain detail.

That idea remains at the heart of 2.0. What has changed is how much more you can do around it. Heights can now have a physical meaning. Terrain can be built in layers. A painted planet can become an atlas of countries, cultures, settlements, and roads. And jump into very specific region of a world with additional details. After you are done experimenting with the shape, you can export the map and interactively play in Beyond All Reason.

A New Physical Planet

The new Physical World generator works with elevations measured in meters, and provides broader control of flexible height ranges, with 12 levels by default. This gives you finer control over the relationship between your painted terrain, the generated detail, and the sea.

Continuous elevations: paint specific heights, from deep ocean floors to mountain peaks, with twelve customizable paint bands to keep everyday painting approachable.
Independent sea level: explore how changing the water level reshapes your coastlines without repainting the whole planet.
Planet size and relief: adjust the planet radius and the strength of its terrain, with procedural detail that takes physical scale into account.
Seed control: keep a result you like or try a different realization of the same broad geography.
Painted terrain alone: turn off the added procedural detail when you want to see the heightfield you have authored more directly.
Terrain operations: set, add, multiply, reshape with a power curve, smooth, normalize, terrace, or invert elevations. Operations can target land, water, or the whole canvas, and work with selections; coast preservation is available where appropriate.

There are also (experimental) fourteen editable preset terrain recipes, including Volcano and Fractious, for exploring different starting shapes. Recipes combine a seed and density with editable generation instructions, can be previewed before applying them, and can be retained with a terrain layer. They are useful both as starting points and as material to paint over.

More Ways to Create Your World

A world can feel very different as an atlas, a globe, or a view looking across its surface. 2.0 expands the rendering tools so you can explore those differences without rebuilding your geography.

Physical terrain colouring: elevation, slope, and climate views, alongside the familiar classic palettes. Latitude can influence the appearance of the land and polar regions.
Terrain lighting: cast shadows, sky occlusion, adjustable sun direction and height, and shading exaggeration to bring out the shape of the landscape.
A rendered 3D view: look toward the terrain from different distances and angles, with atmosphere, ocean, and volumetric clouds. Adjust cloud coverage and height to change the mood of a scene.
Geographic guides: latitude and longitude grids, plus a kilometre scale tied to the size of your planet.
Live previews: see updates while painting, with background rendering, progress feedback, and cancellation for longer renders.
A clearer connection between canvas and preview: the viewport outline helps you keep track of the area you are looking at when working across projections.

The eleven map projections are the same Equirectangular, Mercator, Orthographic, Gall–Peters, Mollweide, Interrupted sinusoidal, Stereographic, Gnomonic, Icosahedral, Equal-area azimuthal, and Conical. Use them to compare the same world from different perspectives, or choose the one that suits your finished map.

Painting, Layers, and More Space to Experiment

The painting workspace has been rebuilt around a more flexible canvas and terrain layers, allowing a non-destructive workflow. This allows you to manage different features and separate terrain changes from exiting shapes, such as trying a different mountain range, or hiding a layer to compare different versions of your geography.

Layer controls: add, name, reorder, hide, lock, and remove terrain layers. Transparent areas and the eraser reveal what is underneath.
Direct and shaped painting: Point, Box, Circle, and Polygon tools for everything from a single cell to a whole landmass.
Soft and blending brushes: shape transitions with Linear, Smoothstep, Quadratic, Cubic, Exponential, or Gaussian falloff.
Two kinds of fill: fill a connected neighbourhood or replace matching heights across the canvas.
Selections: isolate part of the map for painting and terrain operations, or move selected geography.
Canvas transformations: raise or lower terrain, shift with wrapping or clipping, flip a map, and fill areas.
Grid controls: resize, expand or shrink the canvas, and double or halve its resolution.
Painting conveniences: zoom and pan, preview the brush footprint, and pick an existing height from the canvas.
Undo and redo: revisit strokes and other changes through the history, with clearer handling of unsaved work.

Several of these tools grew through the 1.x updates. They now sit together in a workspace designed for the larger range of things a 2.0 world can contain.

Build a Fantasy World to Suit Your Terrain

Once you have a Physical World you like, world layers can develop it into a fantasy atlas. Choose the number of countries and settlements, the map detail, and a presentation style, then generate a world that follows your geography.

This can add biomes, rivers, lakes, countries, borders, cultures, religions, provinces, settlements, place names, and roads. Building the atlas leaves your painted terrain intact, and rebuilding can be undone if you prefer the previous result.

Different map presets let you explore different sides of the same world:

Political: countries, borders, towns, rivers, and roads.
Cultural, Religions, and Provinces: the people of the world, their beliefs, and its internal divisions.
Biomes, Physical, and Heightmap: the landscape, climate zones, ice, and elevation.
Temperature, Precipitation, and Population: climate and patterns of habitation.
Goods, Trade, and Military: resources, markets, trade routes, and armies.
Emblems and Points of interest: heraldry and places worth a journey.

You can also switch individual overlays on and off to create your own combination. Changing what is shown does not regenerate the world, so you can move between a political map and a climate map while keeping the same underlying geography.

For your own landmarks, named world locations let you mark locations and retain their names and coordinates as you change projection. A useful way to start making the world yours is to name the first island, mountain, or city that catches your imagination.

A World with Many Styles

World layers come with fifteen presentation styles: Atlas, Parchment, Ink, Climate, Ancient, Political Atlas, Clean, Cyberpunk, Dark Seas, Gloom, Light, Monochrome, Night, Pale, and Watercolor.

Each changes the colours, lettering, and linework while keeping the geography in place. The same world can become a restrained reference atlas, an old parchment chart, a dark ocean map, or a softer illustrated view. You can explore the styles without committing to a new generation of the world.

When it is time to share your work, export the terrain and visible world layers together as an image, or take the world layers out separately as vector SVG or transparent PNG. Vector exports include shapes and outlined lettering, with optional legend and scale, for further composition in a drawing application.

The .fpp2 document format keeps terrain layers, physical elevations, sea level, seeds and generation settings, named places, and the generated atlas with its presentation. It is the format to use when you want to continue developing a 2.0 world.

Your existing .planet files still open. Legacy export is also available for older workflows, including the bridge to World to Beyond. That export flattens the visible terrain into the original nine height categories, so keep a .fpp2 master to preserve the new layers, places, and atlas.

Other import and export options include:

Heightmap import: greyscale images, colour-to-height mapping, and Terrain-RGB elevation data.
16-bit heightmaps: take continuous terrain elevations into other terrain tools and game workflows.
Painted map images and text: exchange the underlying grid as an image or in the classic text format.
Rendered PNGs: export Physical and Legacy views up to 8K on the long edge, and Flat Land views up to 4K.
Drag-and-drop opening: bring an existing world into the painting workspace.

The rebuilt interface also brings a more adjustable workspace, scrollable palettes, canvas navigation, and built-in help for the main workflows.

Flat Worlds and Familiar Favourites

Physical Planet is the new focus moving forward, but the other ways of making maps remain part of the app.

Legacy preserves the original generator and its nine height categories, eleven projections, and eighteen themes. It is there for returning projects and for anyone who enjoys the original approach.
Flat Land is a useful choice for bounded maps rather than whole planets. It offers 2D and relief views, eight themes, and controls for erosion, hydrology, inland lakes, and the water plane. It can take your work in a different direction when you are thinking about a single landscape or a game map.

Experimental Steam Achievements

We are also adding experimental Steam achievements to bring a little extra fun to using the app. They celebrate creative milestones and encourage you to try different tools, views, painting techniques, and worldbuilding possibilities.

Alongside them is a curated set of achievement illustrations with a stylized look. We hope these small rewards adds a bit more reward to your journey as you explore and create. They are also useful to guide you what to try next.

Achievement support is experimental in this release, and we welcome feedback if an unlock does not behave as expected. Some milestones are tied to capabilities beyond the current public build, so the achievement list will continue to develop with the app.

World to Beyond: A Rebuilt Map Studio

The free World to Beyond DLC now arrives alongside 2.0 with a rebuilt GUI for creating maps for Beyond All Reason and other Spring/Recoil games. The major road block from previous teaser is the now fully integrated map format generator, getting rid of third-party dependencies.

The earlier exporter centred on turning a planet into a map. The new studio workflow gives the other parts of that map their own space: resources, vegetation, water, scenery, and the final output.

Its seven stages cover the complete project:

Source: begin with a painted planet or a procedural map, choose a generation scheme, and set the map size.
Terrain: tune height range; procedural sources offer terrain styles, themes, generation controls, erosion, previews, and playability readouts. Imported heightmaps and ground textures provide further ways to bring in your own material.
Metal: place resources in a dedicated painting workspace, with automatic placement and brush controls including softness and symmetry.
Grass: grow vegetation from terrain rules, then paint over the result to refine its coverage.
Water: adjust the water appearance and judge it against a live coastline sample.
Features: use generated scenery or import .obj, .gltf, and .glb models. Set scatter rules and paint a separate placement mask for each model—for example, trees along a ridge and boulders near the shore—and preview where they will land.
Output: build a complete .sd7 map archive, including terrain, textures, resources, grass, water settings, and scenery, with progress feedback and cancellation.

There is also a real-time 3D viewer for inspecting the terrain, water, vegetation, scenery, resource spots, and start positions before compiling the archive. It currently requires OpenGL 4.3 support and will not work on macOS. And if you are patient enough to read till this line - there are more interactive ways to inspect and play with your map coming in future updates!

Studio projects can be saved as .w2b files, retaining settings and painted channels so you can return to a map over several sessions. Custom model files remain external references, so keep those assets with your project.

Whether you want to turn an unusual planet into a battlefield or just use W2B as a really easy utility to assembly a fully functional BAR map, there is a lot of freedom here.

Availability

Free for existing owners: 2.0 is an update to Fantasy Planet Painter, with the free World to Beyond DLC releasing alongside it.
Windows first: macOS is coming later; we will share more when it is ready.
Updated pricing: the price for new purchases has already changed to reflect the app's progress. Regional prices are shown on the Steam store.
The current build is released with the hope that you could try the new features early on - it may contain many features that we have not tested thoroughly - expect follow-up updates to address rough corners.

References

Steam Annoucement

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

Fantasy Planet Painter 2 - 2026 Launch Trailer

Sat, 19 Sep 2026 01:04:36 +0000

Fantasy Planet Painter is a world building tool/world map editor by Methodox Technologies, Inc. It allows users to paint world maps using coarse pixels at high level while the algorithm generates all the intricate details procedurally. You can simply sketch out your planet’s main features - mountains, valleys, and oceans. Once you’ve laid down the basics, Fantasy Planet Painter steps in to handle the finer details, filling in realistic terrains that bring your vision to life.

The 2.0 update brings refreshed GUI and new world generation capabilities and enhanced editor experience and workflows. Notably, the world regions feature will enable creators to modify detailed terrain regions while still working on a planet-scale canvas.

For anyone who loves creating worlds, whether for stories, games, or just for fun, Fantasy Planet Painter makes it simple. Fantasy Planet Painter gives you the power to craft beautiful, immersive worlds from scratch. It’s your imagination, brought to life, one brushstroke at a time.

Learn more from Steam annoucement!

Methodox Voxel Sandbox | Launch Trailer | Methodox Voxel Scene Viewer

Wed, 26 Aug 2026 18:55:20 +0000

Methodox Voxel Sandbox is a Windows-only voxel world generator, editor and renderer. You can randomly generate a voxel environment, build inside it, then photograph it with a digital camera.

Core Features

Seed-Based World Generation: Automatically rolls and generates expansive voxel environments from a given seed.
First-Person Editor: Walk through the world from a first-person perspective to interact, break blocks, and build new structures.
Progressive Path Tracer (Photo Mode): Renders scenes progressively with light bouncing, glass refraction, metal reflections, glowing objects, clouds, and soft shadows.
Advanced Camera and Image Controls: Fine-tune renders with settings for lenses, lights, quality, exposure, and tone mapping.
255-Slot Material Palette: Build with terrain, vegetation, ores, glass, metal, lights, and full color ramps.

Methodox Voxel Scene Viewer: Included download tool that opens external voxel scenes (such as .vox, Goxel, OpenVDB, and MCEdit schematics) at any scale to render them with the path-tracing engine.

A Detective Story: The Case of The Dead Office Guy (Game Trailer)

Fri, 06 Mar 2026 19:27:09 +0000

Overview

In the quiet town of Baytown, an unremarkable man lies dead under suspicious circumstances. Rumors ripple through the streets. Secrets long buried begin to surface. The whole community is buzzing - some in dread, others gripped by dark fascination.

A Detective Story is a compact detective simulator that brings generative AI to the heart of interactive fiction.

Step into the role of detective in this small-scale murder investigation. Interrogate a cast of AI-powered townsfolk, each with their own motives, fragmented memories, and the potential to lie or mislead. Explore the map to uncover physical evidence and hidden clues. Piece it all together before time runs out.

Game Guide

Your mission: Solve the murder as efficiently as possible - minimize days elapsed and questions spent.
Bringing suspects to the station costs valuable time (days). Choose your interviews with care.
These are informal interrogations - no formal oaths, no truth serum. Witnesses and suspects may deceive, omit, or hide the truth.
You have only 3 questions per interview. Make every one count.
Stay in character for maximum immersion: Ask about alibis, relationships, timelines, strange sightings, and contradictions.
Cross-check stories, hunt inconsistencies, and link conversations to evidence found on the map.

Hardware Requirements

A Detective Story is lightweight and runs smoothly on modest hardware. It requires at least 10 GB of system RAM (DRAM) - with no heavy VRAM demands.

Weekly Update 2026-01-11

Mon, 12 Jan 2026 01:29:36 +0000

This week was mostly about tightening up the foundations of our tools rather than pushing new features. A lot of our older experiments were starting to show their age, so we spent time cleaning things up and getting the core systems into better shape.

What Happened This Week

Refactoring Neo + Parcel NExT review

We continued working through refactors on Neo and reviewing the Parcel NExT implementation. Some of the earlier experimental frontend work had spread across multiple assemblies, so small API changes ripple everywhere. Slow, but necessary.

WPF + Nodify wrestling

A surprising amount of time went into understanding how WPF resource dictionaries, theming, and Nodify's API actually want to behave together. After digging through the quirks, we finally have a clearer picture of how to keep styling and view models consistent. Didn't get as far into custom styling as we hoped, but at least the fundamentals are sorted out.

Serialization groundwork

Started wiring up the basics for text-based JSON serialization of Divooka graphs/documents. Also began work on package reference records and figuring out how packages get identified and loaded at runtime. All early steps, but important ones.

Graph editor + GUI cleanup

Made some initial passes at reorganizing the graph editor. Small changes now, but they'll help us build better tools on top later.

Fantasy Planet Painter update

Spent a little time polishing and updating the Steam submission for Fantasy Planet Painter.

Methodox Threads

We also pushed out an early public release of Methodox Threads, our lightweight branching text environment for managing non-linear AI conversations. The new v0.7 build adds integrated Gen-AI generation directly inside each document pane, configurable providers, and a simple JSON-backed structure for exporting or versioning thought trees. It's essentially a cleaner way to explore tangents, run parallel prompts, and keep complex LLM work organized. Download is available on itch.io.

Closing Thoughts

Not a "big features" week, but a surprisingly productive one in terms of future stability. Refactors aren't glamorous, but they make everything that comes next a lot smoother.

[Article] Divooka, Where We Are

Sat, 16 Aug 2025 19:42:13 +0000

Many years from now, when power users, researchers, and historians look at this article, they will see how it all started and glimpse the vision behind our work.

Overview

Ah, vision - a fascinating subject, and a quality not appreciated by all. Like the ability to dream, to imagine, and to dwell in the realm of mathematics and technicality. For imaginative minds, it's dangerous to wander too far; without standing on solid ground, one can hardly make real progress. Often, it pays to be hands-on.

Divooka is (or is becoming) a complete, general-purpose, high-level, multi-paradigm, flexibly typed, modern visual programming language/system, complete with package management, standard libraries, application frameworks, graph editors, IDE, CLI executor, code generator & compiler, derived frontend apps, examples, documentation, and accompanying tutorials and training materials. We've achieved the majority of this already, so it's not an exaggeration to list them now. What's more, there are still ideas I haven't put into words.

It's hard to do one thing well, and to achieve all of this with limited resources, we need a good strategy. Of course, the strategy itself is a secret I won't share - it's fairly simple, really, but requires determination and execution power. After a year since incorporation last July, it's useful to review and recap what we've done and where we are.

In this article, I'll focus on the period from January to August 2025, but to give a complete picture, I find it instructive to look back and highlight outcomes from last year and key lessons learned.

Early 2024

2024 was about the modernized inception of what Divooka is today.

Neo was reviewed a third time, and we managed to trim down most legacy code. It was time to think more broadly about the concept of "general-purpose visual programming," rather than just a demonstration for data analytics. A new repository was created for modern development. Gospel was conceived.

Talks with investors and prospective entrepreneurs mostly confirmed that this subject is hard, and we learned there are countless low-code platforms in China. That is good.

A disagreement with a co-creator helped me settle the fact that we would definitely go desktop-first and worry about the web later.

The conception of Quadrinity and the flexible office software framework inspired me to quit my job and move forward.

July–Sep 2024

During initial incorporation, development was highly focused, and Divooka, though very simplistic, was a well-defined, easy-to-perceive single tool with only a handful of nodes. With Haopu's help on plotting, it quickly looked like a handy little utility for data analytics - a subject matter we should continue to explore and focus on in the future.

At the same time, to prepare for public preview and an angel investor meeting, I spent a month making prototypes for many potential application areas, including experimental libraries and web use. Due to lack of sophisticated integration and completeness, I doubt these prototypes made as strong an impression as I hoped.

On the marketing side, the concept of a case competition was pitched during this time, but it never materialized later in 2024 due to slow progress on software completion and the dashboard library.

Sep–Dec 2024

With the promise of investor funding, I decided to expand operations and start hiring contractors to work on various aspects of the overall Divooka platform, including GUI design, website improvements, and preparation for first practical use. In a previous article, I mentioned that end users were unlikely to use Divooka directly during initial adoption. To elaborate:

Lack of comprehensive DSL libraries at this stage.
Overall complexity and learning curve as a general-purpose programming language.

While we could have focused on DSL, the second point made it unlikely to gain traction (given how unknown we were) and not commercially feasible any time soon. Thus, we needed more specific, tool-like, highly focused, direct end-user GUI applications.

For that reason, we published Fantasy Planet Painter. We also planned to publish Arcadia, but timeline issues prevented it.

It was during this period that we conceived what was previously known as "ZFA," while "fighting" for the trademark of "Zora" in Canada. Due to delays with investment funding, personnel management, and other corporate matters, we didn't make significant progress on the modern Morpheus framework or ZFA at that time.

In conclusion, during these busy four months, there was not much I would call technical progress. Most efforts were miscellaneous but time-consuming. I also learned it was better to take more matters into my own hands.

Jan–Aug 2025

January to August has been much more fruitful and productive, despite major distractions in January, May, and July. With help from Aaron, Allan, and ChatGPT - and without the communication burden of contractors and external collaborators - progress has been slow but steady. More importantly, I've had time to investigate highly technical matters and build foundational work.

The Web Summit in May and internal training from April to July helped us greatly polish the Neo graph editor, stabilize Neo's internal serialization format, and establish Divooka for general-purpose use.

Ecosystem-wise, I've done plenty of investigation and prototype work on Python integration, build automation, code refactoring, and preliminary work on online services.

There has been extensive work on Neo and Neo-first features, including general GUI improvements, bug fixes, plugin framework enhancements, subgraph work, generics, lambda support, multilingual framework setup, procedural context, and other experimental work. Related to this is the improved Neo serialization format, which is becoming more robust and stable. We haven't yet worked on package management. Although we are trying to make it DiDS-conformant, it's still far from achieving a single final format.

DSL-wise, there has been initial work on Ol'ista, Glaze!, Slide Present, and Novella. Many utilities were also created for ChatGPT and GenAI services, including interfaces for Nvidia NIM, ComfyUI, and Hugging Face inference services. Different users have different demands, and it's hard to focus on any specific library without a pilot project. While we do have internal pilot projects, they are large in scope and still require groundwork, so Divooka hasn't yet played a significant role. I do want to seek external collaboration on this - but at the moment resources are constrained.

On the plotting front, as of early August, Aaron has made significant progress on the mid-level plotting API, making Divooka's plotting library almost "self-sustainable," able to meet a wide range of demands.

Although data analytics is arguably not our only focus, use case investigations have improved in-memory DB handling, refactoring, and preliminary libraries for PostgreSQL ingestion. One architectural challenge is expression interpretation: we decided long ago that, at least for data analytics, it's not efficient to rely entirely on node interfaces - some coding is desirable. The main focus is SQL snippets through our in-memory DB library, though at times LINQ expressions and in-place C# scripting have been useful. However, concerns with the latter are robustness, error tolerance, predictability, increased distribution size, and future program export compatibility.

The data analytics API also faces the challenge of whether to focus on OOP or tabular data as intermediate formats. Sometimes one is more convenient than the other, which increases development costs to maintain both. Eventually, we will likely keep both but prefer exposing the tabular format in Divooka.

A more complete picture of "data analytics" in Divooka would extend into data science and machine learning. There's plenty of research to do here, including choosing a foundational library, gradually building our own infrastructure, and developing graph-friendly, visual-programming-first APIs. This will have to wait until next year.

Summary

The most visible outcome is that Neo is receiving significant updates. On the programming language front, Divooka's function libraries are growing as the language becomes more capable, flexible, and production-ready. Once we start working on package management, it will be more prepared for practical day-to-day use. However, package management requires a fully functional online service first.

Meanwhile, we are actively exploring more "direct-user-facing" applications, which I'll discuss in future posts.

We could use a lot of help on DSL work, and that's the plan as the foundations solidify and architectural decisions become clearer.

References

Wiki Entries on related subjects:

DevLogs on Divooka/Neo progress:

The Introductory to Visual Programming with Divooka Textbook:

Access it online here!

Additional references:

Glossary

DSL: Domain-specific Library
DiDS: Divooka Document Specification
DiOS: Divooka Open Standards
Gospel: The new, revived, modern incarnation of Parcel, gateway into Divooka; Now a new graph editor frontend for Divooka
Neo: The Windows graph editor for Divooka
Morpheus: The cross-platform GUI framework and graph editor architecture for Divooka
Quadrinity: A way to perceive office suite software as a single framework consisting of multiple views, like Blender's workspaces
ZFA: Zora Frontier Architecture

(Demo Game) Progress Record & Soft Intro to PID Controller

Wed, 23 Jul 2025 12:39:17 +0000

Video Intro

As fate has it, this is the third time I am doing control system simulation stuff in real-time, after proportional control and vehicle control system.

This demo shows controlling spaceship maneuver using PID controller in 2D. The video walkthrough covers the basic rocket control. It also shows GUI features for setting up such a control system by defining operations on fuel and signals.

Online demo: https://youtu.be/Yqh1EL9nN4g

Understanding the Problem and PID Control

One example of cruise control in everyday life is cars maintaining a steady speed on a highway. Similar concept apply to rockets or spaceships. Unlike cars, which move along a single dimension (forward), rockets operate in a 2D (or even 3D) space where they must manage not just speed but also direction, orientation, and position. Designing a cruise control system for such a scenario introduces unique challenges that require more sophisticated control mechanisms.

At its core, cruise control for a rocket or spaceship means maintaining a desired velocity or position in space despite disturbances—such as gravitational pulls, drag (in simulations), or unexpected shifts in thrust. In space, this is far from straightforward. A rocket’s motion is governed by Newton’s laws, meaning it doesn’t naturally come to rest when the engines stop. Once a rocket starts moving, it will continue drifting in that direction unless an opposing force is applied. This creates the first major challenge: how to not only reach the desired speed and direction but also prevent overshooting or oscillating around the target.

The second complication is that rockets often need to control both linear motion (x and y position) and rotational motion (angle or orientation) simultaneously. In a simulation, this might mean trying to keep the rocket pointing straight up while also maintaining a stable position or velocity. Even a small error in orientation can cause the thrust to push the rocket off-course, requiring constant adjustments. This is where a PID controller comes in, as it continuously calculates how much correction is needed based on the current error, the rate of change, and past performance.

It's helpful to visualize the problem in 2D context - and reduces complexities in implementation and simulation. Imagine trying to land a rocket on a platform: you need to precisely control its horizontal and vertical speeds while keeping it upright. A simple “on-off” control (like firing thrusters only when the error is large) results in jerky, unstable behavior. PID smooths this process by blending proportional control (correcting based on error size), integral control (accounting for accumulated errors), and derivative control (damping rapid changes).

References

Cruise Control - Vehicle Proportional Control: https://youtu.be/Pt2TOeEhJ_w
Vehicle Cruise Control - Control System: https://youtu.be/A7JopQNLuAY

DevLog 20250722: (Special Project) Correct Physics Handling

Tue, 22 Jul 2025 23:45:02 +0000

Overview

This little project deals with very simple (2D) right body physics. I will not spoil all the fun - essentially we control a 2D rocket. It would be fun to visualize data processing in such a fashion on a node canvas - kind of matches our Divooka visual programming scheme.

The hypothesis is that at least for 2-dimensional cruise control, a simple PID should be able to do something useful, and it's with that gut I am set to experiment a bit to verify my idea.

I've done some experiments in July last year but ended up not going far due to technical challenges.

Challenge

The challenge was to get it working properly with physics setup. Per RigidBody2D doc:

So is it relative or global? Without being able to visualize the force, it's a bit hard to tell also whether to use a force, or to use impulse.

It's been a while and I almost gave up - never really have time to create our own physics engine. But Godot got a new physics kernel and I thought maybe give it a try.

Some Inspiration

I've been doing some analytics and talking with ChatGPT on a new airship design that puts the air vessel at the bottom of the ship instead of hanging overhead - that inspired me maybe there are two things with current setup that's not working:

After fixing a few API calls related to GraphEdit get_children() change. I was looking at the force application code once again:

func _physics_process(delta):
# Remark: We are not using to_global directly because of issues with viewport transform
var left_anchor = %LeftThrusterCenterOfAction.position
var right_anchor = %RightThrusterCenterOfAction.position

# Remark: applied force is RELATIVE to the body (aka. current object)
apply_force(Vector2(0, -1).rotated(rotation + _left_engine_angle_degrees / 180.0 * PI) * _left_engine_thrust, left_anchor)
apply_force(Vector2(0, -1).rotated(rotation + _right_engine_angle_degrees / 180.0 * PI) * _right_engine_thrust, right_anchor)

Again, it's really simple once we figure out what's the right way to do things.

References

Video and intro: YouTube

Coder Legion - Recent posts tagged methodox

DevLog: 2026-10-15 A Detective Story - Making It to The Release.

Overview

Development Experience

Reception

Revival of Effort

The Things I Am Still Not Satisfied With

Remarks

References

Fantasy Planet Painter 2.0

The Basics: From a Sketch to a World

A New Physical Planet

More Ways to Create Your World

Painting, Layers, and More Space to Experiment

Build a Fantasy World to Suit Your Terrain

A World with Many Styles

Save and Share Your Worlds

Flat Worlds and Familiar Favourites

Experimental Steam Achievements

World to Beyond: A Rebuilt Map Studio

Availability

References

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

Fantasy Planet Painter

The Beginning

The Start

The Road Map

Feedback and Improvements

Version 2.0

The W2B Project

Going Forward

References

Fantasy Planet Painter 2 - 2026 Launch Trailer

Methodox Voxel Sandbox | Launch Trailer | Methodox Voxel Scene Viewer

Core Features

A Detective Story: The Case of The Dead Office Guy (Game Trailer)

Overview

Game Guide

Hardware Requirements

Weekly Update 2026-01-11

What Happened This Week

Closing Thoughts

[Article] Divooka, Where We Are

Overview

Early 2024

July–Sep 2024

Sep–Dec 2024

Jan–Aug 2025

Summary

References

Glossary

(Demo Game) Progress Record & Soft Intro to PID Controller

Video Intro

Understanding the Problem and PID Control

References

DevLog 20250722: (Special Project) Correct Physics Handling

Overview

Challenge

Some Inspiration

References