Read-only archive of the Armageddon Games Forums Archive (2000–2026) · About this archive

Post 2.5 ideas

45 replies · 15,212 views · Started 18 May 2009

What are some ideas you may have for things that should be implemented after 2.5 is completed?

What I want most is more Enemy Misc. Attributes--for example:

Being able to change a darknut's shield:

Misc 6: The "HP" of the darknut's shield. In other words, how many times you must hit the darknut with a hammer before it loses its shield. If 0, the shield cannot be broken.
Misc 7: Which projectiles the shield blocks (use same #s as for shield item misc. attributes)
Misc 8: Which projectiles the shield reflects (use same #s as for shield item misc. attributes)
Misc 9: For which directions does this apply: 1 = Front Only (direction the enemy's facing), 2 = Back Only (opposite of direction enemy's facing) 3 = Front & Back 4 = Sides Only 5= Front & Sides, 6 = Back & Sides, 7 = Shielded from all sides

So by default, darknuts would block arrows, magic, sword beams, etc. from the front. But you could make a darknut who's shield reflects magic & blocks all other items from the front AND back (so you'd have to kill from the side)

Leevers:
Misc Attribute 4: If 0, nothing special. If 1, the leever will shoot a projectile once each time it emerges from the ground before moving. If 2, the leever will repeatedly shoot a projectile after it emerges as it walks around.

Tektites:
Misc Attribute 4: If 0, nothing. If 1, whenever the tektike lands, it'll shoot a projectile.

Peahat:
Misc 1: How often the pea hat has a chance of landing (in # of seconds)
Misc 2: The inverse chance of pea hat landing at said interval
So for example, if misc 1 is 10 & misc 2 is 2, then every 10 seconds, the pea hat has a 1 in 2, or 50%, chance of landing.
Misc 3: Duration that the pea hat stays landed (in # of seconds)
Misc 4: If 0, nothing special. If 1, peahat shoots projectile only as it is flying. If 2, peahat shoots projectile only after it has landed. If 3, peahat always shoots projectiles, whether it landed or is flying.

Projectile (Fire Shooter, Arrow Shooter, etc.):
Misc 1: How often it shoots the projectile (in # of seconds). So if it's 3, it'll shoot one projectile every 3 seconds. If 8, it'll shoot once every 8 seconds.

Wall Master:
Misc 1: Where the wall master warps Link if it catches Link.
0 = Dmap's Entrance
1 = Uses Sidewarp A
2 = Uses Sidewarp B
3 = Uses Sidewarp C
4 = Uses Sidewarp D

Pol's Voice:
Misc 1: Inverse chance of it jumping when it moves to a new combo
Misc 2: What item it's vulnerable to:
1 = Arrow
2 = Magic

Zora:
Misc 1: How long Zora stays emerged before it disappears again
Misc 2: How long Zora stays submerged before it reappears
Misc 3: If 0, the Zora emerges randomly. If 1, the Zora emerges on water combo close to Link.

Tribble Enemies
Misc 4: How long (in # of seconds) the enemy can wait before its killed until it transform into another enemy. For example, you can adjust how fast or slow a gel tribble transforms.

Also, for ALL enemies, be able to change the size of the enemy, from 1 tile to as large as 4 x 4.

A couple more:

Arrow/Boomerang Items: Add a sprite selection for the sprite when it hits a wall. It drives me nuts with it hardcoded to tile 54. Would be nice to have it have a set of 4 tiles for arrow impacts, so you can make it look like the arrow's actually sticking out of the wall for a second.

Ganon: Selectable "death beam" sprites. Can get frustrating when you want to use page 0 for something else, yet you have to remember to not use those 3 tiles, on top of the rest of the junk that has to be there. Right now, my page 0 is flooded with "In Use" markers due to the hardcoded stuff. The whole goal is basically "Un-hardcode" page 0, minus the first 4 tiles.

And of course, I'm sure its been suggested a million times already, but add the "Guy" enemies to the enmy editor list so we can change those tiles too.

Eh, this is light stuff. Give them a challenge they're willing to really try!

What I would basically like to see, is that ZQuest goes outside the window - Actually not base itself within a little 320x240 screen, or a larger yet unwieldy version, but instead create a series of windows that can be scaled, closed, and removed if undesired.

Also, if it's going to be based on actual windows, I suggest expanding the palette to something like 512 colors - Not that some people need all that space, but given that some people want to rip MC graphics they can actually use the GBA palette setup.

Oh, and a few code snippets that are floating around should actually be turned into features, like the talking NPCs or bottomless pits. 😊

Did I mention a complete rebuild, from the ground up, so you can not run into so many problems and bugs?

Actually the idea of NPCs and Pits aren't really nessesary since there re scripts for that.

How about solid ffcs and throwing pots?

Most recommended: pick-up and throwing objects and some Z3 movement bosses.

I'll stick this since that hacker deleted the other thread.
Anyway, feel free to re-post your ideas for after 2.5 right here!

I feel that despite the fact that scripts exist, a pit combo type would be a lot easier to deal with, but I can wait for the combo type editor that was brought up once for that and ice combos to happen.

I'd love a Guy Editor. I'd also love a screen flag that makes the invisible wall associated with a Guy disappear when the Guy does; as it is, the closest thing is the Feed the Goriya room type. Guys in general could use some love especially if NPCs aren't implemented into ZC proper.

A way to have branching rather than simply linear lweapon families would be awesome, but probably too complex to do.

The only other thing I really wanted... well, just got implemented. 😃 -- Pteryx

Here are some ideas for further custimization in the enemy editor:

1. Additional Shot Types:
-2 Shots: Shoots 2 shots at once in any combination of the 4 compass directions (so Up and right, left & right, up & down, up & left, etc.)
-2 Shots (Opposites Only): Fires 2 shots at once in the 4 compass directions but they will always be shot in opposite directions. In other words, can shoot Up and Down or Left & Right.

2. Add "Leaver" to the mix...Correct me if i'm wrong but i believe the only other difference between a Leever and other walking enemies is that it digs into the ground & reappears. Oh, and it can't currently shoot projectiles or have other properties that Walking Enemies have, like have a shield. But Leavers should be able to fire off weapons & be shielded, as well as have Touch Jinxes...same with many other enemies too, like Tektikes & Peahats (but they dont ever walk so that's why they're not included in the this category)...Or perhaps just keep Leaver as its own category if need be but allow it to have defenses (shields) and projectiles as well.

3. For "Death Type", have both a "normal" and "instant" type...the difference would purely be cosmetic. "Normal" is kept the way it is...when an enemy dies, a puff sprite appears (it doesn't damage Link but it shows that the enemy has been killed). For "instant", when you defeat an enemy, it disappears without any sprite. I could think of many instances when this might be necessary so you dont want it to look like you've actually killed an enemy even though you may have done so.

4. For Defenses, why not add "Reflect"? This would ultimately be the highest level of defense. Not only can an enemy protect itself from Link's weapons, but it can reflect them back at Link (only applicable for certain weapons I realize). There could be 2 kinds: Always Reflect (so it reflects the weapon 100% of the time) and Rare Reflect (the enemy will always block that weapon at the very leas but it also has a chance of reflecting that weapon occassionally)

5. Some sort of way of determing how many hits with the hammer it takes before the enemy's shield is broken if the enemy is a shielded enemy & the "Hammer Can Break Shield" flag is checked. Similarly, a way to make it so that you can choose the enemy's tiles with a shield if it is in fact shielded & then choose seperately what the enemy's tiles are if the enemy then loses its shield.

6. Gravity Rate: Another variable you can set...either put on Data 1 or Data 2 tab. What this changes is how the enemy is affected by Gravity. So for example if an enemy has a higher Gravity Rate, it will fall faster when the "Enemies Fall From Ceiling" flag is set. Also, for enemies that jump (like Vires, Tektikes & Peahats), they will jump higher or shorter depending on their Gravity Rate (so maybe 50 is like the default value & anything larger would mean a smaller jump & anything lower would be a smaller jump)

I'VE SAVED THE BEST (imo) FOR LAST! MY FAVORITE NEW, POTENTIALLY EVIL ENEMY PROPERTIES:

7. Peril Damage: A checkbox for an enemy on the flags tab...if set, then when you have damaged an enemy until it only has a certain # of hits left until it dies, then the amount of damage it does is doubled. So for example, if you have a Darknut with a damage rate of 4 and 32HP and attack it until it only has like 2 HP left, then it's damage rate becomes 8.

8. Peril Speed: Another checkbox...if set, then when the enemy's HP gets down to a certain point, it's speed is doubled.

9. Peril HP: Here you put down a number...this determines at what HP does the damage amount and/or speed double for the enemy. If it's greater than the enemy's original HP, it does nothing since that doesn't make much sense. Likewise it also does nothing if neither Peril Damage nor Peril Speed are checked. But if one or both are checked, you can determine when how many hits are left do these flags take effect.

10. Peril CSet: You can leave at -1 so that means its CSet doesn't change...or you can change the value so that when the enemy's HP gets down to a certain rate or lower (as determined by the Peril HP), the enemy's colors can actually change.

It would be nice to have the Death Type, Death attributes, etc. (new Walker Data 1 tab) options applied to flying enemies. That is, bring Keese and Peahats into the family (with new "walk types", of course- maybe calling it movement type).

Aside from that, it would be nice to have pre-defined movement types specifically for use in sideview gravity. I've thought of a few:
1. Walker - Just walks around. This is what we have already.
2. Patroller - Walks until it reaches and edge of a platform, and reverse direction if it finds one.
3. Clinger - Holds fast to solid combos. If combo is floating, it will circle around. Needs a parameter to determine initial direction (so as to set clockwise/counter-clockwise motion).
4. Swooper - Holds on to ceiling, and swoops down when Link approaches.
5. Divebomber- Comes from the top of the screen, then flies at Link. Parameters for period and amplitude could be added to make the latter motion a wave.
6. Glider - Similar to the above, but comes from the side. Same parameter idea for making it a wave.
7. Hopper - Jumps when Link approaches. Parameters for height and distance could be supplied.
8. Climber - This one's a bit more complicated, as it requires a specific type of combo be defined as climbable. It would be an enemy that just moves up and down a chain/vine/ladder.

Speaking of post 2.5 ideas, if there's going to be a combo type editor and a flag type editor after 2.5, then perhaps there should be a room type editor.

How about an new item called...... THE AXE!!

I know it's not really a Zelda item, but I know I haven't ever seen the Stomp Boots before either. Basically there would be a new combo type that would be called 'Tree' or 'Breakable Tree' or something like that. Sort of like the hammer, except it is stronger, slower, and in ZC purely for story and difficulty. You like?

couldn't you just edit the hammer to be stronger and just make the tree be a pound block with the stump combo following?

I am constantly extraordinarily eager for even a single frame's worth of extra computational time between when Link has health greater than zero and when Link's health is zero or less. That would allow us to insert a script to use a captured fairy, or to allow for a condition "If Link Dies, do this." Right now, all it does is give you the Game Over screen with no chance for anything else.

Because right now, what if there was an attack that did more damage than Link has maximum health? We'd have no way to check to see if Link is below 3/4 of a heart to execute such a similar script.

I'd also love to get rid of the spinny spinny *pop* death somehow. 😛

ShadowTiger wrote:I am constantly extraordinarily eager for even a single frame's worth of extra computational time between when Link has health greater than zero and when Link's health is zero or less.

This I will look into. Thanks for reminding me. 😊

sps999 wrote:couldn't you just edit the hammer to be stronger and just make the tree be a pound block with the stump combo following?


That's the thing, I wanted the hammer and axe to be separate items to increase difficulty. How? Instead of having the hammer smash all pound combos, you could have the player wait until they find the Axe to do certain puzzles or advance in the quest.

New Ideas:

I've been playing Spirit Tracks all day and I've come up with some new ideas:

Train/Mine Cart: This is more based off of the Oracle games than Spirit Tracks. There would be a cart/train on a set of tracks that could transport you to other parts of the dungeon. It would also feature a switch to change certain tiles to change the direction you would head. It would function exactly like in the Oracle games.

Indiana Jones Whip: Just like in Spirit Tracks

Whirlwind: From Spirit Tracks, I thought this item was actually a really good idea.

Non-Spirit Tracks Ideas:

Playable Music: The ability to set notes and warp locations, or functions for each song.

Deku Stick: As a crappy weapon, or to solve puzzles with FIRE!!!!

Deku Nut: Stun non-Boss enemies on screen for a few seconds.

"Door of Time": A rule that does not use Triforce Shards, but two separate item sets, the first to unlock something, such as the Door of Time in Ocarina of Time, and the rest as what Triforce Shards were used for.

Tunics: A rule that makes useable tunics, and that makes the Rings not change Link's color. That would allow you to change your tunic. For example:

-Kokiri/Green Tunic: No power, but resets attacks from enemies to normal levels.

-Goron/Red Tunic: Allows you to walk across "Fire" or "Lava" combos. Makes you extremely vulnerable to Ice Magic (This is in the making right?), triple the damage to falling in water without flippers, and double the damage to being attacked in water.

-Zora/Blue Tunic: Allows you to dive under water forever, and enter certain warps. Makes you extremely vulnerable to Fire/Lava, and health is drained in rooms marked "Volcano" (from OoT).

-Magic Armor: 1/2 Damage, 2X Attack, but quickly lowers remaining rupees.

Cool ideas right? :googly:

Edit: Why is this here --> -Zora/Bl

How about a move towards SVG graphics and free-scale window sizes, ala Super Maryo Chronicles.

I dont know what kind of framework ZC is built upon currently, but a move in this direction would facilitate new graphic design.

Perhaps this is restricted by the tile-based rendering. -shrug-

FefeRawft wrote:I've been playing Spirit Tracks all day and I've come up with some new ideas:

Train/Mine Cart: This is more based off of the Oracle games than Spirit Tracks. There would be a cart/train on a set of tracks that could transport you to other parts of the dungeon. It would also feature a switch to change certain tiles to change the direction you would head. It would function exactly like in the Oracle games.


Essentially a raft you can attack from as it moves along it's route? (with changed graphics to look like a mine cart). Zelda Classic uses Allegro for it's engine.

I assume the switches could be created by linking combos together. Sorta like this, only constantly linked together. I guess the raft isn't essential as long as you put the flippers into the game.

What I'd be more interested in, and which I will be scripting shortly, are those arrow deflectors from ST. The ones where you can hit them with the sword to change their direction, and when an arrow hits them, they shoot it straight forward.

Two things I would really want is this:

1. In Large Mode, I want there to be a way in toggling the combo selector on the right. There are three of them, and because their are three of them, it is really hard to see, even in full screen. I am always trying to grab the correct tile but I can never see it as it is too small. So my suggestion is a button that toggles the combo selector to show: 1 combo selector, or 2 combo selectors, or 3 combo selectors. As it is set to 3 right now, it would be cool to toggle between them so that if selected 1 combo selector to be shown, then it would just show the one, and it will bigger, so I can see the tiles (so it will look like small mode of how big it is). That is the one of the only reasons I like small mode more is because of how small it is to see those tiles I am choosing (especially if I have a lot of tiles that look the same. If this was implemented, it would be gold.

2. Have a screen data spot that is called Link's position. In every screen when this is set to 0 (as deflaut), it will just have Link's original position in the dmap, however, when you put in the screen number, it will place Link's cursor in the place you told it to. So that when doing cutscenes, you don't see his cursor jumping around. Just set it to example: Screen number 09. It will place the Link cursor in Screen number 9. And it will make it look like Link never moved. Which would be great.

Shoelace wrote:
2. Have a screen data spot that is called Link's position. In every screen when this is set to 0 (as deflaut), it will just have Link's original position in the dmap, however, when you put in the screen number, it will place Link's cursor in the place you told it to. So that when doing cutscenes, you don't see his cursor jumping around. Just set it to example: Screen number 09. It will place the Link cursor in Screen number 9. And it will make it look like Link never moved. Which would be great.


It's for something approaching this reason that I added the "Don't Show Link Marker in Minimap" screen flag, which is sort-of sufficient for this concern. (Personally, I think cutscenes should use the "No Subscreen" and "But Don't Offset Screen" flags, but that's more a preference than anything.)

True, but on the other hand I do a lot of tile warps in my game that make it look like you are in the same screen when really you are not (in gameplay, not cutscenes). It is done a lot on HoD. I just noted it because I was just watching a playthrough on my game on youtube, and Sillycat commented on how often the cursor had jumped in a screen he walked through. XD

Can we open up C-Set 12, 13, and 14 for general use? The only thing that is preventing this from happening is that ZQuest uses 12, 13, and 14 for the interface palette, and that special sprite palettes utilize C-set 14.(but only 14?) Currently its possible to use 12, 13, and 14, but you would have to remember which colors are where, since the interface palette used in those slots, but c'mon, can you at least remove the need for that while in tile editor mode?

How about having the 12(or 15) C-Sets change per level, as well? I mean I like static palettes as much as the next guy, but I also like to utilize as much as possible at any given moment. This would also remove the need for boss palettes, I would imagine.

I've said this before, but that was before the forum was hacked, so it's been lost...

I'd like to see a shovel item. This would entail several things:
* A new item type, Shovels.
* A new combo type, Dig->Next. This is because it's important to be able to dig on more than one type of combo per screen. A simple Dig flag wouldn't work, although a set of possibly 4 distinct dig flags might work just as well.
* Link may need a new 'digging' animation.
* Item Drop set: could use Tall Grass or have a new, dig-only set.

Possible tweakable properties of the Shovel:
* Does it work only when facing left/right? Or left/right/up/down?
* How fast (slow actually) is it to dig?
* What sound effect plays when you dig?
* Can it be used as a weapon (albeit a slow one)? (And yes, I know that is unprecedented, but no reason it can't be).

Along with the room type editor I suggested for after 2.5, perhaps there should also be an item class editor, in which the names of the item classes could be changed, but the hard part would be implementing the ability to change the functions of the item classes. In addition, the tricky part of making a room type editor would be implementing different features for different room type categories. And one more thing, perhaps a counter editor, which could be used to make counters for things other than rupees, hearts, bombs, arrows, keys, magic, and super bombs.

What I would think it would be nice is to have a visual absolute tile/side warp destination spot like you know in RPG makers that when you set a player transfer, you can see the actual map and pick a destination spot and you're there.

All I could ask for are two common Zelda functions (which wouldn't be too hard to implement now, but a feature freeze is a feature freeze).

1. Correct item flicker. In all games since LttP, dropped hearts/Rupees/etc appear immediately, then flicker right before they disappear.
2. Maintaining HP when you continue. Instead of setting a continuing HP (all hearts, percentage of hearts, etc.), make an option that, when you save and continue, you maintain the same HP as before.

I haven't checked new betas for awhile, so if any of these are already implemented, sue me. 😛

Pineconn wrote:All I could ask for are two common Zelda functions (which wouldn't be too hard to implement now, but a feature freeze is a feature freeze).

1. Correct item flicker. In all games since LttP, dropped hearts/Rupees/etc appear immediately, then flicker right before they disappear.

That's not a bad idea.


2. Maintaining HP when you continue. Instead of setting a continuing HP (all hearts, percentage of hearts, etc.), make an option that, when you save and continue, you maintain the same HP as before.

I haven't checked new betas for awhile, so if any of these are already implemented, sue me. 😛

I think that's what the save points are for.