2012 24 Oct

Combat System #3: Group enemies

Categories: Game Design

In an earlier post (Combat System #1, Sep 03) that discussed the combat system, we admitted that we originally aimed for making a turn-based game. However, we also mentioned that other variants (esp. the RtwP combat of Dragon Age) were worth discussing and we spent some time doing so. We are grown-ups that make games in an industry that still mostly focuses on kids as customers. Most of us were still teenagers when turn-based RPGs vanished and made place for the new era of realtime. And even if the pros and cons sometimes come down to personal taste, we think that no one would argue one point: turn-based games tend to be less “action-packed”. It can grow annoying (especially in a less tight combat) to wait until all those goblins, kobolds, what-so-ever-minions have finally made their turn. Especially watching enemies moving is kinda boring and that’s why some TB games have sped up movement (e.g. animations) to the brink of sheer ugliness.

Players are eager to see their characters’ turns and they are also excited to see whether the enemy boss will kill their tank in his next turn. And while we all enjoy wiping out 20 goblins with a fireball, no one wants to see them all move and attack one after the other. In fact, some of us got often tempted to reload and see whether their wizard has a higher initiative this time to get rid of those little annoyances in the beginning of the combat.

ToEE tried to tackle this problem with a menu option that, once activated, would allow enemies within the same initiative group to move simultaneously. That turned out to create cool packs of hobbling and wobbling goblins but (as mentioned above) was not always beneficial: In a fight with a small number of semi-bosses that happened to be in the same initiative group (say, a giant, a werewolf and a demon) we would not only want to anticipate their attacks separatly but it also does look kinda unepic when these individuals make their moves together.

So we wanted to take care of the boring minions on the one hand without randomly grouping more epic enemies on the other. We straightfowardly decided to let our level designers choose which enemies should be grouped and which shouldn’t. The ‘minion mobs’ were born and we found them to provide additional advantages:

Rather than rolling the gobs initiative individually¬†and grouping them up accordingly, we group them up beforehand and roll their initiative only once. This implies that a group of minions can not be ‘spread out’ over the initiative list and act individually¬†(a case that the ToEE approach didn’t prevent). Also, we are going to try and give them some additional ‘identity’ exceeding the simple fact that they act simultaneously, by also tweaking their AI to stay together and attack the same target whenever possible. We think that might add to the strategic depth of our combat (and even if it won’t, it will still be more atmospheric). As an additional consequence, the player will be able to predict the a mob’s behavior to some extent. As far as we’ve implemented this (grouping and movement already looks good, but AI is still very basic) our idea feels great and we hope we’re well on the way to make turn-based combat a little more appealing regarding the pace.

We hope you enjoy our super-size-goblin-minion-mobs screenshot (more will follow soon) and we are, as always, looking forward to your comments!

 

 


Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 71 bytes) in /var/www/mpress/public/wp-includes/comment-template.php on line 896