The title to this post is one part joke and one part reality. As it stands, The Regret of Vitrerran is early in development and so any changes made right now aren’t and cannot be last minute. We haven’t even Kickstarted this yet! However, we did—or rather, Joe did—employ a very substantial change that has pushed our Kicktarter plans back a bit.
Of course, there’s nothing wrong with that. In fact, the last two and a half weeks have been absolutely correct.
The Regret of Vitrerran is now a different game with different gameplay.
See, here’s the fun thing about being part of a small team: there’s no one to say “no” to changes or new ideas. Most changes are small, as the gist of the project is fairly set in stone, and if they don’t pan out, all that’s needed is to reload an older file.
There’s no real formal method to how we are approaching game development, so as it stands, all ideas are at least worth talking about. Some are worth trying. Most have been worth implementing.
So about two and a half weeks ago Joe came up to me and said something along the lines of, “Hey, we have a real-time card game that doesn’t really feel like a real-time card game due to balance delays. I want to fix that, but that means changing a lot of it.”
I was concerned. This wasn’t a small change. “How long will this take?” I asked.
“I can have a mockup done before the weekend is out. Take about six hours.”
I will forever stand by the fact that our original gameplay designs were fun, even if they were perhaps a bit strange and quite hard to explain. We had a three by three grid where attack and defense cards were placed, the goal to break through a defense to unleash an attack. However, the game didn’t quite play the way either of us expected.
Let’s look at fires. You have an area and I have an area, and both of us have the means to throw fire and the means to put the fires out. I throw my fire at you, and you douse it in water. You do the same to me and I douse the flame. The emphasis here isn’t on setting fires but putting them out. I throw more fires; you hope to have more water on hand to put them out. We are trying to burn each other to the ground yes, but too much emphasis seems to be placed on the water.
Our first model was too defense focused. Too chaotic. We want to make a card game, and card games play host to strategy, yet our old version didn’t require all that much strategy. Having forethought was better than not having it, but I found it just as useful to throw attack cards randomly and only bother with precision when it came to defense.
And really, attacking just didn’t have the force or fun it should have had. Setting fires is more fun than putting them out. When you attack in a game, you want immediate feedback. You want a noise and an action. You want fire. In our first version, you were met with a delay as the attack card prepared to work. The opponent had to have the chance to defend, otherwise defense cards weren’t useful.
Every action was delayed, which was interesting, fun in its own right, but not right.
Joe wanted to remove the delays to create immediate feedback. “I don’t know why we never bothered with this before” he said, and I don’t either.
What he wanted to do was create two grids, one for attacking and one for defending. That posed its own problems, but a “what if the defense cards stack so you can keep refreshing them?” fixed the biggest one.
My main concern was actually one of uniqueness, which is both foolish and petulant now that I think about it. I have seen other games with attack and defense parameters before, and I liked that ours contained them in one place. I liked that we were making a game quite different from others, and this felt like a step backwards.
Joe was adamant and I was curious, and so he retooled our gameplay to what it now is and what it will now stay (unless a better idea strikes, but I’d rather not dwell on that). I think it took a bit longer than he had wanted it to, but he did have it done before that weekend was out.
And, sad story, it didn’t work. The emphasis was now on attack, but strategy had fled the field. See, even though there were nine places to attack and nine places to defend, it really didn’t matter: attacking in one spot over and over proved the only strategy worth employing.
“Well, I programmed this in a much more efficient way, so it isn’t completely lost” Joe said, and we both frowned and wondered what to do.
The answer turned out to be delays. This bothered me for actual gameplay reasons: we are making a real-time card game, and too many delays might make it feel like a turn-based game. Too many delays might make the player feel too controlled, and that’s not fun.
We threw out some more ideas, including a rather stupid one where defense cards ticked up and down—stupid for two reasons: One; it wouldn’t fix the problem and Two; it put unneeded emphasis on defending again (though expect to find magical defense cards that start quite high and tick downwards (stupid ideas have their uses))—and decided to sleep on the idea before scraping it.
I was offput by the delays, but Joe implemented them anyways. I didn’t have any better ideas, and neither of us wanted to throw away that many hours of work. The worry became one of instant gratification: “We can’t force this to work simply because we put immediate time into it when we put a lot more time into the old way.”
But our story has a happy ending, or at least this story has a happy ending. The delays work. They don’t feel too forceful, and they don’t create a turn-based affair. In fact, they make sense. If you’re attacked and hit in a specific spot, you’re bound to put a short-term emphasis on defending that spot so it isn’t hit again. That’s what these delays do.
And actually, they managed to solve all of the little problems with our old gameplay method.
The big gameplay emphasis is now on attacking while keeping up a solid defense. Defense is crucial, but the whole point is to get in solid attacks to win, not to defend the best while hoping for the best. It feels better to play; it feels like the player has more control.
The game now feels more strategic. There’s still some randomness to it, but I wouldn’t recommend being chaotic with your card placements if you want to win. Brute force really won’t work now.
We got to remove parry, which was a needed fix in our old method. If two attack cards were placed in the same spot at the same time, only one would take and that ruined the feel and flow of battle. Parry deleted both cards so it at least felt like you did something, and while the stat was actually quite fun and we wanted to plan utility cards around it, it’s better that it’s gone. We hope to replace that stat at some point since the more we have, the better.
The game is just more fun to play, and it’s more fun to play for longer periods of time. My one real worry with our old method was keeping things fresh for eight full single-player campaigns. That worry no longer exists. We’re now talking about creating bosses that extend or decrease the battle grids to make things even more hectic. Three by three can feel overwhelming at times, so surely a four by four would be even more intense.
The entire battlefield is now symmetrical, and humans just generally prefer symmetry. We got to remove the discard area as well.
A few misplaced weeks and the game is better than it ever has been, and now things are back on track for our Kickstarter attempt. Joe is working on more art and more magic to show off in a trailer, and I’m back to learning the mysteries behind FL Studio so I can create sound effects.
My hopes are high because I’m confident this game is going to be good when it’s done.
~Chad