Just saying, but of course it would've been possible to use the tiles you've drawn instead of rectangles if you really wanted. Screen->FastTile() lets you draw tiles from the tile page.
/**
* Optimized and simpler version of DrawTile()
* Draws a single tile on the current screen much in the same way as DrawTile().
* See DrawTile() for an explanation on what these arguments do.
*/
void FastTile( int layer, int x, int y, int tile, int cset, int opacity );
Your script would have to be rewritten though.
If the colours of the metres are CSet based, FastCombo allows you to cheat some free tile space too. I've actually managed to run ZC out of free tile pages in the past.
I'm going to put in some paragraph formatting in the quote, Binx, I think PZC gobbled it...
Meh, I already finished the subscreen, anyways, so no big deal, it's perfectly passable.
I'm not sure what you mean by me needing the counters for in-game functions. There are 25 script counters, I'm only using 15 of them, so I still have 10 left over for other things. I used counters because it's an easy way to track the various meters. As far as the coinage is concerned, they're not different currencies for different regions, but like you said, follow AD&D rules: 1 gold piece is worth 10 silver, and 1 silver piece is worth 10 copper.
I quite literally ran out, using them to track stats, afflictions, and other goodies. A single array can work in exactly the same way, and doesn't use any in-built space that I may want for something that requires it later.
As an anecdote, in the original D&D, and AD&D, the exchange rate was not 10:1, 10:1, 1:1; it was 12:1, 20:1, 1:1, just like the proper old pence, and shillings. Thus, 240 pence to the sovereign, or 12 pence to a shilling, or 20 shillings to a sovereign.
You're certainly going to need banking systems, and custom shopkeeps that will change up coins, and you may want to do what i did, and include a message on an item pickup script, if the player has no free space, as the counter values aren't summing their free space at present, merely the value of the objects, and when the counters cease to increase, a player will undoubtedly be left confused, and think the game is broken; as we both know that people here love to read instructions before trying a game.
I was going to try to add a function to split the space in any wallet so that if you have, say the 999 rupee wallet, you can have 999 coins, but once you reach 999, you can't carry anymore coins of any kind, so you could end up with 54 gold, 338 silver and 607 copper, any you'd be maxed out, but if you spent all the copper, and replaced it with gold, you'd still have 999 coins, but they'd be worth more. The meat, ale and bread I totally disagree about. They're active items that you have to consciously consume, so they need counters so that you can keep up a stock.
I didn't even notice a 'food' counter. I was talking about the stamina gauge itself... If it was always hovering near the player, and shifted colours when it ran down, they would be more conscious of it than on the subscreen. Shocking, I know, but people don't pay much attention to the passive subscreen while playing.
Watch some LPs, and learn the basic mindset, as I constantly see people go out of their way to pick up items that can;t even hold, fo frequently, that I made it a point to add an array in LoE to hold the value of each object a player picks up that they cannot carry ( UselessItems[] ) so that at the end of the game, I can display it with a string, as Z3 did with enemy kills.
Money
I wouldn't tie how much a person can carry to coin value at all. From any standpoint, that makes no sense. Make it 999 max coins, of any summed value. If your base coinage is silver, with 1sp = 1 rupee, that would be a wallet capacity of 9,990 rupees, but if gold is hard to find--not a random drop--it limits grinding by making it unprofitable.
In other words, you can use an inbuilt counter to track up to 999 objects, and if that counter is maxed, the pick-up script on an item refuses to add it to a counter. That's close to what I did, save that it doesn't permit fractional space, but it will require a pick-up script for money, rather than just using the item editor counter increase field.
Doing it this way is more complex, but far more realistic; and I've never seen any RPG where a player couldn't put a 20,000 gold gem in their pocket because it was worth too much; although I know few players foolish enough to do it, unless they want to be the latest marks.
You'll want to avoid any spillover problems, and you'll need functions that auto-tally for shoppes, but aye, my method is somewhat different, and you have all the ingredients you need to do something that is just as effective, in another manner, but it requires scrapping many ZC models. How would a person spend 1/10 rupee, with the in-built shoppes? They can't, and if 1cp is 1/10 of the basic money unit, you need to account for that.
This is why I say, use a float array, because that can be a proper-pretend-float, and you can write out its value to a counter by converting the ZC-float of the summed total, to a ZC-int, and print that value out on the screen, whether by means of copying it to a counter, or with draw commands. Otherwise, you're going to need to base all your prices around the cp, and you'll run into large numbers that ZC can't handle as ints.
My money objects store their size in an array, and the 'free space' value in that array is mirrored to a counter so that I can put it on the active subscreen. That's the only spot in the entire game to which you can't directly draw, and the place for where I've reserved counters, although at this stage, I mayn't use it; but I need to reserve it so that other people may use it for the sake of simplicity.
But, I did take their icons off the subscreen. but that still leaves me with the problem of where I *am* going to draw counters for active items like the food, bombs and arrows, since their icons don't fit. Like I said earlier, if I can draw the counter over the "B" button item,and still have it always show the right counter, or nothing if the item doesn't use a counter (like how counter-based items are handled in later games, like in OoT and later, you didn't have a counter on the HUD for bombs or arrows, the counter was laid over the item sprite), that will make my subscreen pretty much perfect, in my eyes.
As to drawing:
Screen->DrawInteger
This allows you to put the value stored in an array, or a counter as an int, onto the screen, wherever you desire. It needn't be in the passive subscreen field at all. You can easily store, update, and draw it every frame. You can have it follow the player around, if you desire. My point, i suppose, is that if you use a draw function to place the value, you don;t need a counter. If you want it on the in-built active subscreen, then and only then, is a counter mandatory.
I put the stamina bar between the health and magic meters specifically because I don't want people to miss it. It's right between the two meters everyone keeps their eyes on. Right now, the biggest issues I can think of are: "What is a fair drain rate?" and "what should I set for the initial random roll?" because 3d6 is just too low to be anything but crippling if the player gets a bad roll (I rolled a 3 on my first test), and even a good roll isn't very nice. I changed the roll to 10D6, but I worry that 60 Stamina might be a bit much to start. I mean, going the Ultima route and making you consume food with every step is freaking ridiculous, but I definitely want food to play a major roll (get it? cuz a roll is a type of food, and this is a role-playing game. It's a pun!), since if you don't eat in real life, you die.
...
I've always had a simple philosophy: Roll a character, and play it, with all the imperfections intact, but in a video game, people will simply cheat at the start, and make multiple characters until they have one that is 'perfect'. That's precisely why I pegged all starting stats at 10, and made increases occur after X levels. Once a player has an investment in a character, they won't want to start over.
You may want to put in a sound when the player is very low on stamina too.
As to a fair drain rate, slave it to a day and night cycle. I'm assuming here that you have day and night in your game world, so every day and night without food should shave off a huge slice of stamina, and maybe some stat damage after a while too. If you want to become inventive, make stamina a float, make every swing of a sword slice off .0010 stamina, and convert the raw factor back to an int later, so that players who run around like mad dogs, batting at everything, tire out the PC.
The drain will rack up over time, without being drastic. That's the value of being able to store the proper and true value as a float, and put the integer portion in a counter, or what-have-you. Pure magic.
Edited by ZoriaRPG, 17 May 2015 - 12:58 PM.
