This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Not respawning destroyed enemies


by on (#47152)
In this post, tepples wrote:
Celius wrote:
Nothing gets on my nerves more than enemies CONSTANTLY respawning (It makes me want to kill someone when some dumbass enemy keeps walking on screen even though I've killed it 1000 times =).)

I'm pretty sure that has something to do with lack of memory to keep track of which items have been destroyed. SMB3 doesn't have this problem, but then it has 8 KB PRG RAM.

Respawning gets on my nerves too. Sometimes you just wanna kill some enemies to make room for a big jump or something, but because you went back for impulse, when the screen scrolls back there are the fuckers again, and you can't do what you planned.

Reserving 1 bit for each enemy in the level isn't so hard on RAM. With just 32 bytes you can remember if each of 256 enemies has been killed or not. RAM shouldn't be an excuse. I believe it's more of a programmer laziness problem, as it's simply easier to not do anything about it.

by on (#47155)
tokumaru wrote:
Reserving 1 bit for each enemy in the level isn't so hard on RAM. With just 32 bytes you can remember if each of 256 enemies has been killed or not.

For this to happen, your code that spawns the enemies has to know the offset of the enemy in the array. It would work well if each level has an array-list of enemies, where each element represents one enemy. Games already have to keep track of this to make sure that an enemy that's still on screen isn't respawned.

It might be more difficult if your engine spawns entire formations of enemies, as I seem to remember Super Mario Bros. doing for double and triple Goombas. (Citation: DahrkDaiz's level format doc) I would imagine that objects representing formations of coins, rings, golden arches, or whatever would have the same problem.

by on (#47156)
I think it really depends on the type of game and design decision. For example, Ninja gaiden 1 and 2 have this "issue" but not #3. #3 doesn't have any extra ram.

by on (#47164)
tepples wrote:
It might be more difficult if your engine spawns entire formations of enemies, as I seem to remember Super Mario Bros. doing for double and triple Goombas. (Citation: DahrkDaiz's level format doc) I would imagine that objects representing formations of coins, rings, golden arches, or whatever would have the same problem.

In my current game, each level can have up to 256 objects, and there is a bit for each one (for a total of 32 bytes). Should special objects need more than a bit (which is the case with formations), there are 128 bytes of RAM available to them, and the "parameter byte" in their definitions (my object definitions have 4 elements: X coord, Y coord, type and parameter, which is used differently for each type) is a pointer to which part of this memory it uses (they can use as many bytes as they want, as long as it all fits in). It's the best I could do without extra RAM.

The ideal thing would probably be keeping the object definitions themselves in RAM, so that you could modify whatever you wanted about the objects, even their positions (although this might require some sorting if the object-loading code expects a sorted list). This is only possible with extra RAM though, as object definitions can take up a lot of space.

I don't know if 256 objects is a good limit for levels as big as I want, I hope it'll be enough. This limitation is not RAM-related, as it would be easy to get, say, 32 more bytes for object bits, it's more related to ROM (I don't have much for definitions) and the code that loads objects (which is easier to code and runs faster if objects can be indexed by a single byte). Although now that I think of it, it should be easy to trigger an event in the middle of the level to switch to another table of object definitions, if I really needed more than 256.

BTW, why split from my post? You and Celius mentioned respawning before I did. Not that I'm complaining, I'm just curious.

by on (#47175)
tokumaru wrote:
BTW, why split from my post? You and Celius mentioned respawning before I did.

I can only split whole posts from a topic. I can't split part of a post. So I split starting at the first post that only mentioned respawning.

But your idea of an "auxiliary object ID" for formations has merit.

by on (#47180)
In the other topic, I posted without realizing this topic existed. I wrote:

------
Even if you go back to an area and the enemies are alive, it's better than an enemy infinitely respawning and walking on screen. That sort of glitch is avoidable. I say enemies can spawn as soon as they come half a screen beyond the edge of the screen. Then they should remain "inactive" until they are at the edge of the screen. That way, the player will have to walk almost 128 pixels in that direction in order for it to start doing anything, so that by the time you kill it, you are probably past the point at which it would respawn. Though that's just a quick improvement (not a fix).

I will probably take the time to make sure this problem does not occur in my game. All it takes is one bit for each object. Though this could take up a lot of RAM if you have a ton of objects.

-----

And I am probably going to have a limit like tokumaru of 256 objects per level, which is more acceptable for me as I have 20ish screen-long levels that are 1 screen tall. But that will make up for my graphical limitations.

by on (#48070)
tepples wrote:

It might be more difficult if your engine spawns entire formations of enemies, as I seem to remember Super Mario Bros. doing for double and triple Goombas. (Citation: DahrkDaiz's level format doc) I would imagine that objects representing formations of coins, rings, golden arches, or whatever would have the same problem.


But for Super Mario Bros. it can't really respawn, as the screen scrolls only in one direction. So the SMB engine might just keep track on which onscreen and next screen formations have spawned and overwrites the rest as needed.

SMB3 keeps track of a 'room' or level section, and resets any collected items / defeated enemy data, does not apply to bonus rooms tough (but if I'm not mistaken, there are only a small amount allocated per level anyway).