DAIKON

All 1 DAIKON 1 Launcher 0 Website & Platform 0 Infrastructure 0

DAIKON: Foundations, Flows, and Split

DAIKON May 23, 2026

Over the past few weeks, DAIKON has gone through one of its most critical development phases yet. This update isn't about flashy gameplay screenshots or finished content drops, it’s about the underlying structure required to turn DAIKON into a true persistent online RPG.

Here is the short version of what’s changing: DAIKON is now the main public focus.

While HELIOS will continue to exist behind the scenes as the private engine and tooling foundation, DAIKON is the actual game project moving forward. The recent work has been about cleanly separating the two, giving DAIKON its own online architecture, and building the core systems that need to exist before larger gameplay features are layered on top.

This includes the client startup cycle, login flow, account verification, session handling, early chat service work, server-authoritative behavior, and the first major step toward a proper service-based online game structure.

Shifting Focus: HELIOS and DAIKON

HELIOS originally started as a private 2D engine and tooling project. It was used to test rendering, maps, lighting, object placement, clipping, UI layout, editor tooling, and runtime behavior. That work proved the foundation could function.

However, DAIKON has very different requirements. A private engine can rely on local files, isolated testing, and direct editor workflows; a persistent online RPG cannot. DAIKON needs accounts, sessions, world servers, client/server separation, secure login, chat, social systems, moderation tools, and a client that follows the server rather than deciding the rules itself.

Because of that, I’ve officially split the project structure:

HELIOS: Remains the private, internal engine and tooling foundation. It won't have a public release.
DAIKON: Is the actual online RPG project. Public development updates will focus entirely here.

With this shift, the old sandbox-style prototype has been retired as the main focus. The sandbox phase was still incredibly useful for proving the core tech could load maps, render scenes, handle clipping, and preview UI. But DAIKON has moved past a local test environment to focus on the real client, server, and services.

Website Relaunch and Clean Slate

Radish.gg has been completely rebuilt around this new direction. The site is now intended to act as the central public hub for official DAIKON announcements, changelogs, project updates, community discussion, and support.

A Quick Heads-Up: Because the site has been rebuilt entirely around DAIKON, previous blog posts detailing early HELIOS and sandbox milestones are no longer present.

This doesn't mean the progress was lost. The important parts of those older posts have been folded into this larger update and the actual project foundation. I wanted a clean slate that accurately reflects what the project is today, avoiding any confusion for new visitors who might mistake it for a local engine experiment. Going forward, the public identity is simple: Radish.gg is the hub, DAIKON is the game, and HELIOS is the private tech behind it.

Client and Server Separation

One of the biggest changes has been separating the client and server responsibilities properly. Earlier versions behaved more like a local prototype, which worked for testing but won't cut it for a persistent online game.

DAIKON is moving to a strict server-authoritative model:

The Client handles the presentation layer: display, input, UI, login screens, world selection, chat panels, and player interaction.
The Server handles the rules: validation, world state, player state, movement authority, and long-term behavior.

The client shows the world; the server decides what is actually true. An online RPG cannot trust the player's client to decide important game logic like whether an action succeeded, where a player is, what items they have, or what permissions they hold. Those decisions belong entirely to the server, and this separation is the most important foundation DAIKON now has.

Client Startup Cycle

A major part of the recent work has been shaping the DAIKON client startup cycle. The client is no longer just "open the game and immediately load into a test world." Instead, it is being structured as a proper online game client with a controlled startup flow:

Client launches
Core game systems initialize
Assets and interface resources prepare
Client checks its startup state
Login screen is shown
Player submits account details
Account details are checked
Extra account verification is requested if needed
A valid session is returned
The client moves toward lobby and world selection
The selected world connection begins
The player enters the game

A single-player test client can start directly inside a map, but DAIKON cannot. It needs to know who the player is, whether the account is valid, whether extra verification is required, what session the player has, what worlds are available, and which world they are allowed to enter. That startup cycle is now treated as a core part of the game rather than a temporary test screen.

Login Flow

The login flow has reached an important milestone. DAIKON can now send account details through the proper login path, receive a result, reject invalid attempts, and create a usable login session when authentication succeeds.

For the player, the flow is intended to feel straightforward:

Enter username and password, then submit login.
The game checks whether the account details are valid.
If the details are wrong, the player receives an error.
If the account requires extra verification, the player is moved to that step.
If everything is accepted, the client receives a valid session and the player continues to the next stage.

This means the login screen is no longer just a visual placeholder. It is now connected to the wider DAIKON structure and forms the beginning of the real game entry flow. The screen itself will get visual polish later, but the underlying behavior is fully functional.

Account Verification and 2FA Flow

The account verification flow has also been accounted for. Some accounts may require an extra verification step before the login process is fully accepted. This is commonly used for stronger account protection, especially when a player has additional security enabled.

For the player, the intended flow is:

Enter normal login details.
The account system checks whether extra verification is required.
If required, the client does not fully log in yet and displays a verification prompt.
The player enters the required code, which is then checked.
If accepted, the login session is completed. If rejected, the player remains blocked from continuing.

This is an important distinction: the client should not treat "correct password" as the same thing as "fully logged in." A player may pass the first login step but still need to complete verification before receiving a valid session. That gives DAIKON a safer account flow from the start.

Login Session Handling

Once a login is accepted, the client receives a session token. That session represents the authenticated player for the next stage of the game flow.

This is important because the client should not keep resending raw account details everywhere. Once the account has been checked, the game uses a controlled session to identify that the player has already passed login. The session flow gives DAIKON a cleaner path for:

Moving from login to lobby
Moving from lobby to world selection
Connecting to a game world
Proving that the player is already authenticated without unnecessary repeated login checks
Keeping account access separate from ordinary gameplay actions

This is a foundation step for the future lobby and world connection flow.

Internal Access Protection

A secure internal access layer has also been added between DAIKON and its account-facing systems. In simple terms, DAIKON now has a gatekeeping step for sensitive account actions.

The game doesn't blindly accept any request that claims to be valid. Instead, sensitive requests need to come from trusted parts of the project, which helps prevent unsafe assumptions and keeps the login flow more controlled. For players, this work is completely invisible, but for an online game, it is vital. Account systems, login checks, sessions, and verification flows need to be protected from the beginning rather than patched later.

Lobby Direction

The next natural step after login is the lobby, which is planned as the bridge between account login and entering the game world.

The intended future flow is:

Startup -> Login ->Verification if needed -> Session accepted -> Lobby -> World selection -> Game world

The lobby could eventually display things like news, account status, available worlds, world population, maintenance notices, character information, social previews, service status, and important announcements.

The lobby matters because the client needs somewhere to go after login before entering the actual world. Without a lobby, the project jumps too abruptly from login into gameplay. That might work for a prototype, but it is not ideal for a persistent online RPG. A proper lobby gives DAIKON a cleaner, more expandable entry flow.

World List and World Selection

DAIKON is also moving toward a proper world list system. Instead of forcing the client to manually know about every available game world, worlds should eventually be able to report their own status. That means the client can ask what worlds are available and show that information to the player.

In the future, this could include world names, online/offline state, population, access restrictions, maintenance state, special event worlds, test worlds, or regional and rule-set differences.

The goal is to make world selection feel like a normal part of the game flow. The player logs in, reaches the lobby, sees available worlds, chooses one, and connects. That gives DAIKON a proper online structure instead of forcing everything through a single hardcoded test path.

Service-Based Architecture

DAIKON is now being built around dedicated services rather than one giant server that handles everything. This is a major structural change. Instead of putting login, chat, friends, guilds, moderation, broadcasts, sanctions, and world logic all inside one large game server, DAIKON is being separated into focused, isolated systems.

The goal isn't to make the project complicated for the sake of it, it's to prevent unrelated systems from being tangled together. A chat issue should not require rewriting the world server. A guild feature should not own private messages. A friends list should not control the entire chat pipeline. A moderation tool should not be an afterthought buried inside unrelated gameplay code. The service-based direction allows DAIKON to grow more safely.

Current Service Direction

Area	Current Direction
Account login	Functional foundation in place.
Account verification	Supported as part of the login flow.
Session handling	Used to move beyond raw login details.
Client startup	Being structured as a proper online startup cycle.
Lobby	Planned as the next major entry-flow step.
World list	Planned as a dedicated world selection system.
Chat	Active development focus.
Broadcasts	Planned for system-wide messages.
Friends	Planned as a social relationship system.
Guilds	Planned as a group membership and permission system.
Moderation	Planned as a dedicated staff/tooling system.
Sanctions	Planned for mutes, bans, restrictions, and enforcement.
Editor tooling	Long-term direction is server-aware development support.

Chat System

Chat is now one of the active focuses. DAIKON’s chat is being treated as its own standalone system rather than something buried directly inside the world server. This matters because chat is not just one feature; over time, DAIKON may need several types of communication:

World chat and local chat
Private messages and friends-related messages
Guild or clan chat
System messages and broadcast messages
Staff messages and moderation-visible communication events

If all of that is hardcoded directly into the world server, the system becomes messy very quickly. The better structure is to have chat act as the message delivery layer, while other systems provide the rules around who can speak, who can receive messages, and what type of channel is being used.

The World decides which players are nearby.
The Friends System decides who is connected socially.
The Guild System decides who belongs to the same guild.
The Moderation System decides whether someone is muted.
The Chat System delivers the message to the correct people.

That keeps responsibilities much cleaner.

Chat Connection Flow

The chat service now has the beginning of its own connection flow. At a high level, the idea is:

The game world connects to the chat system, and the chat system acknowledges that connection.
The world can send chat messages into the chat system.
The chat system processes the message and delivers it to the correct destination.
The game world receives delivered chat events and passes them to players.

This allows chat to exist outside the core world loop. The world server does not need to personally own every part of the chat infrastructure. It can connect to the chat system, send messages, receive delivered messages, and let the dedicated chat layer handle the communication pipeline. That creates a much stronger base for future public, private, guild, and system messaging.

Why Chat Is Separate From Friends and Guilds

One important design decision is that chat, friends, and guilds should not all be the same system. They are related, but they do entirely different jobs. The chat system delivers messages. The friends system tracks social relationships, online presence, and private communication permissions. The guild system tracks membership, ranks, permissions, and group identity.

Those systems will eventually talk to each other, but they should not be fused together. This avoids a common online-game problem where one social system going offline breaks several unrelated features. If friends are unavailable, that should not automatically mean all chat becomes unusable. If guild data is unavailable, that should not break world chat. If chat is restarted, that should not destroy guild membership data. Separating them gives DAIKON a better long-term social foundation.

Broadcast and System Messages

Broadcasts are planned as a separate system-level communication layer. Not every message in the game should be treated like normal player chat. Some messages need to come from the game itself, such as:

Maintenance warnings and restart notices
Server-wide announcements and event reminders
Staff broadcasts and important account notices
World status warnings

These messages should be controlled, highly visible, and handled differently from ordinary chat. That is why broadcasts are being planned as their own area rather than being treated as normal player messages.

Friends System Direction

The friends system is planned as its own service. Its job will be to understand player relationships and presence. That could eventually include friends lists, online/offline states, private message permissions, ignore/block rules, friend-related notifications, and social status visibility.

The friends system may connect into chat, but it should not become the chat system itself. For example, private messaging may use the chat delivery layer, but the friends system can help decide whether the message is allowed. That separation keeps the project cleaner.

Guild System Direction

Guilds are also planned as their own system. The guild system should understand group identity, ranks, permissions, and membership. That could eventually include guild creation, membership, ranks, permissions, guild chat access, announcements, moderation, and future group-based gameplay systems.

Guild chat would use the chat layer, but the guild system would decide who belongs in that channel and what permissions they have. This allows guilds to grow into a serious game system rather than being treated as just a chat room.

Moderation and Sanctions

Moderation and sanctions are being planned from the beginning. This is important for any online game with public chat and player interaction. Future moderation systems may include mutes, bans, account restrictions, chat restrictions, staff notes, player reports, punishment history, internal staff tools, and service-wide enforcement.

This work is not just about punishment, it is about keeping the game manageable, fair, and safe for the community. Moderation should not be improvised after launch; it needs to be part of the online foundation.

Server-Aware Editor Direction

The DAIKON editor is also being reconsidered as part of the online split. Originally, the editor was closer to a local engine tool. It helped with maps, object placement, clipping, lighting, previews, and general engine testing.

For DAIKON, the long-term goal is different. The editor should eventually become server-aware, meaning it could one day support safer content editing, runtime previews, server-backed validation, controlled world updates, internal development tools, and live-development workflows that let me see the world closer to how the game client sees it.

The editor is not being forced directly into the live game server right now. For now, it needs to stay clean and separate. But the direction is clear: DAIKON’s tools should eventually support the online structure rather than only editing local files in isolation.

UI Direction

DAIKON’s UI direction is also becoming clearer. The project will likely use a mixed approach. Visual frames, buttons, decorative panels, and interface styling can be asset-driven. However, actual gameplay interfaces need to be dynamic.

Systems like inventory, equipment, quests, chat, social panels, and moderation tools cannot just be static images. They need to respond to live player data, server state, permissions, unlocked features, account restrictions, and gameplay changes. That means the UI needs to look consistent while still being controlled by actual game systems. This will help DAIKON avoid the problem of building pretty interfaces that are difficult to connect to real gameplay later.

What This Means for Players

For players and community members, this update means DAIKON is still early, but its foundation is becoming much more serious. Recent work has focused on the systems required before the visible gameplay layer can properly grow.

This is foundation-heavy work. It is not as instantly exciting as new areas, combat, quests, items, or bosses, but it matters more at this stage. Building content before the foundation is stable usually means rewriting that content later. DAIKON is being built in the opposite order: Foundation first. Core systems second. Content third.

Current Status

DAIKON is now the main public-facing project.
HELIOS remains private and internal.
The old sandbox focus has been retired.
The client and server have been split more clearly.
The client startup cycle is being shaped into a proper online flow.
Login now works as a real connected system.
Account verification is part of the login path.
Accepted logins now produce a usable session.
The next entry-flow target is the lobby and world selection.
Chat service work has started.
Chat is being kept separate from friends and guilds.
Friends and guilds are planned as dedicated systems.
Broadcasts are planned for system-level messages.
Moderation and sanctions are planned from the beginning.
The editor’s long-term direction is becoming server-aware.
Radish.gg has been rebuilt around DAIKON as the public focus.

What Comes Next

The next major focus is continuing the online foundation. The likely next steps are:

Expand the standalone chat system.
Continue shaping the client startup flow.
Build the lobby path after login.
Add world list and world selection behavior.
Prepare social systems to connect into chat later.
Continue separating client presentation from server authority.
Keep public updates focused on DAIKON.

Once that flow is stable, the actual entry pipeline will look complete: you'll launch the client, log in, complete verification if needed, land in the lobby to check news, pick your world from the list, and jump straight into the game.

Closing Notes

This changelog covers a lot of invisible work. The project has moved from a local engine prototype toward a real online RPG structure. That means login, account security, sessions, client startup, chat, services, world selection, moderation, and tooling all need proper foundations before the game can grow safely.

DAIKON is still early, but it is now moving in a much clearer direction. The work being done now is the bedrock for everything that comes later. Future updates will continue focusing on DAIKON as the main public project, with more visible gameplay progress coming once these core systems are stable enough to support it.

Here's some pictures!

Thank you for reading,

-RadRadish