ALso, for the sixth(?) time in this thread: I'm not talking about an algorithm to automatically level-up enemies to match the player's level. I'm talking about an algorithm which will spawn enemies at whatever level the designer hand chooses. (This could also be used with a level-matching algorithm, I guess, but that's not required, let alone recommended in my article.)
Your article recommended "let[ting] enemy types spawn at differing experience levels" -- specifically, "us[ing] the
exact same level-up function I used for player characters to dynamically improve [enemies] on the fly" (your emphasis) -- in order to avoid "encounters which only pose an appropriate challenge during a very narrow window of the player characters’ development" or players' "running into battles they can’t possibly survive." A specific example of this technique you offer is "a battle filled with Bloodbeard’s Bandits at whatever the player’s level is." (I have no idea whether the current iteration of the article has eliminated or qualified these statements.) I know that you're saying in this thread that you aren't advocating what those quotations suggest, but your continued insistence that it's crazy that people read the article as advocating for it is silly. In fact, I don't really understand what "on the fly" could mean if not some kind of in-game (as opposed to predefined) scaling of enemies, nor do I see how your kind of predefined level scaling would solve the problem of encounters only working at certain levels or players facing battles they can't win.
Anyway, I think you're also misunderstanding
J1M's point, which is simply that
while it is true that combat involves more than enemy stats, having the enemy stats determined by a formula rather than hand-tailored is going to yield an inferior result, whether combinatorial or not.
I also think you haven't responded to the more fundamental point, which is whether it is actually labor saving to give each enemy "stat growth data" and "a skill progression" -- and then test and balance that equation at varying levels -- rather than instead manually defining what the enemy's stats are at a each level. In this sense, it is utterly irrelevant whether we call an enemy a Goblin (Lv. 4) or an Orc; you could just as easily provide each enemy type with a "name progression" or a "palette progression" or a "sprite progression" that is employed dynamically, and in fact you often see epithets and palette swaps used this way in rogue-like games. The question is simply whether, for Goblin (Lv. 1 to 5) it is (1) more efficient and (2) more effective to define the stats by creating and testing a formula or by creating and testing manually generated data. The additional question is whether you are better off in an RPG with hand-crafted encounters simply hand-crafting
each enemy, such that any particular instance of a Goblin in the game can have its own unique statistics (presumably starting with some basic norms).
I'm not sure why you'd rather stay hung up on whether people are reading your article correctly or not rather debating whether your method (whatever it is) actually serves the purpose you propose.
Incidentally, this isn't touched on in your article, but it seems to me that a decent argument in favor of Goblin (Lv. X) instead of Goblin (with the following unique stats) is that it makes it easier for the player to quickly grasp what's going on in a battle. Of course the exact same argument would favor Kobold, Goblin, Hobgoblin, Orc, Uruk-Hai instead Goblin (Lv. 1, 2, 3, 4, 5), so I'm not sure it ultimately is a winner.
