18 replies to this topic

[Anthus]

Gone away are collecting swords, and heart containers, and magic. At least in the traditional sense. The idea here is that there are "take one item" rooms presented throughout the quest. There would be 24 in all (for a total of 8 max for each "stat"). There would be one at the end of each dungeon, and 16 more scattered throughout the world. The items would be either a heart container, a magic container, or a sword upgrade (enemies would need to be adjusted, but this is all conceptual).

 

This needs no scripting, and can be done with ZC out of the box to create a decently functional choice-based level up system. Scripting would come in when it comes time to limit how far in one direction Link can advance. In Zelda 2, each of Link's stats max out at 8, and then the other ones must be upgraded (or skipped, if you so choose). This is a good idea. Imagine if Link chose to forego everything except sword upgrades. With a Level 24 sword, the game becomes laughably easy, and broken, pretty much (in ZC).

 

Capping each stat does not get rid of this issue entirely, but it does circumvent is nicely, and creates its own unique strategy. Having 8 attack, and 1, of magic, and life might make enemies very easy to kill as early as half way through the game, but then on the other side of the coin, you can be killed very easily, and have limited use of items (since in my idea here, we are going with a stamina bar that gets bigger vs. real magic). Capping each one out at 8 would still encourage growth, but not make the game as broken.

 

Now, for the scripting. With the "take one item" rooms, they present a set of challenges for this concept. The rooms only show up ONCE until you pick an item, then are all gone forever. This rules out use of an item pick-up script since the item must be already picked up for the script to run, thus making it useless. When I was thinking this out, my first thought was along the lines of, "Oh, I'll just have an item pick-up script prohibit Link from grabbing this item if he already has 8-- Oh wait, he has to still pick it up, rendering the room gone, and removing the other choices permanently".

 

To get around this, I was thinking of another scripted method, possibly a global script, but I'm not sure: Basically, there would be a situation where Link passes through a hall way or something before the upgrade room. This room would hide a trigger which checks Link's amount of each upgrade item making sure it is 7, or below. If it is at 8, then the script would change the value of the shop used for the upgrade room to one of three variants which does not have the item Link already has 8 of. Alternately, you could forego the hallway trigger altogether, by using a script that checks the inventory upon entering the room. This script would then change the shop value out as the room loads, not needing a separate trigger room. I'm just not sure which is more feasible. You with me so far? I think this would be a really cool thing to do in a quest.

 

There are some other things I have not yet experimented with, or that might still make this more complex than what I have in mind. Right now, I am operating under the assumption that a 'counter' can be attached to Link's hearts and magic, and even sword upgrades in a way that can also be used as a variable in a script without scripting initially. Basically, heart containers, and magic containers use a counter like bombs and arrows which can be used as arguments in a script. Making sense still? Furthermore, I don't know if those counters can be placed on the subscreen to show the level number (1-8 ) like in Zelda 2 without scripting. I also am not entirely sure on whether the life upgrades should instead use rings to reduce the damage Link takes by smaller percentages, rather than just giving whole Heart containers. Zelda 2 does both, but it also only has 4 heart containers to find. This is all conceptual, and I'm basically just wondering if this would even work before I even think about drawing a single screen in ZC outside of my current projects.

 

Thanks for sitting through one more of my posts about stuff I might try to make.

[justin]

two thoughts.

1) it would be very easy to do what you want with scripts. wouldn't need to do any ZC-trickery, basically just create a new room-type by placing an ffc that does all the checking, placing and removing of items on the screen

 

2) while i get you want to cap to 8 like AoL, it could be very interesting to not cap, and give players the option to fill one skill to the brim to create interesting challenge runs.

[Anthus]

The more I think about it, there really is no reason to cap the level (other than by limiting the amount of rooms to upgrade). It would be easier to implement without a cap, and offer more play options to a wider range of players which isn't a bad thing. Maybe in a 'real' game there would be a cap for the reasons I stated above, but part of the fun of ZC is making stuff you can't play anywhere else. 

 

For the sake of keeping the subscreen clean, I need to know if it is possible within the current editor to change how health and magic are displayed in a certain way. I'd want to use one constant physical length for each bar (life and magic). As Link collects heart containers and magic, the bar needs to stay the same physical size, but still increase in effectiveness. Again, this is how Zelda 2 handled it (sans collecting bar-extending containers), since I'm kind of bad at explaining this. This would avoid having odd numbers of hearts, or an extremely long magic bar (other reasons I had for capping it off), which will look messy.

 

If it is possible to have bars change the percentage it represents of life and magic, I would rather have it uncapped, so long as it looks neat. The sword level would still just be a regular ol' number though. There would  ideally be a number next to the life, and magic bars giving its current level. These could be counters connecting to the ring items, if that is possible.

 

Some other ideas for tweaks I have if it is left uncapped is that the change in strength between levels would be slightly less dramatic. This hypothetical implementation has Link starting out with say, 16 hearts, displayed as a segmented bar that is only eight or so units long. Instead of collecting heart containers, Link just collects a bunch of ring items. Each one has a 10% (or something) increase in defense over the last. Stamina can be handled in a similar way. You start with a large amount, and upgrades increase the time in which is refills (magic rings).

 

EDIT: I wouldn't even need counters to show up on the subscreen if I decided to just make tiles of the number, and layer it over the graphic for the stats and use those as the displayed item sprites. I dunno.

[Deedee]

You'd be surprised to know that you can actually do this upgrade cap system without scripts, but I'd rather not get into the depths of it unless I had to.

 

I'd make the cap 12, out of 24. This way you can balance out all your stats, or you can just raise 2 stats until they are maxed, but lose out on the third stat.

[justin]

i'm not sure about a non-scripted fixed length percentage based health / magic bar. but it would be easy to do with a script drawing over the passive subscreen. 

[Anthus]

I'd be interested in hearing how that would work.

 

It has also occurred to me, I wouldn't have to worry about a messy subscreen with the methods mentioned at the end of my last post. Just have Link start with the max amount of HP/ MP, then have items increase his resistance to attacks. Yaaaaay

[justin]

I'd be interested in hearing how that would work.

 

i'm assuming you meant the subscreen health/magic meter thing, and not the ffc "choose" screen.

 

here's a version of the subscreen meters from a quest i was working on. sorry it doesn't use any constants. the rectangle draw is calculating the percentage of max, and then the drawtile is drawing the border over top. should compile, and you just toss call UpdateCounters() inside your global loop.

 

void UpdateCounters(){
 //tile 29010, cset8, yh=5, xw=13+16+13
 
 if(Link->HP > Link->MaxHP) Link->HP = Link->MaxHP;
 Screen->Rectangle(7, 27, -46, 27+42*(Link->HP/Link->MaxHP), -42, 123, 1, 0, 0, 0, true, 128);
 Screen->DrawTile(7,24,-50,29010,3,1,8,-1,-1,0,0,0,0,true,128);
 
 if(Link->MP > Link->MaxMP) Link->MP = Link->MaxMP;
 Screen->Rectangle(7, 27, -19, 27+42*(Link->MP/Link->MaxMP), -15, 115, 1, 0, 0, 0, true, 128);
 Screen->DrawTile(7,24,-23,29010,3,1,8,-1,-1,0,0,0,0,true,128);
}

[KingPridenia]

Yeah I'm with Dimentio. Having a cap of 24 is a bit too much. You should consider that in AoL, level 8 Attack made you do 12x damage, but level 8 Life cuts damage down by 75% compared to level 1 in each. If the cap was 12 with a total stat limit of 24, it could be workable having 12 in one stat, 11 in the other and 1 in the last. Problem then becomes how do you balance a game properly around that? Then again, I'm assuming the difficulty would be centered around a balanced build, i.e 8-8-8. Still, you wouldn't want to make it completely impossible if you choose to keep a stat at 1. Using AoL as a base:

 

Level 1 Attack - Have fun trying to get 96 hits off on Barba and Thunderbird; leveling up is going to be a chore.

Level 1 Magic - Every spell after Fairy costs 120 MP, meaning even with full Magic, just barely grazing a Bubble locks you out of half your spells.

Level 1 Life - Most enemies can 2-3 hit kill you without Shield. Taking a single hit means needing the Life spell.

 

Still, your concept sounds pretty solid.

[Jamian]

You could script the item pick up rooms easily by having a local ffc script which creates the three items, then checks every frame for the number of items in the room. Once it detects there is one less item (when the player picked something up), it removes the other two and triggers a screen flag so the items won't reappear when you reenter.

Edited by Jamian, 23 January 2016 - 10:48 AM.

[Timelord]

You should be able to draw the sword number, and magic number, with a simple trick: Make a number of swords, one for each level, equal to the maximum sword stat level that you want. For each, set the counter ref to a script counter, and set the increase counter to 1, and counter max to whatever your cap is.
 
Then, on the subscreen, make a counter object, and display the script counter that you want.
 
You can do a similar trick for other level-based items, where you wish to display the item level.
 
Note: You can use counters CR_SCRIPT* without actually using scripts. They work with counter refs as-is, out of the box.

Of course, it's far easier to do this with scripts, and you won't waste 24 items to have 24 'levels' You need only one item of any given type, then you read the item power, and display that value with DrawInteger() to the subscreen.

Then, to increase the level, you load the itemdata for it, and write to its power. This will make it more powerful (without changing what it triggers), and simultaneously affect the scripted display. If you need to affect more triggers, you can make a tiny pickup script for the level-x sword, or what have you that copies the power from the next lowest sword owned, to the new sword. (This is only needed if you have sword-specific triggers.)
 
Of course, you can make the other swords into other things, such as axes, or staves, and trigger things with them, while maintaining independent power levels for each.
 
For drawing bars using percentages, the maths above are wrong. Here are some examples that I typed out of me head, to be applicable here:

const float GAUGE_PIXELS_PERCENT = 1.0000;
const int GAUGE_PIXEL_WIDTH = 100;
const int GAUGE_HP_STARTX = 40;
const int GAUGE_HP_STARTY = -24;
const int GAUGE_HP_HEIGHT = 8;
const int GAUGE_HP_COLOUR = 0x81;
const int GAUGE_MP_STARTX = 40;
const int GAUGE_MP_STARTY = -12;
const int GAUGE_MP_HEIGHT = 8;
const int GAUGE_MP_COLOUR = 0x21;

void DrawCounters(){
    Screen->Rectangle(7, GAUGE_HP_STARTX, GAUGE_HP_STARTY, GAUGE_HP_STARTX+GAUGE_HP_HEIGHT, GAUGE_HP_STARTY + ( (GAUGE_PIXEL_WIDTH/Link->MaxHP) * Link->HP ), GAUGE_HP_COLOUR, -1, 0, 0, 0, true, OP_OPAQUE);
    Screen->Rectangle(7, GAUGE_MP_STARTX, GAUGE_MP_STARTY, GAUGE_MP_STARTX+GAUGE_MP_HEIGHT, GAUGE_MP_STARTY + ( (GAUGE_PIXEL_WIDTH/Link->MaxMP) * Link->MP ), GAUGE_MP_COLOUR, -1, 0, 0, 0, true, OP_OPAQUE);
}

You want something more like that.

If you want to draw a box of a specific size as an outline, and then fill it, you can do that too, but it's slightly different:
 

const int GAUGE_HP_STARTX = 40;
const int GAUGE_HP_STARTY = -24;
const int GAUGE_HP_HEIGHT = 8;
const int GAUGE_HP_COLOUR = 0x81; //Classic Red, CSet 8, colour 01.
const int GAUGE_MP_STARTX = 40;
const int GAUGE_MP_STARTY = -12;
const int GAUGE_MP_HEIGHT = 8;
const int GAUGE_MP_COLOUR = 0x21; //Classic Green, CSet 2, colour 01.

const int GAUGE_PIXEL_WIDTH = 80;

const int GAUGE_OUTLINE_COLOUR = 0x01; //Classic White, CSet 0, Colour 01

void DrawGaugesWithOutline(){

    Screen->Rectangle(7, GAUGE_HP_STARTX-1, GAUGE_HP_STARTY-1, GAUGE_HP_STARTX+GAUGE_HP_HEIGHT+1, GAUGE_HP_STARTY + GAUGE_PIXEL_WIDTH +1, GAUGE_OUTLINE_COLOUR, -1, 0, 0, 0, false, OP_OPAQUE);
    Screen->Rectangle(7, GAUGE_MP_STARTX-1, GAUGE_MP_STARTY-1, GAUGE_MP_STARTX+GAUGE_MP_HEIGHT+1, GAUGE_MP_STARTY + GAUGE_PIXEL_WIDTH +1, GAUGE_OUTLINE_COLOUR, -1, 0, 0, 0, false, OP_OPAQUE);
    Screen->Rectangle(7, GAUGE_HP_STARTX, GAUGE_HP_STARTY, GAUGE_HP_STARTX+GAUGE_HP_HEIGHT, GAUGE_HP_STARTY + ( (GAUGE_PIXEL_WIDTH/Link->MaxHP) * Link->HP ), GAUGE_HP_COLOUR, -1, 0, 0, 0, true, OP_OPAQUE);
    Screen->Rectangle(7, GAUGE_MP_STARTX, GAUGE_MP_STARTY, GAUGE_MP_STARTX+GAUGE_MP_HEIGHT, GAUGE_MP_STARTY + ( (GAUGE_PIXEL_WIDTH/Link->MaxMP) * Link->MP ), GAUGE_MP_COLOUR, -1, 0, 0, 0, true, OP_OPAQUE);
}

If you want the area of used MP/HP (e.g. damage) to show as another colour, and not black, you do this:

const int GAUGE_HP_STARTX = 40;
const int GAUGE_HP_STARTY = -24;
const int GAUGE_HP_HEIGHT = 8;
const int GAUGE_HP_COLOUR = 0x81; //Classic Red, CSet 8, colour 01.
const int GAUGE_MP_STARTX = 40;
const int GAUGE_MP_STARTY = -12;
const int GAUGE_MP_HEIGHT = 8;
const int GAUGE_MP_COLOUR = 0x21; //Classic Green, CSet 2, colour 01.
const int GAUGE_HP_BG_COLOUR = 0x55; //Classic Brown, Cset 5, colour 05.
const int GAUGE_MP_BG_COLOUR = 0x72; //Classic Blue, Cset 7, colour 02.

const int GAUGE_PIXEL_WIDTH = 80;

const int GAUGE_OUTLINE_COLOUR = 0x01; //Classic White, CSet 0, Colour 01

void DrawGaugesWithOutline(){

    Screen->Rectangle(7, GAUGE_HP_STARTX-1, GAUGE_HP_STARTY-1, GAUGE_HP_STARTX+GAUGE_HP_HEIGHT+1, GAUGE_HP_STARTY + GAUGE_PIXEL_WIDTH +1, GAUGE_OUTLINE_COLOUR, -1, 0, 0, 0, false, OP_OPAQUE);
    Screen->Rectangle(7, GAUGE_MP_STARTX-1, GAUGE_MP_STARTY-1, GAUGE_MP_STARTX+GAUGE_MP_HEIGHT+1, GAUGE_MP_STARTY + GAUGE_PIXEL_WIDTH +1, GAUGE_OUTLINE_COLOUR, -1, 0, 0, 0, false, OP_OPAQUE);
    Screen->Rectangle(7, GAUGE_HP_STARTX, GAUGE_HP_STARTY, GAUGE_HP_STARTX+GAUGE_HP_HEIGHT, GAUGE_HP_STARTY + GAUGE_PIXEL_WIDTH, GAUGE_HP_BG_COLOUR, -1, 0, 0, 0, true, OP_OPAQUE);
    Screen->Rectangle(7, GAUGE_MP_STARTX, GAUGE_MP_STARTY, GAUGE_MP_STARTX+GAUGE_MP_HEIGHT, GAUGE_MP_STARTY + GAUGE_PIXEL_WIDTH, GAUGE_MP_BG_COLOUR, -1, 0, 0, 0, true, OP_OPAQUE);
    
    Screen->Rectangle(7, GAUGE_HP_STARTX, GAUGE_HP_STARTY, GAUGE_HP_STARTX+GAUGE_HP_HEIGHT, GAUGE_HP_STARTY + ( (GAUGE_PIXEL_WIDTH/Link->MaxHP) * Link->HP ), GAUGE_HP_COLOUR, -1, 0, 0, 0, true, OP_OPAQUE);
    Screen->Rectangle(7, GAUGE_MP_STARTX, GAUGE_MP_STARTY, GAUGE_MP_STARTX+GAUGE_MP_HEIGHT, GAUGE_MP_STARTY + ( (GAUGE_PIXEL_WIDTH/Link->MaxMP) * Link->MP ), GAUGE_MP_COLOUR, -1, 0, 0, 0, true, OP_OPAQUE);
}

All the sizes, coordinate positions, and colours here, are set by the constants, so that you may easily change them. The colours are in hexadecimal format to match the CSet table format. Call the function before Waitdraw() in the main infinite ( while(true) ) loop in your global active script.
 
You can similarly use DrawInteger() to draw levels to the HP & MP bars. Store the levels in a counter, or an array, and change the formula for displaying the amount used to be modified by that value too, or just increase Link's HP and MP by whatever a 1x factor would be, each time; however you want those levels to work.

Edited by ZoriaRPG, 25 January 2016 - 03:38 AM.

[Nathaniel]

If it was up to me to decide how powerful each rating would be, to keep a proper balance with how ZC normally does things from weakest to strongest, this is what I would consider, assuming you stick to the 1 to 8 ratings.

 

Attack:

1 - equal to Sword

2 - 50% more damage than Sword

3 - equal to White Sword

4 - 50% more damage than White Sword

5 - equal to Magical Sword

6 and 7 - something better than Magical Sword, but less powerful than ZC's Master Sword

8 - equal to ZC's Master Sword

9 or above, if used - relatively less significant improvements

 

Life:

1 - equal to starting protection

2 - 50% more protection

3 - equal to Blue Ring

4 - 50% more protection than Blue Ring

5 - equal to Red Ring

6 and 7 - something better than Red Ring, but worse than Gold Ring

8 - equal to Gold Ring

9 or above, if used - relatively less significant improvements

 

Magic: I'm not sure where to go with this one.  It would probably take a lot of scripting to implement spells similar to the Adventure of Link, which has arbitrarily decided magic costs for each spell at specific skill ratings.  If there was a life spell though, you'd have to make sure that the magic cost is never less than the amount of life it gives back (thus why it never went below 50 in AoL, where a value of 48 = 3 bars of life).

 

So upgrades give less dramatic changes, since there are more of them.  Anything more would be overkill and make even the hardest parts of most quests pretty easy, unless you give later enemies much higher amounts of life.  But if you wanted to upgrade one area more at the sacrifice of going less in another area, it should be considered a risk or even a certain kind of challenge, with upgrades beyond a score of 8 being less significant.

[justin]

For drawing bars using percentages, the maths above are wrong. 

 

how about you enlighten me as to how my math is wrong? both our formulas get the same results no matter what numbers I toss at them. so unless it comes down to some bizarre zscript behaviour regarding division i think both work just fine. in fact, i know mine does because i've used it in a quest i was making.

 

here's an example of mine in action:

[Timelord]

how about you enlighten me as to how my math is wrong? both our formulas get the same results no matter what numbers I toss at them. so unless it comes down to some bizarre zscript behaviour regarding division i think both work just fine. in fact, i know mine does because i've used it in a quest i was making.
 
here's an example of mine in action:

 

 

Your maths would work as a percentage ( ( x / y ) * 100 ), but you didn't express them as such.

 

27+42*(Link->HP/Link->MaxHP) is not a percentage, it's a ratio.
 
I put up code for percentage-based effects (see DrawCounters() ), and I put up specific sized/ratio code too. Have a look at them. You would set GAUGE_PIXEL_WIDTH = 100 to use percentage-based drawing.
 
100/factor * avail
 
That yields the percentage of 'factor' that 'avail' covers, converting fractions to raw percentages. i.e., the percentage of 'factor' for 'avail'.
 
This works well for drawing metres for enemy/boss health, and such, if you want a percentile-based display for them. (That allows drawing the HP of any enemy to the same general scale.) It would also work for drawing any other sort of gauge, but usually people will want to fix the size of an object first, which is why ratios are often used, instead.
 
In the example that uses percentages, I added a drawing modifier, to size the box. It draws the box in a number of pixels per percentage point via a float value. Thus, if you have a float value of 0.5, and 43%, it draws a box that is 22 pixels in size (because I forgot to floor it; it should be 21). Thus, it is scaled around the percentage.
 
The others ( both variants of DrawGaugesWithOutline() ) use a ratio method, with a fixed size predetermined, which is what you did. The maths are the same, in those two, save that I implemented the equation a bit differently.
 

I'm not sure what you are doing with DrawTile() either, unless you are drawing the gauge with tiles for some reason. THat to me, seems redundant, if you are going to draw it with scripted commands, unless you want a pattern. Even so, it'd be a huge pain to scale those around a desired outcome, unless you use actual tile scaling. That would be interesting, as you could make one tile that is a gradient, and scale it on a single axis, to stretch it into whatever size you wish.

 

The yscale arg is a int, that works as a percentage, so you can just toss the percentage derived from the equation into that.

 

P.S. I used something similar to the functions above for the Stamina Gauge in the LBW Item Rental Header. You have that file, if you want to reference it; but I do not recall which way I went with it there. It might be better, or not as good as what i tossed together purely for this thread.

 

I'm going to need to experiment with using DrawTile() this way, for gradients though.

Edited by ZoriaRPG, 25 January 2016 - 04:27 AM.

[justin]

I'm not sure what you are doing with DrawTile() either, unless you are drawing the gauge with tiles for some reason. THat to me, seems redundant, if you are going to draw it with scripted commands, unless you want a pattern. 

 

the drawtile is drawing the border over top.

 

See the picture I posted as an example, I thought the pic was worth the words, alas.

The ratio based meters are drawn with the DrawRectangle, and the tile border is drawn overtop. The tile borders look way better than an outline in my opinion, and would be tedious to draw with scripted Draw commands.

[Timelord]

See the picture I posted as an example, I thought the pic was worth the words, alas.
The ratio based meters are drawn with the DrawRectangle, and the tile border is drawn overtop. The tile borders look way better than an outline in my opinion, and would be tedious to draw with scripted Draw commands.

Ah, I thought those were just graphics on the subscreen design. ... I see what you did there. (You wanted rounded corners.)

The thing with DrawTile() , normally, is that it fixes you to a size in pixels that is a multiplication factor of 16. Then again, the scale args can mitigate that,

Sorry though if you thought I was complaining about the equation in general. I should have been clearer that in my original response, that the equation didn't produce a proper percentage, although it does otherwise work. I really have no idea if when the Op asked for a 'percentage', he was literal. (I tend to be, as it is specific, and occasionally mandatory.)

Now I need to become accustomed to your new username: I looked at the page, and said 'What?!' when I read the quote, and saw the username.