next »

[Tangleworm]

Alpha Build Available!

Thanks for taking a look! I have a playable work-in-progress version up at https://magnesiumninja.itch.io/nomia.

Hi everyone! I'm making an isometric tactics game called NOMIA.

What's the summary?

It's Final Fantasy Tactics meets Slay the Spire.

It's about a group of adventurers navigating a dreamlike world, where things that fade from the collective memory coalesce into places and creatures. It's an exercise in making a cozy fantasy setting that explores lesser-seen worldbuilding elements.

What makes this unique?

I'm focusing on three things that I hope will make for a fun and unique experience.

1. Your hand has two halves.
The left side of your hand represents your Actions, which persist between turns, but have charges and cooldowns.
The right side of your hand represents your Gambits, which are drawn from a deck of cards each turn, and are discarded when played.
You can add to both decks over the course of a run, expressing your playstyle through character building as well as deckbuilding.

2. Your party has two heroes.
You'll always pick two at the start of each expedition -- a Mighty and a Magical.
The Mighty has more Actions.
The Magical has more Gambits.

Each has a unique deck of possible cards.

3. Your enemies have tells.
Enemy intents are shown on your turn, rewarding clever defense.
Intents are adjusted when you play cards, but not randomly; enemies have a goal in mind and will do their best to achieve it, allowing you to counterplay.

You can make enemies reconsider their intent by attacking them. A character can play tank for their partner if they're in a pinch.

What am I working on?

I've spent roughly the last four months laying the groundwork for the card battle system, and figuring out a card creation pipeline and art style that would make it feasible for me, one (1) person, to make hundreds of unique and interesting cards.

I hope to achieve a sense of multiplicative game design -- that is, each aspect of the game creates synergies with the others, creating many possibilities and stories.

Next, I'll be working on run progression, and unique map/enemy generation for the different biomes I have in my head.

Thanks for taking the time to read my devlog!

What does NOMIA stand for?

It stands for No One Makes It Alone. I am, ironically, making this alone. But I also like to think of it as a meditation on the fact that even in this situation, I'm benefiting from the work of countless people who have inspired me and laid the groundwork for what I'm trying to do.

[Tangleworm]

Devlog 2 -- World/Enemy Generation

I'm pursuing random generation as a way to create lots of unique situations with less effort on my part. Completely random generation ironically ends up making everything feel same-y, so I'm working on making each biome unique by giving each a different generation algorithm.

Each biome will have unique enemies, with a small chance of enemies from "neighbouring" biomes wandering in, or enemies from the "universal" enemy set being sprinkled in.

To create a sense of ebb and flow, enemy generation is also not completely random, but intended to flow between "big" enemies with unique mechanics and "small" enemies that are only a threat in large numbers.

To make it feasible for one (1) person to make a lot of enemies, each is represented by a single illustration. I wanted to make each look like a tarot card and/or a comic panel.

[Tangleworm]

Devlog 3 -- Diagonals

(Been working on the mix of enemy generation, but I haven't done the art for many of them yet!)

There's lots of weird stuff that happens when your game is tile-based, like how to handle movement and knockback.

There's lots of ways to handle "distance" in a tile-based world. You could make it so that 1 unit of movement lets you step left, right, up, or down -- this is called rectilinear distance, or Manhattan distance. Fire Emblem does this. You could make it so that a unit of movement also lets you step diagonally -- this is called chessboard distance, or Chebyshev distance. Many D&D battlemaps do this.

I decided to go with rectilinear distance for this game, since it's more intuitive when we consider distances in the real world. This means that going diagonally costs 2 points of movement -- an attack with a range of 2 will only be able to target the immediately adjacent diagonal tiles.

However, certain attacks can move the caster (lunging and retreating), the target (knockback and pull-in), or both. There are a number of ways we can make a "line" from one point to the next in rectilinear geometry. How do we handle non-orthogonal pushing and pulling?

I could think of three ways to handle it.

1. Don't

If we restrict any self/target-moving abilities to just the orthogonal tiles, we can sidestep the whole issue. This is simple to implement, and the player will always understand exactly how knockback will work, because it only happens when we can count exactly how many tiles everything will move.

The downside to this is that this cross-shaped target can get extremely annoying when you want to hit an enemy that's directly diagonal to you. Because movement costs an action point in this game, it can get annoying to have to spend that point to do a very minor positional adjustment to hit an enemy that already "feels" adjacent to you.

2. Kinda Do

If the target is at exactly 45 degrees, it only gets a little more complicated to understand, but it gets a lot less annoying at close ranges. Every diagonal tile needs 2 units of knockback.

The tricky part is handling the different corners an enemy can get knocked into. Because knockback does damage based on how much remaining knockback there is when the unit hits a wall, how do we handle when it hits a corner, but there's only 1 unit of knockback left? How do we handle them hitting a convex corner (e.g. being shoved into the corner of a building from the exterior) versus a concave corner (e.g. being shoved into the corner pocket of a pool table)? Can we make this intuitive for the player to understand?

3. Really Do

We can go all the way and let knockback abilities hit every tile a non-knockback ability can.

This is difficult for both the developer and the player, since there are many ways to form a line (i.e. the shortest distance between two points) when we're in rectilinear space. Should we snap the knockback to the closest direction? Should we push the enemy on a path that might not be what the player wanted? Should we let the player choose, and slow down the decision for every knockback card by an extra click? Even this diagram is complex to look at, and we haven't even gotten into handling convex corners versus corner pockets.

It didn't seem worth it for the tradeoffs.

In the end: I originally went for Don't, but after some consideration I'm partway through implementing Kinda Do, and I'm happy with this choice. It prevents knockback-related abilities from feeling underpowered due to needing to spend an action point on a minor positional adjustment before casting them, and most knockback abilities are close range anyway.

If anything, this shows how much thought must have went into the various tile-based worlds we've seen before.

[Tangleworm]

Just a small update! Drawing more enemy cards, trying to find a balance with how much time I want to spend on each one.

[Schrompf]

I like the isometric graphics style! Nice colours.

Deck building. Hm. Well, maybe others will enjoy this.

[Tangleworm]

I like the isometric graphics style! Nice colours.

Thanks!

Deck building. Hm. Well, maybe others will enjoy this.

Aww.

Devlog 4 -- Stealing

As TVTropes puts it, there are three main archetypes for fantasy RPG characters -- Fighter, Mage, and Thief. The Actions vs. Gambits system lets me express the Fighter vs. Mage distinction, but how would I express that a character is a Thief when there's no stealth or social mechanics?

I had the idea of giving the player the ability to copy, i.e. "steal", cards. Because all abilities (even enemy abilities) are represented by cards under the hood, part of a Thief's repertoire would be to copy abilities from enemies, allies, and even themselves.

To offset the fact that you can't choose which card(s) you copy, they're played for free, but immediately destroyed afterwards. I hope this leads to wild moments when everything lines up perfectly, and it also helps multiply the possibility space because every enemy ability is now potentially a player ability.

Besides this, I'm still chipping away at enemy art, and working on menu and game flow behind the scenes. Hopefully I'll have the most basic vertical slice soon.

[nathy after dark]

The art and design are very crisp and clean! Reminds me of Transistor's aesthetic.

[Tangleworm]

The art and design are very crisp and clean! Reminds me of Transistor's aesthetic.

Aw thank you! That is high praise :D

[robotbard]

Wow, this looks super interesting!!

I'm working on a game with similar inspirations (FFTactics, Slay the Spire, and Into the Breach) and ended up in a very different place in terms of combat. I'll be sharing mine soon, but you're miles ahead of me! I love the gameplay you've shared.

Some questions:

• Do you grow your party of characters over the course of a run? Or do you grow the decks of the 2 characters you start with? Or both?
• Assuming you stick with the 2 characters, do they have separate hands? I couldn't quite tell from the videos. Or are their cards mixed into one hand for the player? What about buffs like Shield?
• What do the card pools look like? Is it like Slay the Spire, in which each character has several archetypes but draw from the same pool of possible cards to draft?

Super exciting, I will absolutely be following this!

[Tangleworm]

Wow, this looks super interesting!!

I'm working on a game with similar inspirations (FFTactics, Slay the Spire, and Into the Breach) and ended up in a very different place in terms of combat. I'll be sharing mine soon, but you're miles ahead of me! I love the gameplay you've shared.

Thank you! Looking forward to seeing your game as well!

• Do you grow your party of characters over the course of a run? Or do you grow the decks of the 2 characters you start with? Or both?
• Assuming you stick with the 2 characters, do they have separate hands? I couldn't quite tell from the videos. Or are their cards mixed into one hand for the player? What about buffs like Shield?
• What do the card pools look like? Is it like Slay the Spire, in which each character has several archetypes but draw from the same pool of possible cards to draft?

• You stick with the two you've selected at the start, and grow their decks. I'll eventually implement StS-style relics for them as well; still thinking of whether I want items to apply to both characters or individually.
• They do have separate hands!
• Each character has a unique card pool -- I'm aiming for about 50-75 unique cards per character, along with a "universal" card pool that touches on every mechanic.

[Tangleworm]

Working on some menu flows! I wrote simple two-line poems introducing each area, and I'm planning to add some more punch to them later on.

[robotbard]

The animations are looking super sharp, and battle is very readable.

How are you solving (or how have you solved) for overlapping units on the map? I see the health bubbles above their heads - what does it look like when a unit is directly in front of another on the diagonal? I ask because I'm trying to solve this myself. I gave up attempting to have health visible on all units at all times, just because the HUD elements obscured the map and other units, though my pixel art style is different than your smooth, high-resolution lines, so perhaps it hasn't been a concern for you.

Into the Breach hides health bars outside of the unit you're hovering, which is the behavior I imitated, but Alina in the Arena has a "stretched" hex grid that allows health to be visible on all units in an unobtrusive way, which obviously isn't possible in an isometric grid. Final Fantasy Tactics has no health hovers and handles it entirely in the HUD pop-ins, likely due to resolution constraints. Funny how simple decisions like this end up becoming key UI considerations...

Cheers!

[Tangleworm]

The animations are looking super sharp, and battle is very readable.

Thank you so much! Your game is looking fantastic too! I'll drop a comment in your devlog in a moment :D

How are you solving (or how have you solved) for overlapping units on the map?

That's something I pondered a lot myself! At least for the time being, I'm solving this through art direction. I use a circle motif so you can see through the "corners" of a unit portrait, and I make the top circle of an enemy card semi-transparent so you can still see the unit behind it.

That's my main way of keeping things clear while keeping all information on the table, but there are a few other things I felt enhanced this:

• Unit portraits have also been carefully proportioned so that there's just enough room for little icons to peek through, i.e. status effects above the health orb and intent icons below. There can be overlap, but nothing ever completely obscures another thing.
• Units are taller than walls so they're never completely obscured, and there's a see-through shader for walls on top of that.
• Using a tooltip system also allows me to compress a lot of information into a tiny icon, since it's still convenient for the player to examine the unit to clarify what any icon means.

Things can still get visually cluttered with many units on the screen, so I'm also considering things like being able to inspect individual units by opening a focus window, or rotating the camera in 90 degree chunks to reorient the world. Hopefully things will be clear enough that these are bonuses rather than necessities, though.

Thanks for dropping by!

Devlog 5 -- Room Generation

Roguelike dungeon generation is ultimately a pacing mechanism -- a well-generated dungeon is one that creates a good rhythm of rising and falling tension when exploring it. Since NOMIA's setting works on dream logic, I thought it'd be fun to have the player go through the dungeon as it's being generated, rather than afterwards.

This conveniently makes it easier for me to pace the run, since we can decide in the moment where the next paths go.

To that end I've been rewriting the map generation system, moving away from separate algorithms for each area to one very parameterized algorithm and different "chunks" for each area. Eventually I'll have animations for new tiles coming in and old tiles falling out.

[Tangleworm]

Devlog 6 -- Actually Deckbuilding

I've implemented card rewards after each battle! It feels nice to be approaching a proper vertical slice. (does having a Roll card officially qualify my game as a soulslike?)

I've also made a battle log system so players can review what happened.

Designing the card reward mechanic was an interesting challenge -- we have two characters, each with two decks of cards. How do we let the player incrementally build these decks while not overwhelming them with complexity?

My goals were to:

• Lean towards many simple choices, rather than few complex choices -- let depth emerge from the sum.
• Not overwhelm the player with too many choices in a row, because that feels the same as making a single overly-complex choice.
• Encourage balance in how much each character is developed.

I could think of three ways to handle it.

1. Shamelessly Copy Slay the Spire, But Four Times

The most naive way to get this working would be to have separate drafts for each character and deck -- Mighty Actions, Mighty Gambits, Magical Actions, and Magical Gambits.

It would certainly ensure that characters are developed equally, but even thinking about this many choices in a row makes my head hurt. Would we need to make four choices after each fight? Would we only get to make these choices after every 4 fights? Would these choices rotate in a round-robin format, and potentially rob the player of a critical choice if they happened upon a boss battle at the wrong time in the cycle?

None of these options seemed appealing.

2. Shamelessly Copy Slay the Spire, But Twice

If we can't just make the player draft four times, why not twice?

I could see an advantage to separating Actions and Gambits; it would make sense to gain a Gambit every battle, but less so an Action every battle, because they'd rapidly clog your hand. I could reserve Actions as boss-battle rewards, or maybe an option at a rest event.

However, because Mighties rely more on Actions, doing so would leave them to stagnate between these "big" events. It would also reduce the excitement of each draft if you really wanted a new Action and knew you wouldn't ever get one, and it would increase the frustration of finally arriving at an Action draft and disliking every choice.

3. Shamelessly Copy Slay the Spire, But Once

I realized the elegance of the original's draw-three-pick-one reward. Any card can theoretically appear, which is exciting, and the next choice is never too far away, which mitigates the frustration of bad draws.

By mixing all four decks into the pile, I'd have to manage some probabilities to encourage balance:

• The left card has a high chance of being a Mighty card, while the right card has a high chance of being a Magical card. The middle card is equally likely to be either.
• Whoever has drafted fewer cards has an increased chance for their cards to appear in any slot.
• Actions are much less likely to appear than Gambits, but they could potentially appear any time.

The result of this tuning is that if cards were picked entirely at random, the heroes would fairly split how many cards they each get to draft, and they'd each have a healthy division of Actions to Gambits. But, if the player really wanted to, they could create an absurdly off-kilter build -- and isn't that part of the fun of a roguelike?

By managing probabilities on the game side, I can spare the player much of the complexity, while still being able to tune the card spread behind the scenes. Anyone who wants to get super deep into the mechanics can still get a "feel" for how cards are rewarded, but the player's mental load is lowered significantly by only showing the information they need in the moment.

This system also dovetails easily into other event types -- I'm planning on having ones that let you specifically mulligan your Actions, and other ways to fine-tune your build.

[deathraydreams]

Great visuals. Fun solutions. I'll take anything to quench that Pox Nora fire
I'm rooting for you and the project! Do you plan on releasing a demo for playtesting?

[Tangleworm]

Great visuals. Fun solutions. I'll take anything to quench that Pox Nora fire
I'm rooting for you and the project! Do you plan on releasing a demo for playtesting?

Thank you! Yes, as soon as I have a playable vertical slice I'll set up something on Itch.

[Alain]

Nomia looks fun and seems to be getting along great! Keep up the good work!

[Tangleworm]

Nomia looks fun and seems to be getting along great! Keep up the good work!

Thank you so much!

This week has been mostly working on behind-the-scenes things. I got cards that swap positions working:

And I also reused the battle-log code for status logs that appear above units' heads, so now it's clearer when a ton of things happen at once:

I feel encouraged to start using more complex combinations of statuses in enemy design now that the information can be conveyed clearly. Sometimes style is required for substance.

[Tangleworm]

Now that I have AOE cards working, I have nothing I can use to put off making proper run-start and run-end menus.

[Alain]

Now that I have AOE cards working, I have nothing I can use to put off making proper run-start and run-end menus.

Menus sound less exciting than AOE cards, but what needs to be done, needs to be done