LBPCentral Archive

Home

LittleBigPlanet 2 - 3 - Vita - Karting

LittleBigPlanet 2

[LBP2] Help!

"Fun" with counters.

Archive: 53 posts

I want to start working on an idea I have for a series of RPG levels.

Without getting into the nitty-gritty of the mechanics of my idea, I want the player to have four distinct stats, one of which being HP, which can go from 1 up to 99. The best way I can think to keep track of that is with counters.

Before I've even started on it though, I'm noticing a problem. There's no way to tell how full a counter is, only whether it's completely full or not. So there'd be no way to, for instance, display how much damage an attack does. The player would just have to eyeball it based on what percentage of their HP bar depleted. Or, for something more directly important mechanically, damage should be a function of the attack power of the attacker and the defense power of the defender, but there's no way to check those values.

The best solution I have to this is to make each stat counter actually a linked series of 99 counters, each with a max count of 1, and have all of them be activated by an AND switch which requires both the input action and for the previous counter to be full.

This is suboptimal to say the least. I haven't worked out all of the rest of the logic yet, but I have a feeling that it would mean a lot of the other logic gates would require 99 inputs, and that strikes me as something that could get messy fast. I have no idea how much thermo this would eat up, but this level is gonna be pretty extensive and thermo's gonna be at a premium, so if a more efficient solution exists it would definitely be preferable.

I could very well not even need it to go up to 99, and in the first level or so in the set I almost definitely won't. The "right" way to do things to me though would seem to be making the system identical for every level.

2011-02-14 19:49:00

Author:
Speed Racer

Posts: 156

This is an issue that a lot of people have run into. Another method is to use an 7-bit register. The binary representation of 100 or less can be represented in 7 bits. However, you still end up with 7 wires going to everything and you run into all kinds of interesting things such as how to set values. You can use the analog signal though, as you can do math on it as well. It' s a little funky but it minimizes the wiring. You can get your start with RTM's excellent blog here (http://www.lbpcentral.com/forums/entry.php?2106-Analogue-Logic-Notation&goto=prev)

2011-02-14 19:59:00

Author:
Shanghaidilly

Posts: 153

The term "7-bit register" sounds terrifying.

I'll give that blog a read though! 7 wires sure beats the heck out of 99!

2011-02-14 20:07:00

Author:
Speed Racer

Posts: 156

If you've never faced any real-world electronics, let me tell you, it is terrifying.

Had a class at uni where we were tasked with building a simulated CPU. Making the registers was... not fun. Still, once we had one we could use it for all our registry needs, so there's that.

Don't get me started on ALUs and pipelining, though. I still occasionally have nightmares, and it was in 1999.

2011-02-14 22:16:00

Author:
Unknown User

You CAN get a reading from a counter or timer other than an ON/OFF. Any device that can read an analog signal will read the percentage of the count: a counter with a max of four with a current count of one will output 25%. It can be difficult to accomplish something meaningful with an analog output, but if you wire it into a sequencer and set it to positional, you can have things triggered at whatever percentage you want. You could build a sequencer 99 batteries across and 99 bits of hologram to display every individual health tick. That would be a pain and 99 bits of holo would start to cause lag even if they're invisible, but it's theoretically possible

2011-02-15 05:18:00

Author:
Sehven

Posts: 2188

Yeah I just got to the ADC stuff on that logic blog. That seems like a good avenue to explore here.

What would really be great though is if it were somehow possible to have a counter hooked to a positional sequencer, and have the output of the sequencer somehow tell another counter to set its count to a specific number. That seems much cleaner than 99 bits of holo, especially when you consider that for, say, a status screen for your whole party, you'd be looking at 99 pieces of holo x 4 stats x 3+ party members, which works out to a minimum of 1,188 hologram "pixels!" I'm gonna go ahead and call a number that big unacceptable.

I think I'm starting to grasp at a way to make a counter display any number I want it to at a given time, but I think it'll take a lot of logic. What would really be nice is if the counter could interpret analogue signals.

2011-02-15 06:03:00

Author:
Speed Racer

Posts: 156

okay wait, maybe I'm onto something here.

for now I'm thinking purely of HP bars. What if they're represented by timers instead of counters. The max time represents your max HP. At the start of the battle they're full. The amount of damage you take is somehow translated into a battery which powers the timer, allowing it to tick down for a number of seconds equal to the number of hit points you lose.

I think that would work, but thinking about it it seems like it runs into the same problem of getting messy. You would need 99 different timers all capable of powering the battery that turns the HP bar timer on and off, each one set for one second longer than the one before it, and the easiest way I can think of to translate the difference of attack - defense would be a sequencer with 99 batteries. Healing would work the exact same way, except it would instead power a battery set to -100.

Still, it does seem like it'd be logically sound, and at the very least it'd be a step above the 99 pieces of hologram. It also seems like something that could potentially be reusable. You could use the same mechanism for your whole party by having AND gates hooked to their HP bars, with both a battery and some sort of logic indicating that they're the ones taking damage.

The only point where this becomes difficult is that the player's max HP needs to increase as they level up. That might be fairly simple too, though. You could have their "actual" HP bar go all the way to whatever time is set as equivalent to 99 HP, but have it decrease to the player's current max HP whenever it's convenient and set something else up in the logic to keep it from surpassing that value. Then just emit a "nominal" HP bar which has the player's current max HP set as its max time. It wouldn't actually control anything, it'd just be a cleaner visual representation of your health.

The other stats could be handled similarly but much more easily. attack and defense and the like generally don't change that much in battle, and you don't need a constant visual representation of them. I haven't looked at the multiplication and division stuff yet but that might be a good way to do buffs and debuffs, since I'm assuming it would leave the original analogue output alone.

I can't be sure without actually having the game in front of me to test, but this sounds like it would all work. It's just a question of how thermo-consuming it would be.

I don't suppose there's any way to transmit info across levels other than through score, is there? The more I think this through the more concerned I am for my poor thermometer, and it'd be awesome if triggering a battle sent you through a level link. Between the stats of three party members, and determining what types of enemies to emit though, having every possible combination of thing be tied to a specific score value seems like it'd be a nightmare, and then there'd be the issue of level-linking back to the overworld at the same position you left it at. It just sounds like a really hairy thing. Who knows though, maybe I'm greatly overestimating the amount of thermometer all of this logic will eat up.

2011-02-15 07:18:00

Author:
Speed Racer

Posts: 156

Timers actually make good health bars. Let's look at a 3 second timer. Considering that a single clock tick is .033 sec. a 3 second timer can store 100 clock ticks of an analog signal strength of 100. So to count down by 1 HP, just send a -100% signal for 1 clock tick (to a timer set for forward/backwards input). Now here's where it get's interesting. If you only send an analog signal of 50, you've essentially doubled your health bar. So by varying the analog input to the timer, you can adjust how many "ticks" the health bar contains. There's your modifiable health bar.

I haven't tested to see how granular you can get with the engine and timers. In other words, if I was to send an analog 1 signal to a 3 second clock, would it really take 10,000 clock ticks to fill the bar (five minutes)? You might want to play around with this.

2011-02-15 14:40:00

Author:
Shanghaidilly

Posts: 153

By extension, if you want a health bar that can be scaled up during the game, you can send a two-clock-tick pulse to a 6 second timer until you decide it's time to double your health and then you can change it to a one tick pulse. Or you can destroy the timer and emit a new one for the later health. This stuff can be kinda' complicated to built just right, but I think it's quite a bit simpler than what you're thinking: you can get by with a single timer for your health bar--you don't need 99 little timers or a second big timer to display the health. One timer is all you need.

I did a tech demo in the beta and I was able to add/subtract specific amounts to the health bar and I had it rigged to slowly regenerate. It's also possible to rig it to receive multiple hits of different amounts of damage and have them stack (so one hit doesn't block it from receiving another hit). There's been a handful of threads about timers as health bars--do a search and it should give you some enlightening results.

2011-02-15 15:49:00

Author:
Sehven

Posts: 2188

oh, man, yeah that's a much cleaner solution than what I was suggesting.

Just to be clear, you're saying I should have a bunch of different batteries set to a bunch of different analogue signals, each one triggered by the player being at a different "level," so that a pulse takes out a different proportion of the timer depending on how much max HP you have?

If I'm understanding it right that'll require 99 batteries on a sequencer, 99 timers, and 99 batteries on microchips. seems like a lot! But it definitely sounds like it'd work way better than my idea of filling the timer and then emptying it by the inverse of your HP stat.

2011-02-15 15:58:00

Author:
Speed Racer

Posts: 156

whoops didn't see your post sehven.

By extension, if you want a health bar that can be scaled up during the game, you can send a two-clock-tick pulse to a 6 second timer until you decide it's time to double your health and then you can change it to a one tick pulse. Or you can destroy the timer and emit a new one for the later health. This stuff can be kinda' complicated to built just right, but I think it's quite a bit simpler than what you're thinking: you can get by with a single timer for your health bar--you don't need 99 little timers or a second big timer to display the health. One timer is all you need.

I did a tech demo in the beta and I was able to add/subtract specific amounts to the health bar and I had it rigged to slowly regenerate. It's also possible to rig it to receive multiple hits of different amounts of damage and have them stack (so one hit doesn't block it from receiving another hit). There's been a handful of threads about timers as health bars--do a search and it should give you some enlightening results.

The 99 little timers would be so that an attack could deal any amount of damage from 0 to 99. when an attack is performed, a subtraction operation will be performed to get Attacker's Attack minus Defender's Defense. Then that number will be stuck into a positional sequencer that has 99 batteries, each of which is set up to a different timer, which starts a countdown to turn a battery on to let the timer drain the appropriate amount of time. The power of the battery would be set to the percentage of the timer that I want to constitute 1 HP, and the timer that powers the battery would last for the number of clock ticks equal to the amount of damage dealt multiplied by the length of one clock tick.

Or I guess you wouldn't even need to directly use clock ticks, and you might not want to because it would mean that you could only deal damage that's a multiple of three. You could just as easily use the .1 second minimum instead of .03. You could do it with pulses but unless I'm missing something you can't send multiple pulses with only one piece of logic.

Unless I'm misunderstanding your suggestion it wouldn't provide the amount of granularity I need. The HP stat needs to be anywhere between 1 and 99, and attacks need to be able to deal anywhere between 1 and 99 damage. You're right about the "display" timer no longer being necessary though.

2011-02-15 16:08:00

Author:
Speed Racer

Posts: 156

Or I guess you wouldn't even need to directly use clock ticks, and you might not want to because it would mean that you could only deal damage that's a multiple of three. You could just as easily use the .1 second minimum instead of .03. You could do it with pulses but unless I'm missing something you can't send multiple pulses with only one piece of logic.

You can easily send how many pulses you want with a single piece of logic. It just loops until a counter hits the number you want, then it stops. And yes, if your pulse generator is using a .1 second timer, everything is base 10. Any idea for how long the signal presented when an impact or similar sensor is triggered? It could lead to some interesting damage accumulation circuitry.

I may see how devastating my 7-bit register is to thermo. As many people have asked for health bars, it might just be easier to convert it to digital and do it that way. Since I have an analog register as well, I can accumulate damage for let's say .1 seconds and then apply it to the Health bar at that interval. This could allow for multiple damages of different levels every .1 seconds. I just don't know if I want to invest the time.

2011-02-15 19:25:00

Author:
Shanghaidilly

Posts: 153

Just so we're clear, the pulse generator you're suggesting is a NOT gate hooked to a counter, which is triggered by an AND gate that has the counter and the NOT gate as its inputs right?

That would work I s'pose, but the only advantage I'm seeing is that you can make things happen a little faster, when speed isn't something I'm especially concerned with I don't think. Unless, again, I'm missing something, which is totally possible since I just got introduced to all this analogue signal and advanced logic stuff yesterday.

2011-02-15 20:36:00

Author:
Speed Racer

Posts: 156

Yes, you have the design correct. (Funny, I just looked up mine and it's exactly as you described).

You'll have to determine how quickly you need to update your health bar depending on the frequency of the damage coming in. As long as you don't have multiple damages that could occur at the same time and at a frequency greater than your update of the health bar, your good.

2011-02-15 20:45:00

Author:
Shanghaidilly

Posts: 153

Combat's going to be completely turn-based, so multiple sources of damage won't be possible.

So, sounds like I have the basic idea down!

No to hunker down and actually make it. @_@

One quick note of clarification about something. Tag sensors have a "signal strength" option. I'm guessing that that means that it outputs an analogue signal that's the same value as the analogue input of the corresponding tag, is that correct? Because if so that makes this so much easier.

2011-02-15 20:51:00

Author:
Speed Racer

Posts: 156

One quick note of clarification about something. Tag sensors have a "signal strength" option. I'm guessing that that means that it outputs an analogue signal that's the same value as the analogue input of the corresponding tag, is that correct? Because if so that makes this so much easier.

You got it. Now go have "Fun" with counters

2011-02-15 21:26:00

Author:
Shanghaidilly

Posts: 153

You got it. Now go have "Fun" with counters

http://www.youtube.com/watch?v=oShTJ90fC34

Oh, here's something. It has absolutely nothing to do with the rest of this but I figured it'd be better to just ask here instead of cluttering up the forum with a dumb question!

Is there a way to make some sort of light that points "away" from the viewer? Like as though the light source were from behind the camera? Part of my idea presentation-wise could be really helped by being able to shine a spotlight dead onto the characters, but I'm pretty sure it's impossible to do. If it is I can just make due with spotlights shined down from the sides.

2011-02-15 22:04:00

Author:
Speed Racer

Posts: 156

Bahhhhh, a big problem with this concept dawned on me while stringing all these timers and batteries together.

So, just to be clear, lemme reiterate the damage system. A subtraction function is performed to determine Attacker's Attack - Defender's Defense. This number gets plugged into a positional sequencer that has 101 batteries on it, 0-100. batteries 1-100 are each linked to a timer that's one second longer than the one before it, and all 100 timers are hooked into the same OR gate. The OR gate is linked to 100 different AND gates, each of which turns on a microchip with a battery in it set to a different percentage. The other condition of the AND gate would be met when the player's HP stat matches the battery that will properly divide the HP bar into a number of segments equal to the HP stat. So, the 1% battery is turned on when you have 100 max HP, for instance, to guarantee that 1 second knocks off one HP.

Herein lies the problem. Each of the batteries in the second set needs to be the percentage of the max HP stat that is equal to one point. Using 100 again because it's easy, 1 point is 1% of 100, so the battery used at 100 max HP is set to 1%. The problem here, though, is that 1 is not a whole or sometimes even a rational percentage of a number. 1% means that you lose 1 HP per second when you have 100 max HP. 2% would mean that you lose 1 HP per second when you have 50 max HP. So, by definition, the correct setting for the battery for 51-99 are all going to be decimal values, and frequently irrational decimal values. The battery doesn't deal in decimal points, though.

Is there a way around this, or did I just find a fatal flaw in this method?

I'm fairly certain that I have, so I've gone on with a different idea. instead of 100 timers, I'll need 10 pulse generators, each one set to generate one more pulse than the previous one. They get activated by the 100 batteries on the sequencer (the 101st battery on the sequencer will be for when 0 damage is dealt, and will only cause a holographic 0 to emit). These send a signal to a tag, which is picked up by an emitted counter, which is the actual HP bar. As far as I can see, there's no way around emitting a different HP bar for every level-up, at least not without a prohibitively complicated logic sequence. Fortunately, this doesn't seem to be too thermo-consuming. to test it I placed 9 emitters each capable of emitting 100 pieces of holo with a counter and tag sensor on it (3 emitters for party members, and the other six to represent enemies, though they don't need to level up so that's absolutely overkill), and it didn't really make a noteworthy ding in the thermometer.

EDIT: Ah, but 400 emitters which are each capable of emitting a single piece of holo with a counter and a tag sensor on it makes the thermometer jump to just below the second tick. Which is still acceptable, but if someone can think of a cleaner method, I'd definitely like as much thermo as possible to devote to the aesthetics of the level.

even if there's not a way to do this that's easier, I can still see ways to decrease the number of HP counters that I'd need to emit. I want the player to be able to decide where to invest their level-up points, but I could very easily revoke that right on HP and just increase it by a set increment with each level, say by 3 or 5. That would cut down on the number of emitters required drastically, and also provide a reasonable number to set for my "max level."

2011-02-16 06:11:00

Author:
Speed Racer

Posts: 156

Is there a way around this, or did I just find a fatal flaw in this method?

If you're doing it with an analog system, you might find a combination of subtractors and signal sampling works better - again, read rtm's blog for details.

The approach I took for an HP bar which can be adjusted by arbitrary amounts was to do the whole thing digitally, using a combination of flip-flops and adders. It's more thermo-intensive, but faster and probably more accurate than any analog solution - can run as fast at 15 updates per second, which is as fast as any sensor would be capable of registering a hit.

2011-02-16 14:00:00

Author:
Aya042

Posts: 2870

Question: What sizes of health bars are you planning?

2011-02-16 16:41:00

Author:
Shanghaidilly

Posts: 153

Question: What sizes of health bars are you planning?

Well, I'm not fully sure. The bare minimum would probably be in the range of 10. For this first level, I don't see it cracking 25, and even that might be generous. I'm trying to keep the numbers small for my own ease and because before I even started I suspected that that would be make it less thermo-intensive. We probably won't be dealing with numbers in the 80s and 90s until the levels that never get made because I'll be bored of the concept by then.

I plan on doing a fairly extensive series of these things though, with the player's level being carried over by stickers earned at the end of the stage that you can then stick at the beginning of the next stage.

I suppose one very simple way to save thermo would be to decide the minimum and maximum level for a given part of the series, and work with the assumption that those are the only max HP values I need to concern myself with.

Aya, could you outline the basic idea of your digital system? I think I have a rough idea of how I could make it work digitally but I'm not certain, and even if I am it seems like it'd be an awful lot of logic.

2011-02-16 17:57:00

Author:
Speed Racer

Posts: 156

Well, I'm not fully sure. The bare minimum would probably be in the range of 10. For this first level, I don't see it cracking 25, and even that might be generous. I'm trying to keep the numbers small for my own ease and because before I even started I suspected that that would be make it less thermo-intensive. We probably won't be dealing with numbers in the 80s and 90s until the levels that never get made because I'll be bored of the concept by then.

Now to the next question: How many different variations of damage are you thinking of having to apply to the health bar? I ask because I'm already working on an analog to pulse count generator. So you could just hook a battery up to it set for the number of "Pulses" and it would generate that many. I already have it working off a counter, but that's a clumsy method of data input as it's integral to the circuitry. I was thinking this could easily be adapted to your damage system by decrementing (or incrementing) a simple counter.

2011-02-16 19:04:00

Author:
Shanghaidilly

Posts: 153

I have absolutely no idea how variable damage can be. Damage is gonna be the difference between two stats, and those stats could be anything.

For this first level though, ten is probably a reasonable guess at the absolute cap for the damage a single attack could do.

2011-02-16 19:10:00

Author:
Speed Racer

Posts: 156

Aya, could you outline the basic idea of your digital system? I think I have a rough idea of how I could make it work digitally but I'm not certain, and even if I am it seems like it'd be an awful lot of logic.

The basic idea is an 8-bit register feeding into one side of an 8-bit full adder. The output from the adder feeds back into the input of the register. You can then place an arbitrary value on the other input of the adder (which can also subtract by using two's complement math), and clock the register.

In one frame, it adds the new value onto the current value of the register, and stores it back in the register, takes one frame to settle, and can be reclocked on the following frame with another value, allowing it to run at 15Hz.

2011-02-16 19:15:00

Author:
Aya042

Posts: 2870

so if I'm understanding you right, you essentially start with an arbitrary number, and then can add or subtract an arbitrary value to/from it and then store the new sum or difference?

That's definitely cool, but I'm not sure it quite works for me. If I understand how it works correctly, I'd need a different register for every HP bar, and since there could hypothetically be 6 of those at once (3 party members and 3 enemies), it seems like it might be not quite for me, since you did mention that it does eat up a bit of thermo.

With my current system that has 99 batteries rigged to 99 pulse generators, it can draw a value from something simple like two counters used to represent attack and defense, and then output a number of pulses equal to the amount of damage taken, which can be wirelessly transmitted to the counters that serve as HP bars. I only need one iteration of the terrifying microchip.

Of course it's fully possible that I'm just not grasping what you're getting at.

2011-02-16 19:32:00

Author:
Speed Racer

Posts: 156

That's definitely cool, but I'm not sure it quite works for me. If I understand how it works correctly, I'd need a different register for every HP bar, and since there could hypothetically be 6 of those at once (3 party members and 3 enemies), it seems like it might be not quite for me, since you did mention that it does eat up a bit of thermo.

Well, excluding display logic, I can fit about 90 copies in a blank level before it overheats, although the design could be further optimized should a larger number be required.

2011-02-16 20:14:00

Author:
Aya042

Posts: 2870

I still think I'm gonna stick with the logic I've come up with, if only for the sake of stubbornly doing things my own way.

2011-02-16 20:17:00

Author:
Speed Racer

Posts: 156

But bottom line is... MM should add variables and it should also be possible to bring these variables along into linked levels.

2011-02-17 03:51:00

Author:
Discosmurf

Posts: 210

99 bits of holo would start to cause lag even if they're invisible
Not true, you should see some effects I have made with an insane amount of holo, it doesn't cause alot of lag (unless your in create then it can cause a bit, but they seem to have cleaned it up alot since the beta.

2011-02-17 05:37:00

Author:
fodawim

Posts: 363

Just a small update, the thing works like a charm! There's a small issue where it seems like some latency gets in there somewhere, making it so that if you try to jump from one position on the sequencer to another, the second pulse generator produces exactly one less pulse than what it's supposed to. However, setting the sequencer to 0 or 100, which are both blank spots, seems to reset the issue, so as long as you go from sequence position 1 to 0 or 100 to sequence position 2, it works correctly. It's a small annoyance but I've already got a number of possible workarounds in mind that would guarantee that the sequencer hits one of those numbers before accepting a new value to process.

Wait, something just occurred to me. could you put the pulse generators on the sequencer itself, instantly turning the analog signal into a discrete number of digital pulses? This is surprisingly low thermo (it fills about 1/3 of the bulb at the bottom), but doing that could cut the whole thing in half, and while I'm not certain because I don't totally understand how latency functions, it seems like it could possibly get rid of that latency problem too, just since there's less steps in the process.

On the other hand, having 200 wires in a single microchip caused a crazy amount of slowdown while actually wiring things together, and this took a long time. Do I really want to find out that there was a more efficient answer that renders all that time I spent pointless?

EDIT: Okay, some preliminary testing shows that it in fact does not remove the latency problem, so that potential benefit is out the window. Could someone with a little more understanding of how the thermo works help me out with how much I could save by consolidating everything onto the sequencer? It needs all the same components, it'd just be pressed down into the sequencer instead of being spread across the sequencer and a chip, so I'm thinking that it won't actually have that much of an affect on thermo cost. Still, I think it'd look much more tidy than the wire jungle my current version is. I'm just trying to weigh the time cost of redoing the whole thing vs. the potential benefits redoing it could have.

2011-02-17 07:14:00

Author:
Speed Racer

Posts: 156

Hmmm, I'm hitting a bit of a snag.

Like I said, the system to determine how much damage to deal works fine. Where I'm running into a problem is the system to decide whether to hurt or heal the player.

The idea I had was, the 99 microchips that I've explained plenty of times in this thread would determine the magnitude of the value sent to the health bar. Now I want another system to determine the sign of it, so that you could either add or subtract health.

Here's what I currently have. The sequencer with all the batteries and microchips his hooked up to two different AND gates. The second condition for the first AND gate is a tag sensor set to pick up when a tag labeled "heal" is activated. The second condition for the second AND gate is a tag sensor set to pick up when a tag labeled "hurt" is activated. The "heal" AND gate is hooked into the positive input of a direction combiner, and the "hurt" gate is hooked into the negative half of the same direction combiner. The direction combiner is then wired directly to my test health bar, which is set to 100 with a non-inverted output.

My understanding was that negative digital pulses would decrease a counter while positive digital pulses would increase it. However, the bar registers a +1 regardless of whether the pulse comes through the positive or the negative half of the combiner. What am I doing wrong?

EDIT: Nevermind, figured it out. Of course the answer was in the one detail I omitted: the test health bar isn't wired up directly, but is sent pulses wirelessly through a tag sensor. The sensor was set to closeness instead of strength, and so of course the sign of the value was being lost at that point.

2011-02-18 03:06:00

Author:
Speed Racer

Posts: 156

Alright gonna resurrect this thing because I have for no good reason decided to throw out the system I hammered out before that worked perfectly fine because I think I've got something that can work much faster, if some folks can help me iron out the bugs.

Earlier in this thread, someone suggested that I could have a single HP bar and scale the signal that was sent to it depending on how many points that bar is meant to represent. At the time, I dismissed that because I thought it would be too complicated. You'd have to figure out what percentage of a given max HP that any given signal is.

But now though I've read through all of rtm's blog and I get the idea of dividing and multiplying better, and this actually doesn't seem that hard. I seem to be hitting a few snags though.

Here's the basic idea. Every combatant has a counter from 1-33 that represents its HP stat.

http://i9.lbp.me/img/ft/0f96adf950227c7de55120e45ffdd0305e0b5c52.jpg

The stat can be any multiple of three from 3-99. When its designated as being attacked, it broadcasts the value of that counter to the damage processor. It's fed into a positional sequencer that has a battery at each of the 33 possible positions.

http://i4.lbp.me/img/ft/1f45f2cd9278b996ff05064c37b34344f0a35d40.jpg

Couldn't quite fit the whole sequencer into a screenshot, but you get the idea. There's no battery at the 3% mark because nothing will have only 3 HP.

Each of those batteries triggers a different sampler for one clock cycle. The timer is fed the analog value of the damage being dealt, but each timer is set to a different length, to divide by the correct amount of max health. So, for instance, the timer that activates at 45 health divides the damage signal by 135.

http://i7.lbp.me/img/ft/597315fcf76545323ea86b7405fcf482f361eee5.jpg

There's 32 of these things in total. The lit up wire is the analog signal that represents the number of damage I wanna deal. The green wire is the battery from the sequencer. The microchip to the right just has a node in it.

Then, the number is multiplied first by three and then by one hundred. The three is obvious; the one hundred is there because the game regards the analog signal as a percentage value already, so when you divide the damage by the max health you get a number that's one hundred times smaller than what you need.

http://if.lbp.me/img/ft/5dfe31479718713b333bfcc37d0986f5b4910656.jpg

So you divide the damage by the max HP and multiply it by 300. This process converts a raw amount of damage into a percentage of an arbitrary number, in this case the max HP. The number is then sent off to a tag sensor wired to the defending combatant's health bar. The sensor goes through a microchip, which is activated while a timer is active that has the same max time as the microchip.

http://ie.lbp.me/img/ft/34e7cb27e7a7e93535502c3050b34fe8e458b0bf.jpg

Again the microchip just has a node in it. The lower timer is the sample window, the right-hand timer is the HP bar. You can see that the microchip feeds somewhere else off-screen. It connects to a second timer with identical settings to the right-hand timer, but is used purely for display purposes instead of actually triggering anything. When the timer on the microchip empties, the "KO" tag on the right turns on and the level will know to treat that character as dead/knocked out.

So, hypothetically, this should reduce the timer by a percentage that directly correlates to the amount of damage you want to deal.

This seems to not work how I'd expect it to though! For my first tests I've been using 99 health. I'm trying to deal 11 points of damage. 11/99 = .111... the health bar timer should drain completely after receiving this signal nine times. If I set the health bar timer and the sample window timer for the health bar to 9.9 seconds, that's exactly what happens. That's worthless to me though, because the whole point of this is to try and beat my old method in speed, so it's gotta be able to deal 99 damage in less than 6.6 seconds. However, if I try to reduce the speed on the timer, it stops working. Going to the most extreme, putting both timers at .1 seconds makes it require 14 hits for eleven damage in order to empty, rather than 9. Every number between .1 and 1 fails to make it work right and I honestly have no idea why. My best guess is that I'm running up against rounding error in the system and if that's the case then I've got no choice but to go back to my old idea. That doesn't really make sense to me as an explanation though, because if that were true then why would it would flawlessly with timers set to 9.9? I dunno, anyone who knows more about timers and upscaling/downscaling than I do, I'd love to hear some advice.

2011-02-27 06:56:00

Author:
Speed Racer

Posts: 156

It's kinda funny how we both went through the exact same steps to reach damage bar designs. I was using counter, then switched to timers, then tried out a tag strength based system, then tried a sequencer, and now have a working 17-bit register (no display though, since that's annoying and costly).

Do you need to display the damage? It's quite easy to make the binary system once you understand how it works. Having just learned how to do it (less than 12 hours ago), it is immediately apparent that it works much better. With this system, I can produce any value from -99999 to 99999 (and beyond, though I'd need another bit to capture it). And all it takes is ~ 1/4 of a thermo section. You can use 15 of these systems at once (without anything else) without encountering lag.

The entire system is pretty much just copy and paste 3 parts:
- Activation
- Manipulation
- Result

Make an number of those, and you're pretty much done.

I use impact sensors for each bit for damage. This pulses the signal to each bit, which then adds to total (by carrying or storing). Depending on which bits are activated, I can detect how much damage is done to the unit, and thus trigger events.

The only issue with this is that is does not like continuous damage, but the upside is that it works instantly with any range of values.

2011-02-27 08:43:00

Author:
SSTAGG1

Posts: 1136

Well, I mean, "need" is a funny word, but yeah, I would very much like to directly display the damage. That's actually where all this is coming from. The system would be incredibly simplistic were it not for that.

2011-02-27 15:48:00

Author:
Speed Racer

Posts: 156

Hello there!

I'm working on a RPG,too.
And I also want to make a Healthbar (actual HP and Maximum HP) via 3-digit numbers
(0-999)
Visible Damage,calculating damage via external values...
I'm terrible in logic things atm.
But I know something about binary systems (I know how to calculate with them)

Can you gimme some tips how to begin?

2011-02-27 16:19:00

Author:
Unknown User

I went ahead and grabbed an analog probe, and it looks like the division of the timer is not quite right. There's a very tiny margin of error that is probably being compounded over and over to the point that it's throwing off the final answer. That's not exactly surprising given that I'm dividing it by a massive number, but it is disappointing!

I have no idea how to fix that or if it's even fixable or if it's an inherent limitation to the game, so it looks like I will not be speeding this process up. That's alright, the old method was a little slow but I'll live. Maybe I'll try starting from scratch again.

2011-02-27 17:54:00

Author:
Speed Racer

Posts: 156

If you've never faced any real-world electronics, let me tell you, it is terrifying.

That was 12 years ago, fool!

2011-02-27 18:03:00

Author:
Mista Epic

Posts: 16

Evidently timers are just incredibly imprecise? For the hell of it I set one to 1 second and then set its current time to .1, and the number that the probe pointed out was definitely not an even 10 at all.

Timer based division seems sort of worthless then if you can't guarantee even a modest amount of accuracy. Well, no, I guess if you were using something with simpler numbers then you could run the value through a sequencer and accommodate for margin of error that way. Still though, sort of a disappointment!

2011-02-27 19:39:00

Author:
Speed Racer

Posts: 156

Evidently timers are just incredibly imprecise? For the hell of it I set one to 1 second and then set its current time to .1, and the number that the probe pointed out was definitely not an even 10 at all.

Yep. Check out this post (https://lbpcentral.lbp-hub.com/index.php?t=47951-Guide-to-Speed-Rotation-and-length-units-in-LBP2-UPDATED-SOME-NEW-INFO&p=765993&viewfull=1#post765993) for details on timer inaccuracy, and the consequences...

...bear in mind that timers are deliberately inaccurate. For most max values they're off by one frame, so a timer val=0.5 max=1.0 will output a signal of 14/29ths (0.4827), rather than the more obvious 15/30ths (0.5).

2011-02-27 19:52:00

Author:
Aya042

Posts: 2870

2011-02-27 20:30:00

Author:
Speed Racer

Posts: 156

Is there any sort of consistent pattern to which timer values are off by a frame?

It's almost certainly a deterministic thing, but I'm not sure what the pattern actually is - probably relies on the internal representation of a floating point value.

2011-02-27 21:04:00

Author:
Aya042

Posts: 2870

Another thought strikes me; instead of going crazy trying to make my microchip work how I want, I can just roll with the error and change the way I define the values. Instead of telling the player they have 99 hp, tell 'em they have 296. Suddenly everything makes perfect sense without actually touching any of the logic!

It also occurs to me that I'm using much larger times for the timer than necessary. I arbitrarily decided that every HP bar should be a multiple of 3 points, but that so happens to work well with the way you do division. As of now though I'm not taking advantage of that. I'm dividing the value by three times what I need to divide it by, then multiplying it by three. That is a silly way to go about things! And hopefully might help me out a bit if I fix it, since I'd be getting larger quotients so hopefully the error wouldn't be quite as problematic?

So, rethinking the idea right now, I'm considering each frame of a timer to represent 1 HP. So a max HP of 6 would correspond to a timer set to .2. Every level, you transfer over to a timer set to .1 more seconds, gaining three more max HP. Then, when they hit a level that puts their HP timer into a problem value, I just say that they gained 2 HP instead of the usual 3. Simple as pie.

There's another issue here though that I'm not quite certain how to solve.

Not quite sure what you mean here, but bear in mind that timers are deliberately inaccurate. For most max values they're off by one frame, so a timer val=0.5 max=1.0 will output a signal of 14/29ths (0.4827), rather than the more obvious 15/30ths (0.5).

This sounds like the current timer value has the same problem values as the max timer value, right? In the example you use you say that .5/1.0 will be read as 14/29, and assuming that's not a typo, that means that both the current time AND the max time are being read wrong by the game, right?

Making the current value of the divider timers play nice with everything else seems like a much more complicated proposition. Unless I want to meticulously work out the values for every number 1-99 divided by every multiple of 3 3-99, I can't know what the value of the current time of the divider timers will be equal to until after the fact. Strictly speaking, this isn't a problem. Again, I can just arbitrarily call the signal a different number that makes the math add up. An attack that's supposed to deal 15 damage but doesn't quite get there because of it being misread by the timer, can be rounded down to 14 damage and we can go about our merry way. The problem, though, is how do you display that information to the player? Their actual HP bar won't care one way or the other, it'll empty by whatever value I feed it. But optimally, I'd like there to be something a little more exact to help the player understand the information. Basically have something like "-10!" pop up in hologram when they get hit for 10 damage. But if I have no way of knowing whether a signal will be interpreted as the correct number or some value less than the correct number, then I have no way of telling the player how much damage they just took. They're left to look at their health bar and estimate it. Which wouldn't be the worst thing in the world, but should be avoided if at all possible.

2011-02-28 03:41:00

Author:
Speed Racer

Posts: 156

This sounds like the current timer value has the same problem values as the max timer value, right? In the example you use you say that .5/1.0 will be read as 14/29, and assuming that's not a typo, that means that both the current time AND the max time are being read wrong by the game, right?

I don't know if it's strictly "wrong", it just "is".

If you're after an accurate discrete-value system, I'd suggest avoiding timers like the plague, and probably analog logic in general.

But optimally, I'd like there to be something a little more exact to help the player understand the information. Basically have something like "-10!" pop up in hologram when they get hit for 10 damage.

This will almost certainly require analog to digital conversion, and if you intend to do that, then why bother with analog logic at all? Just make the whole system digital.

2011-02-28 13:36:00

Author:
Aya042

Posts: 2870

You could always use something less precise mean to show how powerful the attack was like lights and sounds.

Or you could precalculate what the damage is and emit numbers.

2011-02-28 14:52:00

Author:
waD_Delma

Posts: 282

I don't know if it's strictly "wrong", it just "is".

If you're after an accurate discrete-value system, I'd suggest avoiding timers like the plague, and probably analog logic in general.

This will almost certainly require analog to digital conversion, and if you intend to do that, then why bother with analog logic at all? Just make the whole system digital.
That's actually a pretty fair point, and might be worth trying.

All of the problems that I'm running into have to do with displaying information to the player. Actually dealing the damage, looking to see if the target was killed by the attack, these are all painfully simple. It's just turning out to be very difficult to create a way to show the player that information in a format that's

-easy to read
-relatively low on thermo
-reasonably fast

I have not looked into bit registers all that closely so I might be misunderstanding how they work, but right now I'm unclear on how I can create a visible and user-friendly health display that can have both variable maximum values and variable amounts of damage dealt without chomping up thermo. I mean, off the top of my head, a slight variation of an analog probe would work, but I would be seriously concerned about how much thermometer space that even 3 of those would take up, let alone 6 or 9. Using a timer or a counter was nice because I only needed exactly one microchip, which could send and receive signals from and to the relevant meters.

I feel like my best two options at this point are:

-accept the small amount of error that's inherent in using timers, don't directly display the amount of damage dealt, and remember that some error really doesn't matter because no one is going to be min-maxing an LBP level so who cares
-go back to my counter-based method. It requires a very small amount of logic, and while it's slow compared to the timers, for my first level the max HP values probably won't be cracking 25, and .63333 seconds is not exactly a long time to wait in a turn-based game. Looking up some videos of Pokemon online as a random RPG example, the HP bars for the higher levels take pretty long to empty out, so it's not that out-there to make the player wait a few seconds for the damage to resolve. Some of the delay could easily be masked by making the HP bar empty while the battle animation is still taking place. At the higher levels there's obviously going to be some relatively sophisticated animations for strong, HP-devouring attacks that would induce a (relatively) lot of delay, so that could be a good way to go.

The only real downside to the counters is that the only way to make it work is to emit a new HP bar with every new level gained, so you've got to be able to emit ~32 HP bars x 3 party members, plus one HP bar for every enemy. The HP bar isn't exactly thermo-heavy, but I'm just trying to be as thrifty as possible with heat.

Actually wait, I could have most of the HP bar logic on a piece of holo, and only emit a counter that feeds and is fed by tags that correspond to the piece of holo, and just use followers to keep 'em together. Alright then I guess counters it is.

2011-02-28 20:13:00

Author:
Speed Racer

Posts: 156

This sounds like the current timer value has the same problem values as the max timer value, right? In the example you use you say that .5/1.0 will be read as 14/29, and assuming that's not a typo, that means that both the current time AND the max time are being read wrong by the game, right?

I never checked that exactly but I did play with timers for division and noticed that ANY timer value evenly divisible by 0.5 and any evenly divisible by 0.7 (And apparently any evenly divisible by 1.9 and probably others as well) will result in 1 frame shorter. But when using the timer for division, the current value doesn't matter... A timer of 1.0 will divide by 29, regardless of how setting the current value works out. (This is tested.)

But it's not exact; in my tests, division by one of these bugged values lost a LOT of precision, so it's not exactly a frame it's off by.

I also disagree that it's intentionally off. It just seems too strange and irregular to be intentional.

2011-02-28 22:12:00

Author:
Tygers

Posts: 114

well yeah that seems odd to me too: if it were intentional, wouldn't it be true for every value?

2011-02-28 22:13:00

Author:
Speed Racer

Posts: 156

well yeah that seems odd to me too: if it were intentional, wouldn't it be true for every value?

Not necessarily.

Perhaps MM's automated test cases only included multiples of one second, and they didn't bother checking the rest, and certainly for all cases where I tested timers in multiples of one second, they were always off by exactly one frame, in terms of the amount of time they last for.

However, just because a timer set to max=1.0 val=0.5 is exactly equal to 14/29ths (or as close as you can get in a floating point representation), it doesn't necessarily follow that a timer set to max=1.0 val=0.6 would be equal to 17/29ths (i.e. 3 additional frames) - in fact, I'd guess it's actually 18/29ths, or more generally f(val)/f(max) where f(x) is the number of frames which a timer set to max=x lasts for.

TBH, I'm not really too bothered what the values actually are, as I intend to avoid using them for any calculations which require any precision. They're great for approximate values, tho'.

2011-02-28 22:51:00

Author:
Aya042

Posts: 2870

2011-02-28 23:01:00

Author:
Tygers

Posts: 114

Hm, okay. So the idea should still be doable then, I just gotta figure out some new fractions to accommodate for the fact that I can't cleanly divide by the numbers I need to divide by.

Is there any sort of consistent pattern to which timer values are off by a frame?

This is just a guess mind you, but based on behavior, I would wager that timers actually have two extra frames built into them. Their behaviors require them to register full, empty, and currently counting, depending on how you have them set.
The easiest way to accomplish this would be to have the actual timer portion to represent the ON part, and then just tack two tiny pieces on the ends to register the other states. I have no idea how long this would actually be.

I was working with a timer set to .3 just messing with some scaling, and I noticed that it was off, 3 was slightly less off, and 30 even less. It all appeared proportionate though, so i suspect that it is a fixed value somewhere in the timer.

2011-02-28 23:17:00

Author:
tdarb

Posts: 689

The idea of test cases only catching some values does seem possible. But that would just back up it NOT being intentional. The multiples of a second are because that's evenly divisible by 0.5.

Well, it's all speculation, but my guess is that it's intentionally off by one frame for all cases where a timer max value is a whole number of seconds, e.g. an 'n'-second timer should only be active for ((n * 30) - 1) frames, and the behaviour for other cases are unspecified.

Imagine the test case for, say, a one-second timer consists of hooking up a timer with max=1.0, output wired to reset, and confirming that pulses every second... which it does. The one frame it's off by is the one frame which is required for the reset. The same setup, but with the timer set to max=2.0 pulses every two seconds. Tests pass = no bugs.

If the test case were instead to confirm that a one-second timer hooked up to a motor bolt set to speed=360 rotates precisely one revolution, then it would fail, but that clearly isn't one of the test cases, and given implementation, there was no way they could make both cases pass in the same test suite - either one or the other necessarily had to fail, so they just picked whichever they figured was more useful for the average creator, or more likely, the people who actually had to build the Story Levels.

They probably never bothered testing the other values, particularly if they were never used in the Story Levels, or if they deemed the precision sufficient - I mean, most people probably don't care if it's off by one frame, so it's good enough = no bugs.

That's just the way software development works in practise, particularly if you're working to a strict deadline. I mean, this is a low priority issue - they were probably far more concerned that the game didn't crash, so comparatively speaking, who cares about the odd lost frame here and there?

2011-03-01 16:55:00

Author:
Aya042

Posts: 2870

Here's a little kicker... A freshly placed timer runs for a full 120 frames, a timer adjusted to 4.0s runs for 119 frames. Anyone still think it's not a bug?

The current time setting also suffers from the same flaw, but if you're using the timer as a divider, the current time tweak doesn't matter; adjusting the current time through circuits still works as expected. (In other words, a 1.0s timer will take exactly 29 pulses to fill, despite the fact that at 0.5s it's at 14/29 and at 0.7s it's at 20/29)

Put the two together.. And if you place a timer, hook it to a 0% battery, set the current time to 0.0s, then to exactly 4.0s (Press right on the D pad 4 times only) it won't be 100% full. It will be at 119/120 frames.

2011-03-01 19:27:00

Author:
Tygers

Posts: 114

Put the two together.. And if you place a timer, hook it to a 0% battery, set the current time to 0.0s, then to exactly 4.0s (Press right on the D pad 4 times only) it won't be 100% full. It will be at 119/120 frames.

Really? That's just hilarious.

Need to check this out, but that sounds more like a bug to me - it would effectively mean there are two different framecounts for 4.0s depending on how you selected it.

2011-03-01 19:34:00

Author:
Aya042

Posts: 2870

LBPCentral Archive Statistics

Posts: 1077139 Threads: 69970 Members: 9661 Archive-Date: 2019-01-19

Datenschutz

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.