letting the player know how unique enemy skills work

[jonthefox]

When you make unique skills for bosses (actually, this issue probably applies to regular enemies too), do you work in a way to inform the player of how it exactly works? For example, say there's a warlock boss who has a special ability called "shadow blade" which does physical damage--but it scales off his MAT, and it is mitigated by the target's MDF (instead of DEF). So the player's best defensive options against him are to either 1) use a skill that lowers his MAT 2) use a skill that boosts your MDF 3) use a skill that increases your physical dmg reduction. But the question, how will the player know this?

Obviously, for some antagonists, especially ones that have very iconic/thematic type skills, you can leave breadcrumbs that point the player towards the correct mechanical understanding. But what if nearly all of your bosses have unique skills (which, i would imagine, a well designed game WOULD). Do you always look to provide ways for the player to know how enemy skills work, or sometimes do you just let the player figure it out based on trial and error?

 

[Rhaeami]

For me, I try to make the framework of the game itself point toward specific types of things to look out for. In my last game, enemies were largely defined by 1.) the damage their attacks inflict, 2.) what element they're weak to, and 3.) how they react when attacked. The first is clear when they hit you, the second is clear when you hit them, and the third is relayed through flavor text like "they countered your attack!" and whatnot.

Since the player doesn't *see* the enemy's stats, I never *use* the enemy's stats. It's simplistic, but suits my design tastes. As long as the player has access to all the puzzle pieces, it takes much less nudging to get them to put them together with the faintest of clues. For instance, if your game is full of enemies that attack with fairly consistent damage, then you meet one that gradually gets stronger over time... it becomes very clear without much explanation.

 

[sabao]

It would be ideal if players could identify enemy skills via visual cues in the form of the animation (Does it look physical? Magical? What element does it look like?) and the battle HUD text communicating its effects.

Xenogears uses some unusual attack types and it assists in communicating them through the battle HUD. In the linked video, you'll see the enemy Tolone use the Positron Beam skill and beside the skill name you'll see Wind Eth which is in-game shorthand saying the skill is magical in nature imbued with the wind affinity.

Unless your game type actually requires players to study enemy stats, bombarding them with numbers they may not completely understand feeds them information they may not actually need and puts unnecessary work on you as the developer. If absolutely necessary, however, you could provide players with a 'Scan' skill that can pull up the enemy unit's entire stat sheet.

 

[ShadowHawkDragon]

For me I'm considering on going with the option of having an NPC in which the player can purchase info on the current areas. This info would include basic descriptions/hint on how to deal with certain attacks/enemies. Unfortunately there is an issue with players being able to [save, buy, read, load]

Another alternative would be having 'data files' or pages of the 'book of foretelling' which can be found in dungeons.

Both solutions would give the option of learning how to beat monsters and bosses from in-game (no need for googling) but at some cost; whether it be money, the time to explore or the need to battle a 'guardian of info'.

Of course the biggest issue is making these pockets of info lore friendly and actually make sense for being in the game. Maybe a scout runs ahead of you to gather the info?

 

[Tai_MT]

The way I typically do it is by making the boss the "Test" and all the encounters with regular monsters up until the boss, the "Lessons". A "Lesson" isn't likely to kill you. Not unless you screw up pretty badly. Or, you're seriously under-prepared. Lessons teach you mechanics. Possibly even mechanics you can use against the Boss (Test!) at the end... or even ones that the Boss (Testtttt!!!!!) will likely use on a larger and more deadly scale.

Of course, my system has a slight drawback in that the player has to memorize what half a dozen armor types do in combat. But, that information is listed in almost every single armor shop, should a player forget. I prefer not holding their hands at all, but if I must, I'll do it someplace where they should at the very least write it down if their memory is crap.

In any case, I also use cues and sometimes patterns in attacks or troop compositions. A big enemy might charge an attack and it will say, "Winds up for a swing!" and that action will boost their ATK by 25% or something, and the player won't know when that enemy will swing, but they know it's coming. They can figure out when that swing will come when it lands, earning real life experience for the player.

The last thing I do is simply to drop some information on basic enemy times into the hands of experienced NPCs. The NPC's who live in the area and deal with Wolves their whole lives know how to deal with them. Usually. So, they might offer you some advice if you go looking to hunt the Alpha Dire Wolf. "Wolves are afraid of fire, use it if you feel backed into a corner!" spouted from the mouth of a local tavernkeep.

If the player isn't paying attention and they get wrecked by a boss, it's their fault. If the player could have had no way to obtain the information necessary to know how to deal with the boss... That's the fault of the dev.

 

[EseQueL]

Create an npc that gives you clue on what the boss' unique features are. For example your Shadow Blade...
Mariah will tell you something like... "That Warlock uses magic on his blade to deal physical damage."

 

[Wavelength]

For years I had been building skills like this for enemies, and recently I realized what poor design that was. There are so many walls between a player and his understanding of enemy damage mechanics - they probably don't know the formula, they can't see the boss' stats, they don't have an easy way to ascertain the damage type, etc.

This is part of why I recommend to most designers that they should use a single stat that influences damage dealt and a single stat (or even no stats) to influence damage taken. It's also why I'm going to recommend that you don't create skills like Shadow Blade for your enemies/bosses, unless you've somehow designed your game (it's feasible, I suppose) so that the kinds of steps you'd take to reduce physical damage are completely and qualitatively different from the steps you'd take to reduce magical damage - not just "use a DEF boost skill" vs. "use a MDF boost skill".

If the difference in the player's experience between having this Physical Attack that Scales on MAT enemy skill versus not having this enemy skill really is that great, then I recommend either telling the player outright when the boss uses the skill the first time (via Common Event) - or, if you have a lot of GUI built into your game, you may be able to color-code stuff to get the point across (e.g. the skill name is in Red, with a Blue background, when the enemy uses it).

If you can't honestly say that the difference in the player's experience will be big, then I strongly recommend simply making it a Physical Attack that Scales on ATK, or a Magical Attack that Scales on MAT. Or, better yet, get rid of damage types entirely, and make both "physical skills" and "magic skills" scale on ATK and DEF.

 

[Naridar]

Chrono Trigger (at least the DS version) uses the skill's pop-up box to tell its' special properties if it isn't obvious. (in your case, it would go like "Phys element attack using M.ATK/M.DEF"). Or if you have some scripting knowledge, you can customize damage display with element icons (I think Tales of Zestiria uses this) or colours based on whether the skill's physical or magical.

 

[Alarkus]

Visual cues can mean a lot. Even something as simple as small icons that appear by the boss that indicate what's happening.