itch.io

While working on Mirror Siege, I started thinking about something that goes far beyond graphics:

How much can the same strategy game change when you move from 2D → 2.5D → full 3D?

Mirror Siege currently exists as a relatively simple playable prototype.

The core idea is straightforward:

Build an army → deploy squads → counter the enemy → break through defensive Towers → destroy the Castle.

But what happens if the core mechanics stay similar while the perspective, terrain, and presentation change?

1. 2D — Maximum battlefield readability

A top-down 2D version makes it very easy to understand the entire battlefield.

You can quickly see:

• army composition
• unit positions
• Towers
• paths
• threats
• available space

This makes 2D extremely useful for large-scale strategy.

But elevation is mostly represented visually rather than physically.

[IMAGE — 2D TOP-DOWN]

2. 2.5D / Isometric — Terrain starts becoming part of the strategy

With an isometric or 2.5D battlefield, the same game can suddenly gain much more visual depth.

Now we can clearly show:

• high ground
• cliffs
• ramps
• bridges
• valleys
• multiple elevation levels

Imagine ranged units defending a cliff while infantry holds a narrow bridge.

Or Cavalry being extremely powerful on open ground but struggling through narrow mountain paths.

The army composition may remain the same, but the battlefield can force completely different decisions.

[IMAGE — 2.5D / ISOMETRIC]

3. Full 3D — Scale and elevation become much more physical

A full 3D version could change the feeling again.

The camera could move, rotate and zoom across a real 3D battlefield.

Armies could:

• climb hills
• descend into valleys
• cross bridges
• move around mountains
• attack fortified high ground
• choose completely different approaches to the same objective

A Tower on a hill would not just look higher.

It could actually dominate a larger part of the battlefield.

[IMAGE — 3D BATTLEFIELD]

Terrain may change the game even more than graphics

This is the part that interests me the most.

Imagine playing Mirror Siege on four different maps:

Open Field Fast movement, large formations, strong Cavalry.

Mountain Pass Narrow routes, high ground, chokepoints, difficult flanking.

River & Bridges Crossings become strategic objectives and armies must choose where to commit.

Fortress Assault Walls, gates, multiple defensive layers and siege routes completely change how an army attacks.

Same units.

Same basic combat system.

But potentially a very different battle.

[IMAGE — MOUNTAIN / BRIDGE / FORTRESS]

That made me realize something:

2D, 2.5D and 3D are not only visual choices.

For a strategy game, perspective and terrain can influence how information is presented, how armies move, how players position units and ultimately how the entire battle feels.

Mirror Siege is still only a prototype, so these images are concept explorations, not promises of future features.

But I find this direction extremely interesting.

If more time, resources and development were invested into the project, I would love to explore how far terrain and perspective could push the original idea.

What would you prefer?

A — Clear 2D top-down strategy B — 2.5D / Isometric with stronger terrain gameplay C — Full 3D with large battlefields and real elevation

Or would you combine parts of all three?

I would love to hear what other developers and players think.

Playable prototype:

https://jxnhalam.itch.io/mirror-siege

I will keep updating this thread as I experiment with the design.

Hello everyone,

This is my fifth small game project: Exact Damage: Endless Equation.

Play it here:

https://jxnhalam.itch.io/exact-damage-endless-equation

The main rule is simple:

Build an equation using addition and subtraction so the result matches the current boss HP exactly.

However, every number has limited uses shared across the entire boss chain. An equation can be mathematically correct for the current boss but still be the wrong strategic choice because it may consume numbers required for the later bosses.

The current build includes:

• Progressive difficulty

• Addition and subtraction

• Endless procedurally generated stages

• Limited number uses

• Multiple bosses in later stages

• Exact equations that can become strategic traps

• Solver-verified stages

• Seed-based replay

• Desktop and mobile browser support

I recently changed the early stages because the original version introduced too many mechanics at once.

Now:

• Stage 1 teaches exact damage with one boss

• Stage 2 teaches combining several numbers

• Stages 3–4 introduce planning across multiple bosses

• Trap equations appear later

• Subtraction is introduced after the basic rules are understood

I would especially appreciate feedback about:

1. Is the game understandable during the first two stages?

2. Does the difficulty increase too slowly or too quickly?

3. Is the interface comfortable to use?

4. Are the number-use limits clear?

5. Does solving multiple bosses feel strategic or frustrating?

6. Does the game display correctly in fullscreen and on mobile?

7. What would make you continue playing for more stages?

Multiplication and division may be added in a future update, but I want to make the addition and subtraction version work well first.

Thank you for playing and sharing your feedback.

Hello everyone,

This is my fourth game idea, and I would really appreciate some honest feedback from developers and players.

Project page:
https://jxnhalam.itch.io/accessible-war-royale-public-game-concept

Accessible War Royale is a public battle royale game concept designed for players who may experience poor eyesight, dizziness, motion sickness, or difficulty understanding complex 3D environments.

The main idea is to add optional visual guidance systems, such as:

• Directional lines connecting the minimap to important locations in the 3D world.
• Clear descriptions such as “behind the rock” or “inside the smoke.”
• Simplified visual information during combat.
• Accessibility features available to every player, not only selected users.
• Some guidance systems could be disabled during the final circle or Top 10 to maintain competitive tension.

This is currently a game design concept, not a finished game. I am trying to understand whether these systems would genuinely help players or accidentally create unfair advantages.

I am specifically looking for feedback about:

1. Would these accessibility features make a battle royale easier to understand?
2. Which features could negatively affect competitive balance?
3. Should accessibility guidance remain active during the final circle?
4. Is the concept explained clearly enough on the project page?
5. What should I simplify, remove, or develop further?

Honest criticism is welcome. I am not only looking for encouragement—I want to identify weaknesses in the idea before developing it further.

Thank you for reading and sharing your thoughts.

Hi everyone!

I am currently developing a game concept called My Sister’s Farm.

Project page:

https://jxnhalam.itch.io/my-sisters-farm

My Sister’s Farm is a cozy, day-based fantasy farming and management game being designed with Godot 4.

The player begins with a small farm on a magical archipelago. The basic gameplay loop is:

Prepare the soil → plant seeds → water crops → advance the day → harvest → sell → improve the farm.

As the farm develops, players can raise animals, hatch dragons, craft food and medicine, unlock new facilities, and explore islands that introduce different gameplay systems.

Some planned islands include:

- Dragon Island for eggs, incubation, and major progression

- Plant Island for herbs, medicine, and alchemy

- Monster Island for light automation

- Ice Island for preservation and cold storage

- Volcanic Island for faster crafting and incubation

- Snake Island for poison plants and disease resistance

Animals and dragons are intended to provide useful abilities rather than simply generating unlimited money. They may help with watering, crop growth, preservation, crafting, disease protection, or reducing repetitive actions.

The project is currently in the design and early development stage. The itch.io download contains the Game Design Document and concept materials. There is no playable build yet.

I would especially appreciate feedback on these questions:

1. Does the main farming and progression loop sound clear and interesting?

2. Do the different islands feel meaningfully different?

3. Would collecting animals and dragons motivate you to continue playing?

4. Does the day-based system sound more appealing than real-time waiting?

5. Which feature would you prioritize for the first playable prototype?

6. Is the overall project scope too large for an early indie project?

I am also open to feedback about the interface concept, economy, progression, and visual direction.

Thank you for taking the time to read about the project!

Hi everyone,

I am currently developing a game concept called Shadow Strike.

Project page:

https://jxnhalam.itch.io/shadow-strike

Shadow Strike is a dark neon fantasy 2D action RPG that combines AFK progression, skill collection, custom combo building, and real-time platform PvP.

The main gameplay systems currently planned are:

- AFK progression and automatic PvE combat

- Skill gacha and skill collection

- Custom skill loadouts and combo synergies

- A Forge system for upgrading skills

- Training Dummy Mode for testing damage, DPS, and combos

- Real-time 2D PvP with jumping, dodging, and air-dashing

- Three-layer platform arenas

The current download is not yet a playable prototype. It contains the game design document, concept direction, and visual mockup screenshots.

I am specifically looking for feedback on these questions:

1. Does combining AFK progression with skill-based real-time PvP sound interesting, or does it feel like two different games?

2. Is the skill collection, loadout, combo, and Forge progression loop clear enough?

3. Would a Training Dummy Mode focused on DPS testing and combo experimentation be useful and enjoyable?

4. Which system should I prototype first: the AFK battle, Training Dummy Mode, skill loadout system, or platform PvP?

5. Are there any major problems or risks you can already see in this concept?

Please feel free to be direct. I would rather discover the weaknesses of the idea early than build too much in the wrong direction.

Thank you for reading and for any feedback.

Hi! Thank you for pointing out the broken link and for asking this question.

Yes, defeating the boss is the shared objective, but defeating it as quickly as possible is not the main purpose of the game.

The boss is intended to be a social gathering point.

I want players to spend time together, talk, cooperate, joke around, create small conflicts, and react to one another. Some players may choose to help, while others may heal the boss simply because they enjoy creating chaos.

That choice is part of the experience.

The troll player is not necessarily “playing incorrectly.” They are creating another challenge for the community. The other players must communicate, adapt, use counter-skills, and continue working together despite the disruption.

The goal is not:

“Everyone spam attacks, kill the boss quickly, collect rewards, and immediately move to the next stage.”

The goal is:

“Can this group of strangers stay together, interact, and eventually overcome the boss—even when some members decide to troll them?”

Boss healing and other troll abilities would still need limits so that victory remains possible. However, I do not want to remove the freedom to troll entirely, because the unpredictable player behavior is an important part of the game’s identity.

The boss provides the challenge, but the players create the story.

Your comment helped me realize that the current project description focuses too much on defeating the boss and not enough on the social experience I actually want to create. I will clarify that. Thank you!

Welcome to the ONE DAMAGE BOSS community.

Hello everyone,

I am developing an early multiplayer game concept called ONE DAMAGE BOSS.

The central rule is simple: every player deals exactly 1 damage per valid attack. No individual can defeat the boss alone, so the entire community must work together.

The concept also includes controlled troll skills that can heal the boss, protect it, stun players, or summon mini-bosses. Every troll mechanic has limits and community counterplay.

This is currently a public GDD and visual concept, not yet a playable build.

Project page:

https://jxnhalam.itch.io/one-damage-boss-public-game-concept

I would appreciate feedback on the core mechanic, multiplayer structure, boss phases, and whether the troll system sounds entertaining or frustrating.

Welcome to the ONE DAMAGE BOSS community.

This is an early public game concept where every player deals exactly 1 damage to a shared world boss.

Please share your feedback about the core gameplay, boss mechanics, support skills, troll abilities, multiplayer structure, and anything you would like to see in a future prototype.

Welcome to the Accessible War Royale / War Assist Battle community.

This project is currently a public game concept and GDD stage project. There is no playable build yet.

The goal is to explore a clearer, fairer, mobile-first battle royale concept built around readable combat information and accessibility.

Core idea:

• Directional Line Assist shows approximate enemy direction, not exact position.
• Smoke assist only shows that an enemy is inside the smoke zone.
• Cover assist only shows that an enemy is behind a rock, wall, or building.
• The system does not show enemy body outlines, hitboxes, or exact hidden locations.
• When the match reaches Top 10 or the final circle, enemy assist is disabled so the final fight is decided by skill.

I am looking for people interested in discussing or helping with the prototype:

• Gameplay programmers
• Unreal Engine / Unity / Godot developers
• UI/UX designers
• 2D/3D artists
• Multiplayer developers
• Testers
• Small partners or investors

The first goal is not to build a huge game immediately. The first goal is a small playable prototype with one test map, bots, smoke, cover, Directional Line Assist, and Final Phase Assist Shutdown.

Feel free to share feedback, questions, ideas, or interest in helping.

Prototype first. Then scale.