I believe making my own RPG game was an opportunity to re-examine established tropes in role-playing games: what works, and what were workarounds that don't apply anymore.
Action Points And Punishment
Earlier I mentioned I wanted the idea of incorporating ideas from fighting games. This included punishing players who spam attacks, in the sense that they'll die if they don't think through their method of attacks. In fighting games, this is achieved by having a long recovery time from attack animation, back to idle animation. While in this transition, the player cannot do anything and is vulnerable.
Dark Souls also incorporates this idea into their combat. Likewise, just spamming the attack button in that game will leave you vulnerable.
So, this is my idea: Any action a unit performs consumes stamina. Stamina naturally refills over time. In the point of view of this turn-based system, stamina refills a little at the beginning of the player’s turn. If a unit runs out of stamina, he undergoes a negative status effect, some sort of “Tired” status; a sort of debuff that makes the unit vulnerable. Until the unit recovers a substantial portion of his stamina, he will stay in that debuff status.
Any action done consumes stamina: even normal attacks, even moving. Only the “stand idle” action will not consume stamina.
This means moving is risky and should only be done when needed.
Either way, this stamina mechanic is simply very similar to action points, in games like XCOM.
Games With Gridless Maps
When I was still working for Red Pumpkin Design Studios, my boss wanted to make a Final Fantasy Tactics style of game.
It came to a point where they were deciding between a square or hex grid for the map.
I immediately suggested a gridless system where units move like in an RTS. They didn’t like the idea at the time though.
That suggestion of mine came from me playing this old 1997 game called Return to Krondor. An RPG game where they don’t make use of a grid for movement.
Recent videogames that do this include the soon to release indie game Skulls of the Shogun, the 2007 portable console game Warhammer 40,000: Squad Command, and the console game, Phantom Brave, first released on the PS2 on 2004.
So across indie and AAA, East and West, Console and PC, if done properly, the idea of gridless movement has been proven to work.
Gridless Map In Practice
So, for the movement, this was my first experiment:
I was forced to remove the coloring of the border, because it took too long to display. Mainly, the generation of meshes in Unity during runtime is slow. It’s also being done on the main thread so it blocks execution, and that causes hiccups in the framerate.
In the end it looks similar to in Phantom Brave:
But you’ll notice the border is not a perfect circle. It takes obstacles into account.
Furthermore, you’ll see he can move about 40 meters here:
...But only about 20 meters here:
This is because that part is actually a hill, while the other part is relatively flat:
So, yes. Height elevation is taken into account. The reason is it takes a lot harder for troops to trudge through elevated terrain, so it costs more stamina.
In game terms, elevated terrain confers advantages in combat, which is why I, as designer, forcefully make it hard for troops to get there.
The simple fact of making it hard to get there gives advantage by itself. Ranged units would be wise to position themselves on high ground, as melee enemies will take longer to get to where they are (since its slower to get to higher terrain). This offers the ranged unit perhaps enough scant time to finish off those enclosing melee opponents.
Skill Interface
Here's a mock-up of the GUI so far:
You may be wondering what's going on over on that bottom-right box:
Short explanation: Its kinda like this:
But why the hell all that buttons, huh?
Here’s how it went that way: I’ve been discussing with my accomplice, Ragosta Tin Dei, how I could encourage the player to experiment. And what I had thought is to lessen the repercussions of mistakes that the player makes. I talked about it in detail here.
The traditional level-up style of improvement is a permanent change for a character, so careful thought must be applied before committing to whatever points should be allocated. An inferior character build will leave the player with having to restart his game, at worst.
That is exactly what I want to prevent. My hunch is, so did Blizzard when they made Diablo 3, and so did Bethesda when they made Skyrim.
The movement away from the traditional stats and skill trees is something to be watchful of. My hunch is you’ll see more of it in new games.
I understand the exploration of character builds is part of the fun for people. Some people don’t mind throwing away hours, maybe days worth of playing when realizing they made a weak character build. I can’t say the same for everyone.
So, with that in mind, I proposed several ideas. The one that I liked the most, is one that Final Fantasy Tactics did (and lately, what I saw Diablo 3 did): swappable skills. Each unit can equip/unequip skills as if they were items. As for Final Fantasy Tactics, they were skill sets. It makes for some rather strange combinations, where you could have a healer that charges in battle, for example.
One of my concerns for this was that it doesn’t make sense in the narrative that you “equip” skills. Does the character equivalently memorize/forget the skills in the story when you equip/unequip skills?
Turns out, players don’t care much, as I saw with Diablo 3 and Final Fantasy Tactics.
So back to this:
So what are those? Each icon you see there is one skill. And like I’ve discussed, you can choose which skill to equip to each unit. You equip them in that grid. That’s a 7×3 grid, allowing you to equip up to 21 skills.
Why so many? That’s where you equip passive skills too. So you have to be mindful of that tradeoff. Passive skills are nice, but they take up space where you would normally put activated skills, too.
Another reason is that some skills take up more than one square. Some skills take up 3, 4, perhaps 5 squares, so the high number of slots is to ensure the player has enough space to juggle placement of skills. Take note its not required to fill every space.
Other than the icons being clickable, each skill is also assigned a hotkey mapped to the QWERTY keyboard for easy access. Other keyboard layouts can be considered.
Polyomino System
Skills have upgrades, and every upgrade adds one square to it. Again, you have to choose. Do you want your unit’s skills to have many upgrades? In exchange, he can put only a fewer amount of skills, since each skill now takes up a lot of squares.
Its basically a Tetris-esque mini-game, or technically, more appropriately called, a polyomino system.
Similar games that do this is the Nintendo DS game, Avalon Code, and the recent 3DS game, Kid Icarus: Uprising.
Unfortunately, its a little way away until I get to implement this since this essentially replaces a level-up system, and levelling up units is out of scope for this small project. But certainly the game will have this later on, and I'm building the system in such a way that I'm reserving space for it to fit into.
The Time-keeping System
Initially I went with the idea of simultaneous turn-based (“we go”, as opposed to “I go, then you go”), where units of both players move at the same time. Both players plan their moves, then comes a resolution phase where planned actions of both your units and enemy units are performed at the same time.
As time went by, I moved on to planning other things in the game, like the fact that the game I’m using this system for is combat between squads: 12 units at most on each side. I realized things will become too chaotic with this set up.
Why 12? Its part of the story. The game takes place during a war, and there are occasional times when you control a 12-man squad.
Simultaneous turn-based may work fine for combat between groups composed of 1-3 people, but at 12 which I wanted, it may become more stress than excitement for the player at that point.
Simultaneous turn-based also has a problem if done wrong: say for example you want your troops to move near the enemy. You’re basing your decision based on where the enemy is now, but remember the opponent may choose to move his troops. By the time your troops get there, his troops may be somewhere else.
You may find yourself in a situation where you are chasing after the enemy who keeps on moving away from you, because output is delayed from player input (i.e. planning phase and resolution phase). Your opponent may even feel the same frustration!
I had several ideas to address this. You could have a follow command in addition to the usual move command. You could shorten the duration of the resolution phase (though duration of attack animations have to be addressed). You could shrink the map where the fight takes place.
And yet with all the things I could think of, I still couldn’t address the 12-man issue. With 12 versus 12, localized fights could occur. What I mean is, at worst, it could simply end up having 12 duels happening at the same time (1 unit of each side fighting each other).
And in that situation, I believe it will be hard for the player to keep track of things going on in the resolution phase. Imagine you have to dart your eyes between 12 fights occurring at the same time! Even worse, duelling participants may switch “partners” in the midst of battle, as the need arises. That may cause further difficulty in keeping track of things.
Of course that situation wouldn’t happen all the time, but even, say, having the fight separate into two fights, I believe, can get hard to keep track of.
But as you could note, this is all conjecture from me. Could there be a sweet spot somewhere? Who knows.
Frozen Synapse does a wonderful job in this area. All the problems I mentioned actually make for some pretty exciting fights in Frozen Synapse. Part of the fun there is anticipating your enemy’s actions.
However I found out early on that units in that game attack automatically as long as an enemy is in their range (a pie shape, as in their field of vision). The developers could afford to implement things that way since all units are ranged attackers.
In my game however, there are melee units. You could think of Frozen Synapse as a tactical tower vs tower game. If towers could move.
Dueling Blades, an upcoming Facebook game by developers in the Unity game engine community, is also simultaneous turn-based. And might I say its rather genius to utilize simultaneous turn-based for a Facebook game cause its a perfect fit. Simultaneous turn-based still counts as an asynchronous (i.e. non real-time) game, and those types of games work well in the Facebook environment.
Their set up, as you could guess, is to make it duels only. One unit versus one other unit, no more than that (so far). So much of my problems don’t apply to them.
Right now, I’m content with resorting back to a traditional turn-based system. I’ve had tons of fun playing Fallout 2, so I know a turn-based system can still be fun if done right.
So that's it for now. In the next post, I'll explain what I have so far for melee combat.
Looks awesome keep goin :D