Developer Ramble: The Kind of Online RPG I Want To Build

This is not really an announcement post.

It is not a pitch deck either.

It is more of a ramble about where my head is at with DAIKON, or whatever this project eventually becomes once it has its own proper identity and name.

Radish.gg is the current home for my development updates, community discussion, support, and project information across current and future projects. DAIKON is the main thing I am building right now, so this is where these thoughts belong for the time being.

This post is more of a point-of-view discussion than a formal design document.

A small note before getting into it: the diagrams in this post are AI-generated design sketches. I am using them because I am not an artist, and they help explain the direction more clearly than a wall of text. They should be treated as rough visual aids, not final UI, final balance, or final in-game presentation.

AI-generated design sketch: DAIKON’s broad direction as a small, lightweight online RPG shaped by readability, accessibility, and long-term progression.

The kind of online RPG I miss

I grew up around an era where online RPGs felt very different from a lot of modern games.

They were slower, more readable, and often awkward in places, but they had a strong sense of account identity, world routine, and long-term progression.

You clicked something, your character did the thing, and the depth came from preparation, risk, economy, social interaction, and slowly building your account over time.

That style of game left a mark on me.

Not because every old system was perfect. A lot of those games had friction, clunky interfaces, strange design decisions, and plenty of things that only worked because people accepted them at the time.

But there was something valuable there:

• A readable interaction model.

• A world that did not need to be visually overwhelming to be memorable.

• Progression that mattered because it took time.

• Items that felt meaningful because they came from the game, not a shop.

• A sense that your account was something you lived with for years, not something you rushed through in a weekend.

That is the rough space DAIKON lives in for me.

DAIKON is not meant to be:

• A clone of any one game.

• A remake.

• A private server with different names.

• A modern action-bar MMO.

The question I keep coming back to is:

What if an old-school, click-based online RPG evolved in its own direction?

What if it kept the slower, readable feel, but had a cleaner interface, better utility, stronger account systems, and its own skill and economy design?

That is the direction I keep returning to.

I am not trying to build the next giant MMO

I want to be clear about this because indie MMO talk can become ridiculous very quickly.

I am not under the impression that I am making the next massive online game with hundreds of thousands of subscribers.

That is not the goal.

The realistic goal is much smaller:

• A lightweight, persistent online RPG with its own identity.

• A game that a small group of people could care about.

• A game that feels memorable, even if it is never huge.

• A game that can be sustainable without becoming greedy or bloated.

If DAIKON eventually became a small, profitable project that kept its servers online, funded its own development, and had a loyal community, that would already be a serious success.

I would rather build a small world people actually care about than chase a giant idea that never becomes playable.

Why lightweight matters

One of the original ideas behind HELIOS, the older 2D grandfather of this project, was that it should be lightweight.

That carried into DAIKON.

This is not me trying to make some grand statement about hardware, and it is not me pretending I have a dramatic personal story behind it.

It is simpler than that.

I remember being younger and seeing people miss out on games because they did not have the right PC, or because their machine was old, shared, low-spec, or barely hanging on. Sometimes a whole friend group would move onto something new, but one or two people simply could not come along because the game would not run for them.

That always bothered me.

Games are social. Online games especially are social. If a game becomes too heavy for no good reason, it does not just exclude a machine. It excludes the person behind it from the group.

So with DAIKON, I like the idea that someone on an old hand-me-down Windows 7-era laptop could still play the same game as someone with a modern gaming PC.

The gaming PC might get more shimmer, nicer effects, higher resolution, or smoother visual extras, but it should not be a different game. The core experience should still be there on low-end hardware.

That matters to me.

A lot of modern games, especially online games, slowly drift toward becoming heavier and heavier:

• Bigger clients.

• Higher requirements.

• More visual noise.

• More layers of systems.

• Less actual readability.

DAIKON is meant to go the other way:

• Readable.

• Lightweight.

• Low-spec friendly.

• Still cohesive.

• Still memorable.

That is also part of why I chose LibGDX instead of jumping straight into a premade engine or trying to write everything in C++.

LibGDX fits the kind of project this is. It keeps me in Java, which fits the server side and the tools I am already building. It gives enough control to make the game behave the way I want without dragging the whole project toward the expectations of a large commercial engine.

DAIKON is not trying to win through engine spectacle.

It has to win through feel, consistency, systems, and identity.

Not action-bar combat

One thing I want to be careful about is the combat direction.

DAIKON is inspired by older click-based online RPGs, but it is not aiming to become full action-bar combat.

I do not want a combat system where the whole game becomes pressing numbered keys on cooldown.

The idea is still readable combat:

• Click the target.

• Engage through weapon cycles.

• Use server-side rolls and rules.

• Make decisions through positioning, gear, resources, and timing.

• Use occasional high-impact actions where they make sense.

There may be a utility quickbar. Magic especially benefits from spell bindings. Specials, food, potions, gear swaps, and certain utilities can make sense on a quickbar too.

But that is not the same thing as building the whole combat system around rotations.

The quickbar should be convenience and utility, not the source of the combat identity.

That distinction is important to me.

Rethinking skills without copying older games one-to-one

A lot of the current design work has been around skills.

I do not want to recreate an older skill list one-to-one just because it is familiar. At the same time, I do not want to throw away the kind of progression that made those games work.

The current direction is to use broader skills where it makes sense, but not to overload everything with endless branches.

For example, Archery is currently imagined as a parent skill with two subtrees:

• Marksman, which is the combat side.

• Bowcraft, which is the production side.

So a player could be an excellent ranged combatant without being a master bowyer, or a master bowyer without being a strong ranged fighter.

That means the parent skill represents overall mastery of the discipline, while the subtrees represent the actual specialisation.

Magic is another example where I do not want to copy old systems directly. Instead of filling inventory space with stacks of spell resources, the current idea is that magic uses staff charge. The staff becomes the magic weapon, and the resource loop is based around maintaining that staff through essence, trading, gathering, boss drops, and preparation.

That keeps upkeep and economy pressure, but moves it away from annoying inventory clutter.

Crafting is another area I have gone back and forth on.

I do not think DAIKON needs a broad “Crafting” skill just because some older games had one. Jewellery bases can belong under Metallurgy. Enchanting belongs under Magic. Bows and arrows belong under Archery/Bowcraft. Creature materials can fall under Hunting. Plant fibres, oils, toxins, and reagents can fall under Botany.

The rule I keep coming back to is simple:

If something has a clear material source or gameplay purpose, it should live there.

Do not keep a vague catch-all skill just because older games did.

AI-generated design sketch: crafted item types are distributed by material source and gameplay purpose instead of being placed inside one catch-all crafting skill.

Gathering and production should not feel the same

Another major design idea is that gathering and production should have different interaction models.

Gathering should be about the world.

The rough idea is:

• Click a resource node.

• Gather over time.

• The node depletes.

• Move, bank, route, react, or compete for resources.

That feels better to me than every rock, tree, or herb being a one-click, one-item interaction.

Production is different.

If you already prepared the materials, the game should respect that. Make-X and Make-All should actually mean something. If a player has the materials to make a large number of arrows, bars, meals, potions, or components, the game should let them queue that work and process it over time.

Not instantly.

Not without validation.

Not offline automation.

But also not stopping after some tiny arbitrary batch just to force more menu clicks.

The depth should come from:

• Materials.

• Time.

• Tools.

• Stations.

• Economy.

• Risk.

• Interruptions.

• Output space.

Not pointless repetition.

AI-generated design sketch: gathering is world interaction, while production is prepared material conversion through timed, server-validated batches.

Free-to-play, members, and keeping the lights on

Monetisation is something I have thought about carefully because it ties directly into the kind of game DAIKON is supposed to be.

At launch, my current view is that everything available should be free-to-play.

No members-only content on day one.

No “the real game starts when you pay.”

No chopping up a thin launch version and hiding the interesting parts.

The launch version should feel like a complete free-to-play game waiting for future updates.

Members, if and when it happens, would come later. It would be an expansion layer. New areas, deeper systems, larger encounters, and more long-term content. Members would help fund continued development, but free-to-play would still receive meaningful updates too.

That is important.

I do not like the idea of free-to-play being treated as a demo or a second-class version of the game. DAIKON is meant to be inclusive regardless of financial status. That is part of the same philosophy as making the game lightweight enough to run on older machines.

If the game is going to ask for money, it should do so honestly.

Before members exists, the most likely model would be optional supporter funding. Something to help keep the servers online, pay for tools, maybe fund assets or outside help later.

But DAIKON is not intended to have a cosmetic shop for weapons, armour, pets, or animations.

That is a hard line for me.

If you see someone wearing something, using a weapon, having a pet, or showing off an animation, I want that to come from the game. It should mean they earned it, found it, crafted it, completed something, or reached that point.

Not that they bought a skin.

That probably makes monetisation harder, but I think it protects the kind of game I want this to be.

What success would actually look like

I do not need DAIKON to be massive for it to matter.

A small, stable, online world with a loyal community would already mean a lot.

If it can pay for its own hosting, tools, assets, and eventually help fund more development, that is a real success.

If a few dozen, a few hundred, or eventually more people genuinely care about logging in, progressing, chatting, trading, fighting, gathering, crafting, and seeing the world grow, that is the kind of success I am actually interested in.

The point is not to beat the games that inspired me.

The point is to build something that remembers why that style of game mattered, while becoming its own thing.

Where DAIKON is right now

Right now, DAIKON is still in the stage where a lot of the foundations are being built and tested.

Some of the boring but important pieces exist already:

• Login.

• World selection.

• Services.

• Client/server structure.

• Technical direction.

• Early tooling.

The missing part is the actual playable RPG loop:

• Combat.

• NPCs.

• Loot.

• Banking.

• Gathering.

• Production.

• Progression.

That is where the project needs to become more than an engine and more than a pile of systems.

The long-term design is useful because it gives the project direction, but the prototype still needs to prove the basic feeling:

• Log in.

• Move around.

• Fight something.

• Get something.

• Bank something.

• Gather something.

• Make something.

• Progress.

• Come back later.

That is the heart of it.

Final thought

This post is not me saying DAIKON is definitely going to become some successful MMO.

It is not me claiming the design is perfect.

It is just where my head is at.

I want to build a small, lightweight, readable online RPG that takes inspiration from the era of games I grew up with, without being chained to copying them.

Something old-school in feel, but not stuck as a recreation.

Something accessible, but not shallow.

Something small, but built with care.

That is the version of DAIKON I want to keep chasing.