[2.6] Nth Enemy has the X

[CJC]

Okay, this is a pseudo-compatibility, pseudo-quest rule, pseudo init-data request that would span several of ZQuest's menus, so I'm pitching it for version 2.6 as it would likely take some time to set up.


In the NES version of the game, defeating ten enemies without taking damage would guarantee the 10th enemy would drop a bomb. I propose that--rather than just making a quest rule toggle for authenticity/compatibility, we turn it into a legitimate quest feature.


So here's the suggestion

Under Init data, add a checkbox "Nth Enemy has the X" with a grayed-out number box next to it. Checking the "Nth" makes the box editable, which can take any number from 1 to 255.

With a number assigned, the quest now runs a built-in script to count enemy kills, which resets whenever Link takes damage or he kills the set number of enemies. In addition, each Item Dropset gets a new pull-down, labeled "Nth Enemy". When Link successfully kills the number of enemies specified in the init data, the probability of the "Nth Enemy" item drop and the probability of the Item Dropset drop rate are both temporarily raised to 100%. Thus, the enemy drops the guaranteed item from its assigned dropset (which may or may not be bombs, depending on what the questmaker decides).

[Nightmare]

It really needs to be a quest rule, the only quests that use this rule really are the traditional Zelda quests.

-James

[CJC]

It really needs to be a quest rule, the only quests that use this rule really are the traditional Zelda quests.

-James

A quest rule would only fix the authenticity of 1st and 2nd Quest. I'm talking about a new editor feature, one with flexibility.

Maybe I'm building a quest where I want a 50 rupee piece to drop when you beat 30 enemies without taking damage, or maybe I want to build a quest where a Piece of Power drops after beating 5 enemies without damage. Perhaps I have a dungeon where you must defeat 3 Gibdos in a row without taking damage to collect a key, preceding the magic key.
A quest rule is only a toggle and would only work with bombs; it's not extensive enough to be a viable addition to the editor.

[Saffith]

It's not really always a bomb. I think it varies depending on the enemy, but I see blue rupees a lot more often.
But, yes, it's something we should add.

[Nightmare]

It's not really always a bomb. I think it varies depending on the enemy, but I see blue rupees a lot more often.
But, yes, it's something we should add.

Just make it optional: This leads to some very broken speedruns among other things: I'd hate to see something like New Quest broken by this bullshit.

I don't think this is exactly a good thing for Zelda Classic to implement outside of the Nth Quests.

-James

[Gleeok]

Easiest way (without breaking anything) might be to have a conditional in the drop-set editor. Of course this also opens up even more cans of worms when you realize the engine now needs to track every type of condition, such as "kill counter for enemy type or id 'X'" and "successive no damage kills" et al.

[edit] Actually, I don't really like this idea very much. ...Maybe something a little simpler.

Also this sounds like a good forum game thread. :P

[CJC]

Easiest way (without breaking anything) might be to have a conditional in the drop-set editor. Of course this also opens up even more cans of worms when you realize the engine now needs to track every type of condition, such as "kill counter for enemy type or id 'X'" and "successive no damage kills" et al.

Actually that could work.

Picture this: A number box in the Enemy Drop Set that says "Guaranteed Drop Kill Count". When an enemy with that drop set is defeated, the built-in script checks if that number of enemies has been defeated. If yes, it resets the counter and drops the first item in the Item Drop Set. 0 would be the sentinel value, ignoring the feature for that drop set. It would also be the default value, meaning unless people change it the Nth enemy feature would not apply.

Some Pseudocode


if(KILL_COUNT == 0)
{
Link->PerfectKills -=1; //Prevents IDS that doesn't use the Nth enemy from incrementing
//PerfectKills, such as bushes or flowers
Break;
}
else if(Link->PerfectKills >= KILL_COUNT)
{
IDS_DropRateBox = IDS->DropRate; //Stores the original drop rate
IDS->DropRate = 100; //Sets the drop rate to 100%
IDS_FirstSlotBox = IDS_DropRate[0] //Stores the drop rate of the first item in the IDS
IDS_DropRate[0] = 100; //Sets the drop rate to 100%
Link->PerfectKills = 0; //Clears the perfect-kill count
Waitframe();
IDS->DropRate = IDS_DropRateBox; //Resets the drop-rate to normal
IDS_DropRate[0] = IDS_FirstSlotBox; //Resets the drop-rate to normal
}

You increment Link->PerfectKills on any frame in which the ItemDropSet is checked for drop rates, as that indicates an enemy has been killed. You reset Link->PerfectKills on any frame where his health is less than the previous frame. The 0 sentinel value being default ensures that the feature is only ever used in quests where the creator intends for it to exist.


EDIT: It might be slightly more practical to use -1 as a sentinel value, so you can have '0' perfectKill enemies that penalize the player by resetting the counter and dropping nothing.

[Zim]

The Perfect Kill counter would apply to the screen-> something and probably not a Link pointer the way this is described.

There"s also slight redundancy in the code.

Another thing would be an on-screen still check and reset and/or store in case Link leaves the screen.. Otherwise he'd be able to meet the counter quota by defeating the amount on more than one screen...
Then we'd have to take into account the fact that some screens enemies come back or not, and whether the counter resets even if link does not get hurt and the enemies respawn to max amount.. etc. All doable though.





Seems the only way to do this practically would be a screen data array for both things, an all enemies no hit goal number

[CJC]

There"s also slight redundancy in the code.
Do you mean the two different drop rates? I was trying to account for the double percentages in an item drop set; the first is the dropset's probability of dropping something, and the second is the probability that--if something is dropped--it will be the first item in the set. Combined, they guarantee that the enemy drops an item and that the item is the intended item.


Another thing would be an on-screen still check and reset and/or store in case Link leaves the screen.. Otherwise he'd be able to meet the counter quota by defeating the amount on more than one screen...
Ah, I misunderstood the mechanic. Blame my faulty cartridge of Zelda 1, most of my Z1 experience is from Zelda Classic; I wrongly believed that it was ANY 10 enemies, not 10 enemies on a single screen. So I used a Link pointer because I figured it rolled over from screen to screen.

[Imzogelmo]

It is any 10 enemies (excepting ones that can never drop items anyway). Original Zelda 1 had an 8-enemy limit on a given screen.

[Zim]

I confused the context because of the screen drop box reference, my mistake.

Another way to do this is to createitemat NPC xy when the counter reaches full.

Item remove for no double drops, so no double item drops, and a enemy of list to activate the counter. This way the drop rates wouldn't need modded.