So, I'm finding myself shocked and bamboozled by how darn few sprite palettes you can have at once. It's just four! It's not like I didn't know that beforehand, but now that I'm actually coding up my project I'm struck by how little four actually turns out to be.
I'm making a co-op kinda thing, so I'm using one palette for player one, one palette for player two, and now I'm left with two palettes for all the enemies and objects they encounter. Furthermore, I usually want black outlines on my enemies which means enemies can have a grand total of two sets of two different colors.
But old retro games should be colorful and alive! So, I've been brainstorming about strategies and tricks to help maximize the color liveliness of the game. I figured I'd write down my thoughts here, and see if there are any other clever ideas I'm missing out on.
Palette Reuse
The obvious first thing to think about is to try to reuse as many palettes as possible. By making enemies that have the same color scheme as player one and two, we suddenly got four different colored enemies instead of two. But, that runs into a wall if you are planning on changing the palettes, for instance like when Mario gets a fire flower and switches to a new yellow and white palette. Unless you are willing to have enemies also magically change colors out of the blue along with Mario then reusing palettes is difficult.
But in certain cases palette reuse can be pretty safe, Mario's fireballs uses the same colors as Fire Mario. When ice Kirby freezes enemies into blocks of ice they use the same blue colors as Kirby's blue form. If either of them loses their special power (this changing their palette) then the projectiles/ice blocks can simply be deleted on the same frame and most players wouldn't mind.
Also, when reusing a palette between two different sprites you can switch around which color you are mostly emphasizing, thus giving the sprites a very different "feel" despite using the same palette.
Changing the palettes actively
Some games (like the Mario games) sets the palettes per level, so that when you enter a level the palettes are loaded and stays there. Enemies simply use those palettes whether they fit or not, so the level design has to be done carefully so there are no terrible clashes of sprites and palettes that look bad together. The easiest example of this level palette design are the Goombas who turn grey in underground levels.
But it's entirely possible to change the palettes on-the-fly inside of a level depending on what enemies appear. Doing so offers a number of pitfalls though, what to do if all four palettes are already in use when a new kind of enemy appears? Simply delete it?
This is the strategy I'm going for in my project. To avoid some of the pitfalls, I'm also giving each enemy a list of alternative color schemes, so that if all palettes are currently occupied they can in a pinch appear reusing one of the other already existing palettes looking only slightly different.
Mid-screen palette changes
Probably not, based on the various topics about it here on the forum it doesn't seem viable for anything except a split-screen game with a big black bar in the middle.
What I normally do is use 2 or 3 palettes (depending on how colorful the protagonist is) for constant objects, such as the protagonist, items, explosions and other effects, and 1 or 2 palettes that can be dynamically changed by the level. Enemies and level objects can use the constant palettes, that usually contain useful colors such as gray and orange, but the custom ones will usually fit the theme of the level better.
There's also software blitting to modify background tiles around the player to add white and black to the other three colors, but that's very slow. You'd need to reserve Black and White in your background palettes as well, leaving two remaining colors in each background palette.
Or even sprite overlays, if you need to add a small black and white object (8px wide) to another object. Mario 2 does that.
Even SMB1 changes palettes mid-room sometimes. Aside from the obvious case where the Mario / Luigi / Fire state changes, it also loads a new palette for Bowzer, and possibly other cases. Not being able to scroll back and forth is probably a big help here.
The other thing that's important in SMB2/3 is how levels are frequently divided up into smaller rooms. Very useful for keeping the enemy combinations contained.
I ran into terrible palette problems making the Jammin Honey game. Not just palettes, but 8 sprite limit problems. Honey always takes up 4 sprites wide, due to overlapping guitar sprites...and uses up 2 full palettes. that means that I can only have 2 enemies on the same scanline before flicker madness. If there is a coin or star, only 1 enemy can be on the same scanline.
so 2 palettes are reserved for honey, 1 for coins and stars, left me only 1 palette to use for most enemies. I had to reuse as much as possible (bees use coin yellow, chicken uses coin brown, fire uses coin yellow)
The white in the chicken's eye is just BG white. noticeable only when she walks over a ladder.
it's tough. it would have been easier if I used only 1 palette for the hero. or if I had restricted each room to only have 1 type of enemy, I could have been more colorful with each enemy.
it was a trade off. I ordered mixed enemies per room to more colorful enemies.
EDIT, correction, I made coins smaller, so I think you can have 3 coins on the same scanline as honey, without sprite flickering.
One thing i've found a bit useful so far is reserving only one extra colour in another subpalette for sprite overlays on a main character or the like. So, let's say there's black outline and two shades for armour in the basic sprite, and one colour for skin in the overlay. What it means is the "skintone" (or whatever it is you're overlaying) will have one context on the player character, and a wholly other when used together with the two free colours in the same palette on some other metasprite object.
It's very circumstantial advice and ymmv.
FrankenGraphics wrote:
One thing i've found a bit useful so far is reserving only one extra colour in another subpalette for sprite overlays on a main character or the like. So, let's say there's black outline and two shades for armour in the basic sprite, and one colour for skin in the overlay. What it means is the "skintone" (or whatever it is you're overlaying) will have one context on the player character, and a wholly other when used together with the two free colours in the same palette on some other metasprite object.
It's very circumstantial advice and ymmv.
That's neat. With things that only use 1 or 2 colors (like a bullet) you could extend this trick quite a lot.
It is at least lucky to have 4 sprite palettes on the Famicom. IMO the more restricting factor is its 2bpp graphics, giving each sprite only 3 (+1 transparent) colours, making you use more than one palettes in an object (like sprite overlaying in Rockman and SMB2US or using different palettes in different portions like in Contra; I think the Double Dragon games use both) if you want it to be more colourful. There are many clever ways in arranging these palettes though, as mentioned by people here.
You're not so lucky if you developed for the Sega systems BiTD though. The SMS has only one single palette for sprites, and no sprite flipping feature too, forcing you to use different sprites for even just palette swapped objects and characters facing different directions. You could use dynamic sprites by constantly changing the sprite table but that eats CPU time in uploading the graphics to video memory. The Mega Drive isn't terribly better either as it has only 4 palettes combined for both sprites and backgrounds (which IMO is worse than the Famicom). The sprites on these systems are 4bpp though so in general stuff should still look better, and I think mid-screen palette changes are relatively easier too.
Another interesting trick is that you can cycle palettes on certain items, projectiles, effects or anything that shines/flashes/glows, and it won't look like they're reusing palettes from other objects. SMB1 does this a lot, but the effect looks cooler in Batman Return of the Joker. As long as the palettes have their colors sorted by brightness, the exact colors used may not even matter much.
In my view, dealing with the palette limitations on the NES is the one thing that most makes it an "NES game". I think it ends up making a big impact on every NES game's design, probably moreso than other limitations of the system. At least, that's how it feels for me. RAM size, performance, etc. are "easier" constraints that take up less of my thought, but palette restrictions are a problem that never goes away.
Maybe an exception to this is to port other ideas to NES and "not care" how the palettes get distributed, like you could say that all the enemies are grey and just go with that. Kind of the least interesting option though.
(I feel similarly about the triangle channel and NES music. I feel like dealing with that one thing has the biggest effect on the whole.)
I get what you mean rainwarrior, and I agree. But at the same time, the mental image I have in my head of old Nintendo games from my childhood were that they were pretty colorful (minus yellow I guess). Megaman's blue color theme really sticks in your mind, and seeing Mario light up with fireflower power while raining fiery death everywhere.
Another thing I realized is that if you got some surplus in the sprite pattern department you can include duplicate sprites with different colors bits set. It can be pretty useful for say, white bullets in a megaman style game, since there is always bound to be some white color in one of the palettes currently in use.
You could also have duplicate sprites with less color details, thus being able to reuse a palette that only has 2 of the 3 colors correct. The loss of detail might not be noticeable if it's moving fast or of minor importance. Take the cannon balls in SMB3, they have a white shiny reflection on one side, but if that were to disappear in favor of a 100% black sprite in an especially crowded scene nobody would notice.
Drakim wrote:
I get what you mean rainwarrior, and I agree. But at the same time, the mental image I have in my head of old Nintendo games from my childhood were that they were pretty
No, that's exactly what I mean! A lot of NES games had very good use of colour! There a huge desire to do so, but the palettes make it a struggle. To pull it off, your game needs to be designed around the limitation, and I think NES game design is dominated by this desire. There are all sorts of arbitrary decisions in NES games about what enemies go together etc. that just wouldn't be made on other platforms.
The other thing dictating palette assignment is CHR ROM/RAM address space limit. If you are dynamically loading tiles into CHR RAM or swapping 1K (64-tile) chunks of VRAM using an MMC3-class mapper depending on what tile is visible, that may provide an additional constraint on what enemy combinations are viable.
$1000-$13FF and $3F11-$3F13: Player 1
$1400-$17FF and $3F15-$3F17: Player 2
$1800-$1BFF and $3F19-$3F1B: Enemy 1
$1C00-$1FFF and $3F1D-$3F1F: Enemy 2
How are you organizing CHR memory? What mapper, and ROM or RAM?
Gilbert wrote:
The SMS has only one single palette for sprites, and no sprite flipping feature too, forcing you to use different sprites for even just palette swapped objects and characters facing different directions.
Because it has no hardware flipping, a Master System or Game Gear game needs to use a lookup table to flip sprite tiles. But if you do that, you can make additional lookup tables with horizontal shrinking baked in, giving you
Neo Geo-style shrinking for free. (Z80 excels with page-sized LUTs.)
tepples wrote:
Master System or Game Gear
Yes, I know that, but still you need constant upload of data to video RAM, especially if you want to have a variety of enemies(or animated frames, etc.) on the screen at the same time, and that when different enemies using the same design but facing different sides appear in a frame you need two copies of them. Ironically the background plane has nearly everything the sprites missed: able to flip tiles, two palettes (though one is shared with the sprites) which could even be set individually for each tile (unlike the 2x2-tile attribute grid of the Famicom, unless you use MMC5). No wonder many SMS games abused background updates as much as possible, with the most obvious drawback being choppy movement due to objects aligned to a grid, and that many objects are terribly symmetrical(in both shape and "pillow" shading) in order to save memory by reusing tiles as much as possible(the rocks, trees, enemies and whatever in Space Harrier, and the town folks in Phantasy Star are quite noticeable).
tepples wrote:
How are you organizing CHR memory? What mapper, and ROM or RAM?
I'm using the MMC5, 8K sized CHR pages, with 8x16 sprites so that I get 8 separate sprite CHR pages to use.
It would be neat to use CHR RAM, but I'm not sure if it's even possible with the MMC5?
MMC5 supports CHR RAM, though no existing cart board came with CHR RAM. You'd have to modify a board to take CHR ROM, just as you'd have to modify cart boards to take flash memory for PRG ROM.
Currently there's no CPLD clone of MMC5, so think about that if you're seeking cart manufacturing.
For "constant upload of data to video RAM", look at what's going on in
Haunted: Halloween '85. The demo is part of the forthcoming
third volume of Action 53.
Drakim wrote:
So, I'm finding myself shocked and bamboozled by how darn few sprite palettes you can have at once. It's just four! It's not like I didn't know that beforehand, but now that I'm actually coding up my project I'm struck by how little four actually turns out to be.
I'm making a co-op kinda thing, so I'm using one palette for player one, one palette for player two, and now I'm left with two palettes for all the enemies and objects they encounter. Furthermore, I usually want black outlines on my enemies which means enemies can have a grand total of two sets of two different colors.
Sure, the two players are both sprites, but you don't have to always use sprites for enemies or objects! You can use the playfield quite effectively for:
Stationary objects - like the coins in SMB and SMB3. Unless you're using MMC5's extended attributes, you're limited to one playfield palette for every 16x16 metatile, and that's one reason why the coins are as big as they are. The coin palette is also used for other parts of the level, like breakable blocks and question mark blocks.
Stationary enemies - if the enemy scrolls with the level and doesn't otherwise move.
Boss fights - to have a really crazy boss fight with tons of objects on screen, many games would make the boss itself out of playfield tiles, and scroll the screen to make the enemy move. The
Guts Man fight in Mega Man 2 and the
Technodrome fight in TMNT both come to mind.
Since the boss is the playfield, the rest of the screen is just the background color, but that never seemed to bother anyone.
Technodrome is a terrible name.
drome means "racetrack" or running. This thing moves slowly. In no sense is it racing.
I'm not up on TMNT lore, but my first handwave would be that it used to be a racetrack for a traveling cyclesport exhibition before Shredder bought it to convert it to a mobile fortress.
I wonder if it was named in reference to
Videodrome, the excellent David Cronenberg sci-fi body horror film? And I think "videodrome" itself is supposed to be a portmanteau of "video" and "syndrome".
Quote:
In my view, dealing with the palette limitations on the NES is the one thing that most makes it an "NES game". I think it ends up making a big impact on every NES game's design, probably moreso than other limitations of the system.
I just quote you because I agree
Also the 8-sprites per line limitation make it difficult to overlay sprites without running into problems.
As for answering the original question, my opinion is that 1 palette for player 1, 1 palette for player 2 and 2 palettes for enemies is the very standard way to do it (assuming a 2-player co-op game). If you need the palette to change to reflect player's state there's not much else you can do. The only thing you can do is change the enemy's 2 palettes during the level.
Just Breed has a system where it loads the sprite palette dynamically in function of what it needs to draw, every frame. As far as I know this is unique. It also uses some sprite overlay for the hero, meaning the first 2 palettes are "fixed" and only the last 2 variable (dynamically loaded).
Another very simple "trick" is to have a constant sprite palette across the whole game. It might sound like it's not a very advanced technique, but it works wonders for
Castlevania and
Battletoads&Double Dragon for example. Since you know what colour palette you have at all times, you can reflect state changes of the player by changing them, and any enemy can use all 4 palettes freely.
Battletoads on the other hands has only the 4th palette which is variable.
One thing that might help in a co-op game is not making your player 1 and player 2 characters palette swaps of each other. That way they can use the same palette, and you can justify their being the same color as a uniform or whatever. But I'd need to see your character designs in order to tell whether that's plausible for your project.
tepples wrote:
One thing that might help in a co-op game is not making your player 1 and player 2 characters palette swaps of each other.
Or: Make them palette swaps in the way that you save their tiles twice in memory, only that one character uses a red shirt and blue pants while the other one uses a blue shirt and red pants.
That was one of the things that surprised me when I started looking into NES.
Like flashing/changing one sprite's palette different colours to show damage states etc. seems like such a common / obvious / easy technique on most other systems I'm familiar with, but on NES when it happens it's usually designed very specially around it. Maybe having several versions of the sprite in CHR for different rotations of the colour, or reusing one of the existing palettes instead, or if it's a "background" sprite using attributes instead of changing the palette itself. I did not expect all these work-arounds before I got to know the NES.
Been interesting reading this. I was under the impression that because the pallete is hard coded into the system you could actually change colour palettes on the fly.i mean for each level loaded, load title screen for example that uses 4 pallets, and Sprite layering using 4 pallets, then when going to level 1 use a completely different set of 8 palletes(4bg,4spr) and so on for each level. Turns out you can't if what I have read. It is literally 8 palletes throughout the whole game. Am I right?
No, you can change the whole set of palettes every frame.
The restrictions come from trying to juggle them. E.g. if you have 4 characters on the screen that each need a palette, what happens when you add a 5th?
Oh I got ya now, that's good to know. Thank you very much that was proper helpful.
When you're working with a limited palette you need to make the most of the colors you have. That's for any resource, really. Tile count, pixels, etc. There are many good examples of graphics on the graphics forum.
One thing you can do is make two characters that use the same palette where one has predominantly more of one color and the other has most of another color. The remaining color is used for details. Could be hard to do if one color is darker than the other (which I personally prefer to do rather than pick two colors with similar brightness).
I think the best thing to do is as mentioned to keep the game "simple" and change palettes during gameplay when needed if you want to add variety in a level.
As for unusual techniques:
If you don't mind a little "bzzt" effect you can get extra perceptive colors by flickering the tiles with horizontal lines, like what Macbee did with Lucky Penguin
https://www.youtube.com/watch?v=8i6bDMH4PaMAnother thing you can do is you can change the PPU intensity mid frame to get darker colors after a certain scanline. There's a game that does this to simulate water surface.
On my game megaman odyssey ...i always struggle so darn hard to deal with sprite palettes. You guys know how some enemies in the megaman games will have completely different sprite palettes in different levels ??
Like a sniper joe in mm 2 flashman may be pink-ish/red ...but then later in a Wily level the same sniper joe is purple/blue/orange or whatever.
For mine, i "dont" want enemies to use different palettes no matter where they may be, or in which-ever levels. So it makes it way harder to pair enemies with others. Often i'll have a custom palette change event when you cross through X screen at X position.
In the last hallway of pyro man level, i have nearly every single enemey type for the level appear, across 4 total sprite palettes "not" including megaman's blue and peach-white, and 2 times during the hallway i change the sprite palette a couple pixels before you scroll them on the screen to load their correct colors.
I also must delete the enemies with the "previous" palette so they dont get the wrong colors once the new ones are scrolled on screen.
It is possible to make mid-level palette changes completely dynamic if you load/unload palettes as objects are activated/deactivated. Each object's initialization code can check if its palette is already loaded, use the index where the palette is, and increment a counter indicating how many objects are using that palette. If the palette isn't available, load it in the next available slot and set its use count to 1. When deactivating an object, decrement the number of uses of its palette accordingly, and if that becomes 0, free the palette slot.
That way you don't have to worry about hardcoding palette changes to scroll positions, you can place enemies freely when designing your maps, you just have to mind the distance between areas patrolled by differently colored enemies, so that a palette slot is guaranteed to be available when an enemy using new colors shows up.
tokumaru wrote:
It is possible to make mid-level palette changes completely dynamic if you load/unload palettes as objects are activated/deactivated. Each object's initialization code can check if its palette is already loaded, use the index where the palette is, and increment a counter indicating how many objects are using that palette. If the palette isn't available, load it in the next available slot and set its use count to 1. When deactivating an object, decrement the number of uses of its palette accordingly, and if that becomes 0, free the palette slot.
That way you don't have to worry about hardcoding palette changes to scroll positions, you can place enemies freely when designing your maps, you just have to mind the distance between areas patrolled by differently colored enemies, so that a palette slot is guaranteed to be available when an enemy using new colors shows up.
This is the system I'm currently using, plus the added functionality of objects having a list of palettes (ordered by desirability) so that if all four palette slots are taken, it will settle for second, third, fourth, fifth, etc, choice. Obviously if there are zero matches the object despawns instantly.
Furthermore, I recently added so that each palette choice on the list can point to different sprite CHR data, meaning that there can be specially adapted patterns for dealing with tight color situations. For instance, my fireball sprite is usually red and white, but it can "downgrade" to just white if it finds a palette with the colors "white, blue, green" and there is nothing better available. When it does this, it changes it's CHR data to be some patterns which has the red trimming part removed in favor of a 100% single color version.
I don't do this for everything, most sprites look terrible with too few colors, but it's a great alternative for objects that tend to randomly spawn everywhere (so you can't tactically plan it's placement out in the level editor) and objects which would seriously annoy the player if they just failed to spawn (Mario's fireballs!)
wow that was umm... very confusing and i barely understand any of it.
from tokumaru's reply.
kuja killer wrote:
wow that was umm... very confusing and i barely understand any of it.
from tokumaru's reply.
Just think of it this way:
Imagine a game that starts out empty, nothing is going on. But then a Goomba walks in from the right. When that happens, one of the four sprite palettes is changed to suit the Goomba's color scheme. That first palette is marked as "occupied".
Then a Koopa Troopa walks in, and he needs different colors from the Goomba, so the second sprite palette is "occupied" by him. So now two out of four palettes are taken.
But then the Goomba walks too far and falls off the edge! He is gone, and so, the first sprite palette which he was using is no longer "occupied", it's free to be used by something else. Now only one out of four palettes is occupied (by the surviving Koopa Troopa). We just keep this up as new enemies appear and die, constantly adapting what palettes are used and which are not, depending on what sort of enemies have appeared.
Normally you'd only be able to have four different objects on screen at once by doing this, but you can be clever and make two enemies with the same coloring scheme "share" one palette slot rather than taking different ones. Instead of marking if a palette is "occupied" or not, you mark down how many objects are currently using it, and treat the palette as unused and free to be changed if that number is 0.
Understand now?
Drakim wrote:
I'm making a co-op kinda thing, so I'm using one palette for player one, one palette for player two, and now I'm left with two palettes for all the enemies and objects they encounter. Furthermore, I usually want black outlines on my enemies which means enemies can have a grand total of two sets of two different colors.
I think it's a given that the two palettes for your main characters should be reused for enemies. You want the main characters to stick out, but there's a limit to how much you can afford sticking out in an NES game. I would never reserve any palette to just one purpose.
Quote:
But, that runs into a wall if you are planning on changing the palettes, for instance like when Mario gets a fire flower and switches to a new yellow and white palette. Unless you are willing to have enemies also magically change colors out of the blue along with Mario then reusing palettes is difficult.
This entirely depends on the game of course. Mega Man is entirely designed around palette changes, and his powerups will change color whenever he does. More ideally, if a palette change for your main character is required (and honestly, it really isn't!) I'd reuse one of the palettes otherwise designated for enemies.
The downside here is that this requires you to use at least that one palette for every stage in the game. The "upside" is that you're now allowed to add a third palette to your main characters for a more vibrant look that I'd say the character you're staring at for the entire game deserves. The classic example here is the Contra guys, who share a palette for the upper body, but have individual pant colors. You don't have to overlap sprites to make use of multiple palettes, and since your main characters are probably going to be bigger than 8x16 in size anyway, you might as well add another palette.
Quote:
But it's entirely possible to change the palettes on-the-fly inside of a level depending on what enemies appear. Doing so offers a number of pitfalls though, what to do if all four palettes are already in use when a new kind of enemy appears? Simply delete it?
Rainwarrior already mentioned how the palette limitations is one of the defining limitations of an NES game. However, in general one thing I think really affects how
any 8-bit game plays is how both gameplay and level design is tightly controlled by how the game deals with its limitations.
The classic example is Super Mario Bros. You can freely destroy almost any block in the game. This would use an excessive amount of memory if the game allowed you to scroll backwards. So it doesn't.
Similarly, for games with a multitude of different enemy types, I'd design stages around not running into more types than intended in one area. One of my favourite examples for how to do stuff in an NES game is
Shatterhand. This game dynamically loads enemy sprite graphics into the CHR with bank switching whenever an enemy of that type appears, along with the color palette needed for it. That allows for much more detailed and animated enemies, but just like with the palettes it obviously means you can only have so many different types on screen at any time. But because the game switches out its set of enemies almost constantly, and the player will perceive the entire stage as "one area" the game ends up feeling incredibly varied.
It's not unusual for an old game to have a glitch where tricking an enemy into following you into a new area will completely screw up its graphics because games are doing this.
Sumez wrote:
Similarly, for games with a multitude of different enemy types, I'd design stages around not running into more types than intended in one area. One of my favourite examples for how to do stuff in an NES game is Shatterhand. This game dynamically loads enemy sprite graphics into the CHR with bank switching whenever an enemy of that type appears, along with the color palette needed for it. That allows for much more detailed and animated enemies, but just like with the palettes it obviously means you can only have so many different types on screen at any time. But because the game switches out its set of enemies almost constantly, and the player will perceive the entire stage as "one area" the game ends up feeling incredibly varied.
It's not unusual for an old game to have a glitch where tricking an enemy into following you into a new area will completely screw up its graphics because games are doing this.
The Curse of Possum Hollow does the same thing with CHR banks as how you describe
Shatterhand. Two enemy sprite sheets are allowed to be active at once, and some enemies are designed to share a 1-page sprite sheet (such as larger zombies and ants, or rats and ground hands). If active enemies use more than two different sprite sheets, they are put in a queue to spawn once an enemy is defeated, after which point they pop into view. Late in development, I wrote a tool that searched the level definitions for cases of possible pop-in, based on which enemies use which 64-tile sprite sheets, but there are still a lot of places in the game where you can lure enemies into a place where you can keep other enemies in the queue. Is pop-in more objectionable than corrupt graphics?
If the game in question doesn't have a natural method to keep enemies from following you (that's very easy for most beat'em ups since they tend to block progress until you killed all enemies on screen), I'd personally just despawn the enemy that isn't "intended" to be active at this point.
If you're able to keep an enemy alive in a way that prevents new enemies from spawning I think that makes it too easy to cheese the game and play it in a way that wasn't intended. I can't recall any titles, but there are definitely games out there where this is a known strategy.
Of course that could still be interesting to explore for speedrunners etc. if it's not too obvious.
For despawning long-lived enemies who follow you, one technique can be to have a flag on enemies that can mark them as "expendable". If some new enemy wants to spawn and there is a lack of resources (palettes, CHR banks, object slots, etc) then the game does sweep over the active enemy list and deletes some "expendable" enemies.
You raise the "expendable" flag on enemies under whatever conditions you feel is fitting, such as them being too far away from their starting point, or having lived too long, and so on.
Thus, enemies can still "chase after" you and will only despawn when it becomes an issue. The player won't be able to exploit the game by intentionally dragging enemies along with him, but they also won't disappear unless absolutely necessary.
That works for a completely dynamic design where any enemy can appear anywhere. But personally I actually enjoy the idea of designing a stage around which object will appear where. I really think it's a big part of the identity of old-school games.