We start here where we left off in the previous devlog. We had a working paper prototype with a simple action-reaction loop. Now was the time to start implementing it.
At that point in development, we still worked within a classic turn-based scheme. You have a hand-drawn at the start, you play the cards on either you or the enemy, the stelas turn around until you feel you’re done or out of cards, you end the turn and the rest of your hand is discarded. Now the demon responds with three actions you just set up and your turn begins again. Also, at this time you couldn’t choose the stelas directly, it was automatically assumed to be the leftmost of the matching color.
No reaction from the monster when playing a card. And that critical hit; somehow it’s still in the game.
Change one thing, forced to change 10 other things
We quickly realized we can’t just repaint the wall from white to pink, leave the rest of the furniture unchanged and call it a day. The pink (well, red-and-blue, actually) forced full renovation. All classic solutions had to go away to be replaced by new ones that fit into the grinds of Deck Binding.
The biggest issue we faced at this stage was the lack of cards combos, something that you want in your card game, right? On this build, players were playing their cards more to position stelas in the best configuration for them, rather than use cards for whatever they had written on them. You could play more tactically of course, but randomly throwing cards around was similarly effective.
We were not as devastated as we had our paper prototype that proved to solve most if not all problems with the game! But in order to not completely break the mental health of our programmers, we decided to introduce the changes slowly, in phases. What sneaky little guys those designers are, right?
Steam Next Fest
The Steam Fest Next – a demo festival – was approaching, a great opportunity to test out some of the latest updates to the game. Phase 1 of our “reach the paper prototype stage” began. We added two small changes that really helped with the game:
- No automatic discard at the end of the player’s turn.
- Targeting the stelas instead of the monster.
Sounds like not much, but it really helped to flesh out the gameplay before we could move to what we thought are the more fundamental problems of the game.
Enemy playing all his “moves” one by one during his turn.
With no redraw after each turn, you could save some of the cards for later, and not spam them up, since you know you won't be seeing them for some time.
Stelas targeting improved the UX of the game, literally highlighting the main gameplay feature of Nadir.
The demo got some pretty positive feedback, players showed their interest in the game and they were curious about what we’ll do next. Remember the bigger issues we thought we were having? So it seems that nobody noticed them. So time for Phase two!
Code bending
Goal: you choose a card, play it on one of the stelas of the right color, apply the card’s effect, the monster reacts with the effect of the chosen stela, we get a new card? Simple, right?
That’s where you are the wrong boyo! What was very easy to prototype on paper required a complete overhaul of the turn system, you know, a pretty big system in a TURN-BASED card game.
But before the programmers started throwing stones at us, we decided that we can get rid of turns… by not getting rid of turns;)
The path of coding is a perilous one, but one that can be bent in multiple ways. In this case, we just made the turn very short. You played the card, bam, that’s your turn. Now it's the enemy's time to act, and voila – we have our paper prototype in a playable form!
Of course, it was not the end of our journey (yeah, it’s not that easy), but we will continue on the next devlog.
Hope you'll stay for longer 😎
Be sure to add Nadir to your wishlist!
https://store.steampowered.com/app/1535100
And if you have any questions or feedback: let us know on Discord!
