Post by Damian on Mar 3, 2015 12:31:44 GMT 10
We continue to iterate on the game mechanics surrounding reanimating undead minions and directing them in combat.
Previously the prototype only permitted a maximum of 2 undead minions for the player to command. This was due to keeping things simple for testing the initial game concept.
The latest build of the prototype (v0.0.0002) allows an infinite number of undead minions so long as the player has harvested enough souls. We really got a kick out of seeing 10+ zombies/skeletons tearing an enemy necromancer to pieces and obliterating his of handful of minions.
We always knew the most exciting feature about this type of game was the ability to command an army of the undead. Not just 1 or 2 zombies, but a 10-20 undead with a plethora of character classes.
While the play test was fun and engaging, it revealed some realities of many AI characters being involved in combat at one time.
We found it very difficult to identify our own friendly minions because the minions have similar silhouettes and appearances. e.g. The player's skeleton swordsman looks the same as an enemy skeleton swordsman.
This also meant that it was impossible to know how many archers, mages, swordsman, etc. that were currently in the player's army. During combat many minions suffer a final death, but there was no way to tell which minions belonged to the player or to the enemy.
It was not uncommon for combat to result in one skeleton left standing. It was also not uncommon to assume that the skeleton approaching you was a victorious friendly minion returning to your side having dispatched your enemies. It was only apparent that the skeleton was NOT your minion when he reached your side and then proceeded to hack at your with his sword.
Another issue is that some undead classes are faster than others. For example, mages cannot run as fast as swordsmen. This results in your army becoming spread out when travelling large distances and was a real pain when rallying your forces for an attack on a group of enemies.
We needed some way to know where all minions were at one time to get an idea of how long they would take to reach the player's position or where the player could go to effectively regroup.
This resulted in a few changes to the user interface to give the player more useful, real-time information about the state of their army:
HUD
[li]To give the player a better sense of the state of their undead army we added a vertical sack of icons underneath the Soul Meter that displays a list or portraits and the number of reanimated minions by undead class e.g. Archers, Swordsman, etc.[/li]
[li]Placing a green ring around the feet of friendly minions enables the player to quickly identify their own minions in the scene.[/li]
Maps
[li]Providing a map screen that shows icons for the player's current position and the location of the player's minions.[/li]
Much of the above seems obvious to read, but we have been very conscious of only adding user interface elements that we absolutely need. Every widget we add obscures a little bit more of the screen and can impede the player's view of what is actually happening in the game.
We'll continue to iterate on these mechanics and balance the UI for the optimal solution.
Previously the prototype only permitted a maximum of 2 undead minions for the player to command. This was due to keeping things simple for testing the initial game concept.
The latest build of the prototype (v0.0.0002) allows an infinite number of undead minions so long as the player has harvested enough souls. We really got a kick out of seeing 10+ zombies/skeletons tearing an enemy necromancer to pieces and obliterating his of handful of minions.
We always knew the most exciting feature about this type of game was the ability to command an army of the undead. Not just 1 or 2 zombies, but a 10-20 undead with a plethora of character classes.
While the play test was fun and engaging, it revealed some realities of many AI characters being involved in combat at one time.
We found it very difficult to identify our own friendly minions because the minions have similar silhouettes and appearances. e.g. The player's skeleton swordsman looks the same as an enemy skeleton swordsman.
This also meant that it was impossible to know how many archers, mages, swordsman, etc. that were currently in the player's army. During combat many minions suffer a final death, but there was no way to tell which minions belonged to the player or to the enemy.
It was not uncommon for combat to result in one skeleton left standing. It was also not uncommon to assume that the skeleton approaching you was a victorious friendly minion returning to your side having dispatched your enemies. It was only apparent that the skeleton was NOT your minion when he reached your side and then proceeded to hack at your with his sword.
Another issue is that some undead classes are faster than others. For example, mages cannot run as fast as swordsmen. This results in your army becoming spread out when travelling large distances and was a real pain when rallying your forces for an attack on a group of enemies.
We needed some way to know where all minions were at one time to get an idea of how long they would take to reach the player's position or where the player could go to effectively regroup.
This resulted in a few changes to the user interface to give the player more useful, real-time information about the state of their army:
HUD
[li]To give the player a better sense of the state of their undead army we added a vertical sack of icons underneath the Soul Meter that displays a list or portraits and the number of reanimated minions by undead class e.g. Archers, Swordsman, etc.[/li]
[li]Placing a green ring around the feet of friendly minions enables the player to quickly identify their own minions in the scene.[/li]
Maps
[li]Providing a map screen that shows icons for the player's current position and the location of the player's minions.[/li]
Much of the above seems obvious to read, but we have been very conscious of only adding user interface elements that we absolutely need. Every widget we add obscures a little bit more of the screen and can impede the player's view of what is actually happening in the game.
We'll continue to iterate on these mechanics and balance the UI for the optimal solution.