Devlog – Post-Update Retrospective – Current Dilemma

Introduction

As briefly mentioned in yesterday’s update log, I’d like to reflect on the current challenges I’m facing.

Since starting this toy project in April, I’ve released two builds.

• The first build (v0.0.1) was a barebones prototype.
  I uploaded it mainly for self-motivation, and it lacked real gameplay elements.
  It featured only a rudimentary interaction system for RPG mechanics, and combat existed in the most minimal form.

• The second build (v0.0.2) went live a few days ago.
  It’s still a very early prototype,
  but I’ve added stats, items, progression mechanics, and some combat traits.

I originally planned to label this update as v0.1, but ultimately decided on v0.0.2.

Of course, versioning methods are varied and subjective, and even considering the fact that game builds tend to use more conservative versioning than typical apps, this was an especially cautious choice.

A Development Crossroads

Version numbering itself isn’t crucial, but it highlights the deeper dilemma I’m wrestling with.

This update marginally improved the game’s overall completeness. Yet I began to question whether my current direction is steering me toward a better game—or just a more polished program. Even evaluating it purely as a technical exercise, my own playtesting didn’t yield satisfying results.

And even if it had scored higher, I couldn’t be sure this approach would be sustainable or effective for a solo developer aiming to reach a meaningful milestone.

In game development, direction matters more than implementation.

It sets the foundation for everything that follows.

To move beyond the prototyping phase, I need to make some serious design decisions. Simply expanding on the current systems won’t cut it.

Key Points Under Consideration

1. Genre, and System Depth
   Though I’ve labeled this a roguelike-inspired game, under closer scrutiny it functions more like a lightweight ARPG roguelite. While it doesn’t heavily emphasize action, it also lacks the systemic depth of a true roguelike.

   So the issue isn’t just classification, but which direction to pursue. Broadly, I’m weighing four potential paths:

   • Turn-based roguelike (focus on progression mechanics)
   • Real-time roguelite (blend of progression, interaction, and action)
   • Short-form survival (bullet-hell style)
   • Classic ARPG (focus on action and interaction)
   • Classic RPG with tile-based movement

2. Camera Perspective
   Depending on the chosen direction, the camera perspective may need to change:

   • 2D top-down (45° angle)
   • 2D side-scroller
   • 2.5D orthographic top-down (45° angle)

3. Technical Requirements
   As the project evolves, I may need to consider swapping engines, frameworks, or languages—though I plan to avoid drastic shifts unless there’s a compelling reason.

These considerations go beyond simply "what kind of game do I want to make?"

They’re about finding a sustainable balance between design, art, and development within my solo capabilities (for example, limiting scope to manageable feature sets).

At a glance, a roguelite may seem like the safer choice, but it often demands better assets and stronger storytelling to truly stand out.

In contrast, while a roguelike doesn’t rely as heavily on those elements, it can only be competitive and unique if its systems are exceptionally well-designed.

So I can’t say for certain which of the two paths would ultimately be the better one.

Conclusion

Until I land on a clear direction, I may end up resetting the project a few times or creating spin-off prototypes for validation.

This process is part of the journey to pinpoint the optimal balance and refine the game’s core vision.

Of course, nothing is ever an easy path. I simply wanted to reflect on making better choices for myself.