One thing to keep in mind is DK's ROM size of 16K of code & data. The original game had about 300 bytes or so of unused space, and that got used up real quick since it wasn't much. Any changes after that required poring through the code looking for ways to squeeze a byte out of it here and there to make up for additions.
I haven't exhausted all the ways to shrink the code yet, but the further we go this way the harder it gets to find new bytes to free up.
Rule alterations to existing logic are not expensive to implement so I like those.
Springs: Yeah, that was the one thing I worried that I cranked up too high. I'll have to dig into the code a bit to see how difficult your ideas would be to implement. The spring jump arcs are all hard-coded data tables. Space limitations would make it difficult to add new tables for different arcs. There might be a way to re-use the existing data and just run it through some math to make a taller arc and that might work. Hopefully existing routines could be altered to allow differently acting springs. This one will need some investigation.
Something easy might be... Springs currently always come into existence at fixed time intervals, but they pop into existence x to x-15 pixels beyond the left edge of the screen. (Actually x to x-23 in this version.) I could simply add an increasing wiggle to the time intervals, which would make them vary even more (but in this case not alter their landing points that we use to see their timing). The effect would add more possibility of gaps to make it up the ladder, but it would disrupt existing strategies.
Your other spring idea, I quite like. Maybe if I could tap the game's barrel physics routine to handle a bouncing spring, then I'd avoid having to create memory-eating data tables. I should look into that.
(Yes, the game is that illogical. Barrels, which don't make much use of it, have a gravity/physics engine. Springs, which bounce around, do not use it.)
Rivets & Pies: Altered rules for deciding which side AI spawns into. I totally agree with you. I think I could even make it so the 'undecided' zone simply starts out 0 pixels, then very slowly grows by more pixels until reaching some decided maximum width by L21. I didn't play with Jumpman's starting location here like I did in Remix, but those are exactly the kinds of reasons why I did change them in Remix.
Barrels: I don't know if you played the later revision, but the earlier version had a bug in the barrel release timers that made them slow down before starting to speed up again at later levels...arg. The current version has consistent decreasing release timers as the level increases. It also ramps up the longer you stay on the board.
The new wild barrels went a little too far, so I added some balances to the revision. The evilness adjusts depending where you are, so you shouldn't get the really nasty barrels where they're hardest to avoid.
The oil can idea is interesting, but it'd be a lot of code, data and a headache to implement because of the way the existing programming is done. If I overcome the technical issues, what rules would the extra oil cans have? Would they stop every barrel that ran into them? Only some? only blue ones? I like the idea of oil cans spawning fireballs higher up, but they'd kind of break the rules if they didn't also stop barrels from reaching the bottom.
Thanks for the input, it's much appreciated.