NEWS

Dreamwalker is intentionally being approached differently from classes whose theme can be explained with one obvious object or element. The goal is a class identity that feels dreamlike and unsettling without turning into a random collection of surreal effects.

That makes restraint important. Shape language, movement, colour and atmosphere have to suggest the theme while remaining readable from the game camera and consistent with Yashariel’s darker visual direction.

The class is still presented as one of the initial four public class identities alongside Plague Lord, Mirror Mage and Starforger. Its design work continues with the same rule as the rest of the roster: recognisable first, elaborate second.

Combat control becomes much more convincing when movement and casting obey the same rules. The current player setup supports WASD and click-to-move from the isometric perspective while ability casting can enter a timed cast state represented by the cast bar.

Casts can be cancelled when the character moves or dies, preventing the UI from claiming an ability is still being performed after the gameplay state has already changed. Controller and character Blueprints are being used to test these interactions with the current character setup.

This is another integration milestone: movement, combat, UI and character state are beginning to behave as one system instead of a collection of independent prototypes.

Starforger shares a broad cosmic space with Mirror Mage, but the two classes are not the same visual idea. The current Starforger presentation is a female figure surrounded by mirror- or crystal-like shards, giving the class a sharper and more constructed visual identity.

That distinction is now treated as fixed in the class artwork. The blue cosmic character belongs to Mirror Mage; the female shard-based artwork belongs to Starforger.

Keeping those identities separate is part of the larger class-direction work: even when two classes use related colours or supernatural themes, their silhouette and visual language should not become interchangeable.

Several systems that began separately are now starting to connect. The HUD tracks health and resources, the lower interface carries progression and skills, the inventory reads item data, and casting has its own visible state instead of happening invisibly in code.

The inventory and item tooltips already expose the information equipment rules need, while gold and pickups connect combat rewards back into the player state. The cast bar can represent timed abilities and react when a cast is interrupted.

This stage is less about adding another standalone widget and more about making the existing pieces agree with one another. A usable ARPG interface has to reflect the same underlying systems the character is actually using.

Mirror Mage is one of the classes where the visual concept has to communicate the idea before a tooltip does. Its current class artwork uses a blue cosmic character and a visual language built around reflection, space and controlled arcane geometry.

The class is deliberately kept separate from Starforger. Both can touch cosmic imagery, but Mirror Mage should not inherit the crystal-shard presentation that belongs to the other class.

That distinction is important for the wider class roster. Shared themes can exist, but each class still needs a silhouette, palette and visual identity that remains recognisable at gameplay distance.

The talent tree is now more than a static layout. Point investment, available-point checks, row unlocking and predecessor connections work together in the Unreal Engine implementation.

The final progression plan provides 46 talent points in total. Levels 1 and 2 grant none, the first point arrives at Level 3, and the final point at Level 60 is reserved for reaching one of the three Ultimate choices. Normal talent nodes use multi-rank investment, while an Ultimate is a single-point commitment.

There is still balancing and presentation work ahead, but the important milestone is usability: the tree can now enforce the structure it was designed around instead of relying on manual test assumptions.

The Plague Lord is built around disease, decay and damage-over-time pressure rather than simply being a dark-themed caster. Its class identity influences the visual language of its skills, armour and the kinds of talent interactions being planned around it.

Each class is planned with four playable races. For the Plague Lord, one of those races is the Rat Prophet. That name is part of Yashariel’s own class-and-race structure and is the official terminology used by the project.

The reveal also established how future class presentations should work: class identity first, then the races and visual variations that belong to it, without treating every race as a separate class.

Ashbound was the development name that carried the project through its earliest phase. As the world, identity and long-term direction became clearer, it no longer felt specific enough to represent what the project was becoming.

The new official name is Yashariel: The Forgotten Ember. The change was not limited to the website title: the Unreal project, module names, paths and technical references also had to be migrated so the new identity existed throughout the project rather than only in marketing material.

The rename closes the earliest chapter of development. The systems built under the old name remain the foundation, but the project moving forward is Yashariel.

Yashariel is built by two people with different responsibilities, so design cannot be thrown over a wall and implementation cannot happen in isolation. The working process became a loop: define the idea, check feasibility, prototype, test, polish and feed the result back into the next decision.

Sina’s design work gives systems a visual and creative target. Rene’s implementation exposes what works, what needs adjustment and which ideas need a different technical route. That back-and-forth is now part of the project rather than an exception when something goes wrong.

The result is slower than pretending every idea is final on day one, but it is far more useful: decisions become stronger because they survive both design and implementation.

The next step was making the talent tree enforce its own structure. Unlocking a later row requires enough investment in the row directly before it, and from the second row onward a node also needs an active connection from a valid predecessor.

Normal rows use a five-point progression requirement. The component now checks available points, current points, previous connections and row unlock state before allowing an investment.

This is the difference between a talent-tree image and a functioning progression system: the layout is no longer decorative. The connections a player sees are beginning to determine the build the game will accept.

The first technical talent-tree implementation translated the approved layout into Unreal Engine. Node data was moved into a dedicated structure and data table, while a Blueprint component handled the rules needed by the interface.

The UI uses the fixed three-path, ten-row structure and can read node information such as row, column, path, skill identity, connections, point limits and whether a node is passive or an Ultimate.

This version was still the beginning of the implementation. The important change was that the tree now existed as a system the game could query and update instead of only as a visual planning image.

Rarity is not only a colour in a tooltip. The armour direction was defined so higher qualities can become progressively more elaborate in materials, silhouette, ornamentation and effects.

Common, Uncommon and Rare pieces stay comparatively restrained. Epic gear can introduce more noticeable details and subtle glowing accents. Legendary and higher qualities can push larger silhouettes, stronger materials, gemstones, auras and more unusual construction while still fitting the class wearing them.

Helmets, crowns, hoods and other head pieces are part of that progression as well. The aim is for a player to recognise increasing equipment quality before opening an item panel.

World design began organising Yashariel around Arandresia as one continent. The objective was to create regions that can feel visually and atmospherically distinct while still belonging to the same larger world.

Confirmed areas include Bloodmoor, the Demon Paths, the Valley of Bones, Drakenfall Citadel and the Forgotten Battlefield, alongside towns, ruins, roads, coasts, swamps and other regions already planned for the continent.

The capital is intended to function as a damaged but living safe meeting point with services such as trading and the Auction House. Beyond that, the world is being built region by region rather than filling gaps with lore that has not yet been decided.

The talent-tree concept settled on three main paths and ten rows. Normal nodes can receive multiple points, while the final row contains the three Ultimate choices.

Progression is intentionally constrained. A player receives a limited total number of talent points on the way to Level 60, which means reaching every strong node is not possible on one character. Connections between nodes also matter, so a build has to develop through the tree rather than jumping directly to isolated rewards.

The structure is meant to support commitment without locking every player into a single straight line. Cross-connections allow hybrid routes where the layout supports them, while the end of the tree still requires one final Ultimate choice.

The normal character level cap is 60, but reaching it is not intended to finish character development. Level 60 is where the game can transition from conventional levelling into the systems built for longer-term progression.

Ash Ranks extend progression beyond the level cap, while Black Ember represents a deeper rebirth-style layer with a limited number of long-term cycles. These systems are designed so account progress can coexist with character-specific choices rather than flattening every character into the same build.

The goal is to create reasons to keep developing a character without turning the normal level cap into an endless number that simply grows forever.

Class design moved beyond names and visual themes. The seven planned classes need distinct identities that affect abilities, resources, pacing and the kinds of decisions a player makes during combat.

That principle shapes everything around a class: its talent paths, skills, equipment presentation, playable races and later specialisation choices. A class should be recognisable from its behaviour, not only from the icon above an ability bar.

The initial public presentation focuses on Plague Lord, Mirror Mage, Starforger and Dreamwalker, while the wider class plan also includes Astralweaver, Chrono Warrior and Chimera Master.

Once the inventory could hold items, equipment needed rules. An item must know which equipment slot it belongs to, which weapon or hand rules apply, whether a class or level requirement blocks it and what happens to its ownership state when it is equipped or picked up.

Binding and trading were treated as part of the item model instead of as a later shop feature. Bind on Equip, Bind on Pickup and account-bound states need to be understandable both to the game and to the player before an item changes hands.

These rules are less visible than a new animation, but they prevent an inventory system from becoming a collection of exceptions once hundreds of items exist.

The first inventory implementation gave items a real destination after being picked up. The interface was structured as a grid with dedicated potion space, while the underlying inventory component handled adding items and refreshing the UI.

Item tooltips began pulling from data rather than relying on hand-written interface text. Name, rarity, required level, required class, stats, affixes, gold value, binding and trade information all have defined places in the item presentation.

That separation between item data and UI matters for scale. New equipment should be added through the data structure, not by rebuilding the inventory every time another item exists.

Adding more drops without deciding how loot should behave would only create clutter. We defined the intended feel before expanding the item pool: ordinary items should remain visually restrained, while rarer items can receive clearer ground-level effects.

Dropped loot is intended to remain available until the player leaves the area rather than disappearing after an arbitrary short timer. Returning to town should not automatically erase what was left behind in the active area, and a visibility key can make faded drops readable again.

The point is to make valuable loot noticeable without turning every drop into a pillar of light. Rarity should feel stronger as quality rises, both on the ground and on the character.

Loot systems become much easier to judge once something can actually drop into the world. The first working version was intentionally simple: an enemy could die, create a gold pickup, and that pickup could be collected and reflected in the player’s gold amount.

That small loop connected combat, death, world pickups and the player’s stored progression for the first time. It also exposed practical questions that would matter later: how long drops should remain, how clearly they should be shown and which rewards a companion may eventually collect.

Gold was only the first step. The same basic chain would later support materials and equipment with their own rules.

The next step was connecting the character’s health display to real gameplay. Damage needed to reduce health consistently, death needed a clear state, and other systems needed a reliable way to react when the character or an enemy reached zero.

This sounds small compared with classes or endgame systems, but it is one of the pieces everything else depends on. Combat abilities, enemies, loot drops, durability and later encounter logic all require damage and death to be dependable.

With that loop working, the project had moved beyond a character simply walking around a test area. There was now a real gameplay state that other systems could build on.

The first HUD turned several hidden gameplay values into information the player could actually read. Health, resources, progression and skill access all needed a clear place on screen without covering the isometric play space.

The developing layout uses a health orb on the left, a resource orb on the right, progression bars around the lower interface and a central skill area. The goal is not to imitate a mobile-game HUD, but to keep essential ARPG information visible at a glance.

This first version was a foundation rather than a final skin. As more systems became functional, the HUD could be connected to real character data instead of being a static mock-up.

Before combat could feel good, moving through the world had to feel predictable. The player controller was built around direct WASD movement while also supporting click-to-move, giving players two familiar ways to navigate an isometric ARPG.

The focus was intentionally basic: clean directional input, reliable stopping, correct facing and movement that could later coexist with skills, casting and interaction systems. Extra movement mechanics were not added simply to make the prototype look more advanced.

Getting movement right first also meant later combat tests would be based on the controls the game is actually intended to use rather than on a temporary prototype.

Opening Unreal Engine marked the point where planning started becoming implementation. The early work was not about producing a polished combat demo; it was about creating a project structure that could support the systems already being planned.

Data-driven ability structures, class and variant information, movement foundations and the relationship between C++ and Blueprints were among the first technical concerns. The goal was to avoid hard-coding every future ability or interface decision into a single prototype.

From this point, progress could be tested instead of only discussed. Every small successful build became a foundation for the next system.

With the project becoming more concrete, we defined who would own which part of development. Yashariel is being built by a small independent team, so clear responsibilities are essential even though major decisions are discussed together.

Rene took responsibility for the technical side as Technical Director & Lead Developer: Unreal Engine, C++, Blueprints, gameplay systems, UI implementation, builds, website work and the technical infrastructure around the project.

Sina took responsibility for the creative side as Creative Director & Lead Designer: art direction, classes and races, armour, world and environment design, artwork, lore direction and the Art Bible that keeps the visual language consistent.

The split is intentional, but not isolated. Creative ideas are checked against what can realistically be built, and technical systems are shaped around the experience and visual direction they are meant to support.

Once the basic game direction was clearer, the visual side needed the same treatment. The first moodboards and references focused on architecture, armour, landscapes, lighting, materials and the overall atmosphere of the world.

The target was dark fantasy without sacrificing readability. Black, anthracite, ash grey and aged metallic tones could define the base, while bronze, restrained gold and ember colour would be used as accents rather than covering the screen in effects.

Everything also had to be considered from an isometric gameplay camera. A design can look impressive in a close-up illustration and still fail in play, so silhouettes, equipment shapes, lighting and important effects needed to remain readable from above.

The project moved from open-ended ideas into a clearer direction. Yashariel would be a dark-fantasy action RPG with an isometric top-down presentation, direct character control, deep character progression and online/MMO-inspired systems.

The ARPG remains the center of the experience. Combat, builds, equipment and progression have to work for a player who wants to explore and develop a character alone. Shared systems and group content are there to expand the experience, not to replace that foundation.

Writing those pillars down mattered. From this point onward, new ideas could be judged against an actual direction instead of being added simply because they sounded interesting.

Before choosing features, the project needed boundaries. We compared the parts we enjoy in existing action RPGs and larger online RPGs with the parts that often make those games feel restrictive, repetitive or unnecessarily dependent on other players.

The discussion covered combat responsiveness, loot, long-term progression, build freedom, shared online systems and how much of the experience should require a group. The purpose was not to copy another game, but to identify the decisions Yashariel should make intentionally from the beginning.

One direction became especially important: online and MMO-inspired systems can make a world feel larger without forcing every player into mandatory group content. That principle would become one of the project’s foundations.

Yashariel did not begin with a finished world, a class list or even its final name. It began with an idea for an action RPG and a long list of questions about what the game should feel like to play.

The first discussions were deliberately broad: combat, loot, character progression, exploration, online elements and the kind of world that could hold all of those systems together. At this stage there were no final classes, no fixed regions and no complete design document. The goal was simply to find the core of a project worth committing to.

That first idea became the starting point for everything that followed. Rather than pretending the project arrived fully formed, these development updates begin here — before the systems, artwork and name that now define Yashariel existed.