NEWS

We also changed one of the more visible parts of the website today. Instead of repeatedly pointing visitors towards a Wishlist before there is much reason to use one, the site now puts more focus on the Yashariel newsletter.

More importantly, the newsletter is no longer just a button and a collection of prepared pages. The newsletter system itself is now connected to the website. Subscription, confirmation and unsubscribe are all part of the flow we have been building.

That does not mean we are calling it finished yet. Over the next few days we hope to put the complete process through proper testing — signing up, receiving the confirmation, handling the subscription correctly and making sure emails arrive the way they should.

If everything behaves as expected, this will give us a much better way to share development updates, larger milestones and important Yashariel announcements without asking everyone to constantly keep an eye on Discord or social media.

For now, getting the system connected is an important step. The next one is making sure it survives real testing.

Today ended up becoming a much larger community cleanup than originally planned. Instead of continuing to patch old test data and early bridge experiments, we cleared the existing development posts and rebuilt the official guide set cleanly on both the website and Discord.

There are now 40 official Ashen Herald guides on the website with 40 matching Discord discussions and fresh bindings between them. Old test threads, duplicate rebuild threads and the temporary GM colour test are gone.

Ashen Herald is now clearly treated as the Community Bot rather than pretending to be a human team member. Human staff use their verified public role, while automated posts have their own identity.

The community bridge has also been tightened up so website and Discord discussions can belong to the same system. New comments can appear without rebuilding everything already visible on the page, and moderation checks can flag obvious spam or suspicious content for staff review.

Alongside the visible work we also completed another maintenance and security pass on the services behind the website and community. Most of that work should remain invisible, which is exactly the point.

The world of Yashariel now has its current name across the project: Arandresia. References on the website and related presentation material have been updated so the old development name no longer appears as the current world name.

At the same time we went back through several mobile and account layouts after changes elsewhere on the site had caused parts of the desktop account area to drift. The goal was simple: fix the affected pieces without turning one repair into three new ones.

And finally, a much smaller detail: Yashariel now has its updated favicon across the website. It is tiny, but seeing the project mark sitting in the browser tab instead of a generic icon was still strangely satisfying.

The Friend Pass work moved further into the website today. The goal is to make referrals, progress and rewards feel like part of the player's account rather than something that lives on a separate promotional page.

We also continued refining how the rewards are presented. Some things can be explained openly, while others are much more fun if the player knows there is something waiting without being shown exactly what it is.

The underlying Friend Pass rules have stayed intact during this pass. Most of the work has been about presentation, account integration and making the feature easier to understand.

More weapon and armour work today. One thing we keep coming back to is that rarity should not exist only as a colour around an item name.

Materials, silhouette, construction and detail should gradually change as equipment becomes more unusual. A common weapon can still look good, but a rare or legendary one should feel different before the player even reads its tooltip.

Sina has been applying the same thinking across armour pieces as well, which helps different sets feel related to their place in the item progression rather than simply being separate pieces of concept art.

Community moderation received another pass today. Staff who have the right permission can lock or reopen a discussion and pin or unpin important threads without needing broad access to unrelated administrative tools.

We also changed how staff identity is shown publicly. A normal member remains a normal member, while verified staff can display their public role. That information comes from the actual account and staff relationship rather than checking whether someone happens to use a familiar-looking display name.

It is a small distinction technically, but an important one for a community system that eventually needs people to know when they are actually talking to a member of the team.

The Community section has taken a big step forward. Threads can now open as real detail pages rather than sending users to placeholders, and the different Alpha, Beta, Feedback and PTR areas are beginning to share the same underlying behaviour.

We also worked on loading threads more sensibly. The original post should be visible as soon as its data is available instead of making the entire page wait for every comment underneath it.

It is still early infrastructure, but this is the point where the Community area starts feeling like a system we can actually use rather than a design for something that might exist later.

The account area, login flow and support pages have been getting a lot of attention. The goal is not simply to make each page work on its own, but to make the whole website feel like one place once a player signs in.

Account overview, security, tickets and related pages are being brought into the same structure, with mobile behaviour receiving the same attention as desktop.

There is still a lot of backend work behind these pages, but the public side is gradually starting to resemble the portal we actually want to keep for the long term.

A lot of today's work happened on the side players should rarely need to think about. We continued defining how support and moderation staff are allowed to act once the live service eventually has real accounts and real consequences.

Sensitive production changes are deliberately being designed around independent review instead of letting one person quietly make permanent changes. Character modifications go through an even stricter path before an administrator can confirm them.

The same thinking applies to evidence and audit history. If something important happens to an account, we want a record that can be reviewed later rather than relying on someone's memory of a chat message.

We returned to the support structure today and worked through how a player should actually move from choosing a problem to submitting a useful ticket.

The flow now has a much clearer shape: category, more specific issue, description, attachments and a final review before submission. Urgency is handled internally rather than asking players to guess which priority label will get them the fastest answer.

Live chat is also being treated as part of the ticket rather than a completely separate conversation, which should make handovers and later reviews much easier.

Inventory, loot and equipment have reached an important point for Alpha 0.1. The core runtime path now covers enemy drops, pickup, stacking, item levels, durability, requirements, equipment, runtime stats and the information shown in item tooltips.

That does not mean the final game inventory is finished forever. It means the foundation is finally solid enough that our time is better spent playing with it, finding real problems and moving on to animation, effects, balancing and the rest of the test build.

Getting to the point where a system can be used instead of constantly rebuilt is a very welcome kind of progress.

Today we worked through the equipment side of death and durability. If an item is equipped when durability loss is applied, that state has to survive unequipping, moving through the inventory and being equipped again.

We also tested the underlying durability calculations rather than trusting that the numbers happened to look right in one play session.

It is another quiet system, but one that becomes painful very quickly if item state can be duplicated or reset by moving gear around.

The 28-slot inventory has reached a point where the objects inside it behave like actual runtime items. Individual instances carry their own identity, quantity, item level, durability and binding state.

Stack filling and splitting are handled deliberately, items with incompatible runtime state are not silently merged and a full inventory is treated as a failed transaction rather than half completing an operation.

This is exactly the kind of system we wanted to get solid before building more content on top of it. Fixing inventory rules with ten test items is much nicer than fixing them once hundreds of drops exist.

Sina worked further on armour for characters whose anatomy changes what an item can reasonably look like. That included headpieces that leave deliberate openings for large antennae and armour that mixes harder organic plating with softer materials.

One ceremonial direction uses hardened pale chitin alongside processed silk and softer collar shapes. Another set stays much more practical with iron and leather. The important part is that they should feel as though different people in the same world could genuinely have made them.

We are trying to build that variety into the equipment from the start instead of solving it later with recolours.

We spent today locking down more of the talent-tree structure. Each class is built around three paths with ten rows, and progress through those rows is controlled by how many points have already been invested rather than by simply clicking anything on screen.

Normal nodes can take multiple points, while the final row contains the three ultimate choices. The overall point curve is also tied to character progression so reaching level 60 has a clear final talent milestone.

The UI side is starting to reflect those rules as well. Nodes need to communicate whether they are empty, partially invested, available or still blocked without turning the whole tree into a wall of text.

Armour work continued today, but not as a single finished costume. Sina has been working through helmets, shoulders, chest pieces, arm protection, leg armour and boots individually so each part can stand on its own before the whole set is judged together.

That process makes it easier to catch things that feel wrong. A chest piece can be too heavy for the legs, a helmet can fight against the character's anatomy, or the boots can suddenly make a set feel as though they came from somewhere else entirely.

It is slower, but it also means we are not hiding bad individual pieces inside an otherwise nice silhouette.

The HUD received another proper pass today. Health and resource orbs are working with the underlying values, while the experience bar now grows outward from the centre rather than behaving like a normal left-to-right progress bar.

We also added room for the current level on one side and the future Ash Rank on the other. Recent experience gains can be shown separately so gaining XP does not disappear into a bar with no feedback.

There are still plenty of visual details to polish later, but the important part is that the HUD is becoming useful during actual play instead of existing only because an ARPG is expected to have one.

The current skill bar uses keys 1 through 6, and today we continued tightening the path from pressing one of those keys to actually resolving a skill.

The game checks the equipped skill, reads its data, checks and spends the required resource, runs the cast time and then executes the effect. For our current damage tests that finally reaches the same damage system the enemies already understand.

The skill data itself is much broader than a handful of test attacks. The table already contains hundreds of entries covering direct damage, damage over time, control, buffs, debuffs, healing, shields, summons and more complex combinations. The important part now is making the runtime flexible enough to grow into that data rather than forcing every ability into the same simple shape.

Combat is beginning to feel connected rather than staged. Damage is being passed into the enemy base correctly, health is reduced and enemies can now reach a proper dead state instead of simply standing around at zero health.

That sounds like a small milestone, but it connects directly to several other systems we have been building. Enemy death can lead into loot, loot can reach the inventory and the HUD can react to what is happening during the fight.

There is still a long way to go in animation, effects and combat feel, but the underlying loop is finally becoming something we can build on rather than something we have to fake.

Not every item-system day is about exciting drops. Today was mostly the plumbing underneath them: quantities, stack limits, splitting stacks, item levels, binding state and durability.

Each individual runtime item now needs to carry its own state instead of being treated as nothing more than a row in a data table. That becomes especially important once two otherwise identical items can have different durability, levels or binding states.

It is the kind of work that players should ideally never have to think about. If we do it properly, they can simply move, equip and compare items without ever noticing how much bookkeeping is happening underneath.

The inventory work continued today with the equipment side of the loop. Picking up an item is only the first half of the job; the game also needs to know where that item can be equipped, whether the character is allowed to use it and what happens when it comes back out again.

The current equipment layout includes the expected armour and jewellery slots as well as main-hand and off-hand handling. Two-handed equipment also needs special treatment so the off-hand cannot quietly hold something that should not be there.

We are trying to solve these rules now rather than patching around them later when hundreds of items depend on them.

Sina continued developing a more grounded armour direction today, mixing iron, leather and practical shapes instead of pushing every set toward ornate fantasy armour.

That balance matters to us. If every item looks legendary, then legendary equipment stops feeling special. Common and early-game gear still needs a recognisable silhouette and enough detail to feel like something people in Arandresia would actually make and wear.

A lot of the work is in small decisions: how heavy the chest should feel, how the boots match the leg armour and whether a helmet still makes sense once it is placed on the character it was designed for.

Today was mostly about connecting systems that had previously worked in isolation. Enemies can die, something can drop, the player can pick it up and that result can now continue into the inventory instead of ending at a debug message.

Gold is part of the same loop, and we have been paying particular attention to what happens when the inventory cannot accept something. A full inventory should not quietly lose half an item stack or leave the game in a strange state.

It is a very basic ARPG loop on paper, but getting it reliable is important. Loot stops being interesting very quickly if the systems underneath it cannot be trusted.

Sina spent more time today on armour shapes and proportions. One thing we do not want is to design a normal human armour set first and then simply force it onto every body shape later.

Helmets, shoulders, chest pieces and lower armour all have to leave room for the features of the character itself. That means thinking about things like antennae, unusual proportions and how different materials can bend or overlap without making the set look accidental.

It takes longer than simply producing another variation of the same armour, but the goal is that even ordinary equipment should look as though it was made for someone who actually lives in this world.

A lot of today's work went into something that sounds simple until every part has to stay in sync: the HUD. Health and the class resource now have a much clearer place in the interface, and we continued connecting those elements to the values the game is actually using rather than treating them as decorative bars.

This is one of those jobs where progress comes from removing little lies from the screen. If the player takes damage, spends a resource or gains experience, the interface has to react properly. It is not flashy work, but every part that starts behaving correctly makes the test build feel a little less like a prototype.

The Yashariel community forum has reached its first complete production-ready state. What began as a website forum has grown into a connected community system that links the official website with Discord.

Posts and replies can move through the shared system while moderation workflows, deletion states and other community actions remain controlled and traceable. The goal is to make both platforms feel like parts of one community rather than two unrelated discussion spaces.

The forum has also been prepared with official German and English guides and overview posts so future players have a clear structure from the beginning. Community Forum V1 now provides a stable foundation for the next stage of Yashariel's community development.

The website and Discord community systems are no longer being treated as separate islands. Forum posts can now be represented across both platforms while keeping a shared relationship between the original discussion and its connected counterpart.

Replies and important community actions were brought into the same workflow so conversations remain understandable regardless of where a community member takes part.

This milestone moves Yashariel closer to the wider ecosystem we want to build: a community in which the website and Discord support each other rather than forcing players to choose one platform.

Weapon design continued across a much broader range of item qualities. The goal is not simply to change the colour of an item name, but to make increasing rarity visible in the weapon itself.

Lower qualities remain comparatively restrained, while higher tiers can introduce more complex shapes, stronger materials, larger details, glowing elements and increasingly unusual silhouettes.

This work is helping define a consistent visual language for equipment progression so a powerful weapon can feel more important before the player even opens its tooltip.

A major part of the community work is the connection between the official website and Discord. Instead of building two independent places that happen to share the same project name, we began establishing a bridge between them.

The first work focused on how forum discussions could be represented consistently and how actions on one side could remain understandable on the other.

This is infrastructure work more than a visual feature, but it supports an important long-term goal: the Yashariel community should feel connected no matter which official platform a player prefers.

The website is becoming more than a collection of information pages. Work continued around account, login and registration flows so the public site can eventually support the wider player ecosystem.

At the same time, the language system was expanded with English and German as the active public languages. Navigation, account areas and more of the surrounding website structure are being brought under the same language rules.

Both areas are still part of ongoing development, but they establish important foundations for a website that will eventually connect players, community features and game-related account services.

Support for Yashariel is being designed as a structured system rather than a simple inbox for player messages. We worked through how a request should move from first contact to investigation, review and final resolution.

The workflow includes defined handovers, internal reviews and escalation paths for cases that need additional attention. Important decisions and actions are also intended to remain documented so a case can still be understood after it has been completed.

Planning these processes before the first public testing phases gives us time to refine them without real players having to become the test case for an unfinished support organisation.

Long before Yashariel has a large player community, we want to understand how that community should be supported. Planning therefore began around the roles and responsibilities a future support organisation will need.

Different support areas require different knowledge, responsibilities and access. The planning also covers how support work, staff responsibilities and administrative responsibilities remain clearly structured as the team grows.

Training and role-specific knowledge are part of the long-term plan as well. The purpose is to build the workflow before scale makes improvisation expensive for both players and the team.

Environmental design continued with focused visual work for Bloodmoor and the Demon Paths. Both regions need their own identity without feeling as if they belong to completely different games.

Bloodmoor leans into a hostile, corrupted landscape, while the Demon Paths push a more threatening and unnatural atmosphere. Architecture, terrain, materials, lighting and environmental shapes all contribute to that distinction.

The broader rule remains unchanged: regions should feel dark, unsettling and recognisable from the isometric game camera rather than existing only as detailed concept art.

A two-person project still produces a surprising amount of data. Game files, design references, artwork, documentation and website work all need to remain organised and available without turning one computer into the single source of truth.

We therefore continued improving the shared project workflow so design work and technical implementation can move between the devices used for development more reliably.

This does not create a visible gameplay feature, but it reduces friction between creative preparation and implementation. Better organisation means more time can go into the game itself instead of locating or moving project files.

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.