INTRODUCTION Lately, a few mappers have been working on healthbars, mostly for Zombie Escape map bosses. I believe they could be used for more things if done well, and I've been working on my own systems too. Sadly, all the systems were state-based and had fixed (preset) states. This means, for each HP state it will delete a part of the healthbar, as if it was moving and/or changing. I built my five-state healthbar system (which is used by SubDelta on ze_Portal_Story and, in the future, by myself on Paper), but it didn't seem like enough to me; 5 states aren't enough, and having more would mean having a lot of entities 'wasted', something I wouldn't like. Michelle later released her syster on ze_destruction_of_Exorath_v3_5: it consists of a lot of wall_toggles(?) that get enabled/disabled depending on the number of humans that have arrived to the boss arena. It uses a lot of entities (1 toggle for each player, I believe, plus all the logic_relays/cases -> more than 70 entities for sure), and it doesn't feel right to me... What could be done to both optimize and make it look slightly better?A BASIC STATE-BASED SYSTEM As I have said, I made a simple state-based system with 5 parts. I wanted to 'copy' some older games (Battletoads, for example) that had a discrete number of HP slots (6 in the case of Battletoads, if I remember well). This system is based on 5 math_counters with fractions of the total HP the boss has and receives per player. So in this 5-state case, if the boss has a starting HP value of 1000 and adds 100 per player, you would have one math counter that starts with 200 hp and gets added 20 per player, another one with 400 and 40 getting added and so on... When you shoot the boss, the bullet counts for all of them; same happens with nades. Now, we 'empty' the 200hp-20HP per player one and we have taken 1/5 (20%) of the total HP; we 'kill' the first state with 5 full blocks or, in my case, we kill one env_sprite and toggle the next one (I wanted sprites because they aim at you and you can make them see-able through walls/models, so you can see the HP remaining though your teammates). Ok. It makes sense, doesn't it? But... it also feels a bit cheap, doesn't it? NOTE: This system, although it can look cheap at some points (for example, when using sprites that simulate 'continuous' HealthBars as in ze_Portal_Story), is recommended (by me) for weaker/moving bosses since it's really easy to parent to entities. It is also EASIER to understand, so I would say that if any, you should start messing with this one first. It's not that the other one is harder, but needs a bit more of work and math. Screenshots of this system: DOWNLOAD LINK: (Includes the 'prefab' .vmf file and a few (6) healthbar sprites for you to use) [-][-][-][-][-][-][-][-][-][-][-][-]> http://www.sendspace.com/file/615x25 A MOVING, CONTINUOUS (slightly less) STATE-BASED SYSTEMOk! We have... 3 HealthBar systems so far, the one I've explained above, Michelle's and (if you want to count this one) ze_ffvii_mako_reactor_b1 - b2 systems, which showed the TOTAL amount of HP left (but lagged a lil' and responded late).Still I'm not fully convinced; my system isn't really entity heavy but doesn't look 'right', Michelle's system is too entity heavy and still looks slightly odd (to me); and Mako's system (thanks to Tony for sending me the mako_b1.bsp, as I wanted to check it and couldn't find it anywhere) isn't quick enough... WHAT CAN WE DO!?!??!?!I had an idea; what if I divided a fixed amount of hammer units by the number of players, and made it so that when the HP corresponding to the overall HP added by one played was taken out of one counter, some entity moved the result of the division? Hmm... This would divide the healthbar as Michelle did, but it would take less entities if possible; I had to try.- Hey Kaemon, do you know if it's possible to divide the value of a math_counter A with the value of another math_counter B so that A contains A/B?- Nope. I don't know if it's even possible.I tried. Failed. Hmm... What if I used a set of logic_cases with the fractions on them (and each case being assigned to the denominator (?) of the fraction)? Maybe that will work, I will have all the speeds on 4 logic_cases that will trigger an output depending on the amount of players from 1 to 64. I redid the system this way:4 Logic_cases (Select the size of the bar)1 math_counter had the initial hp (Let's call it A)1 math_counter had the hp per player (Let's call it B)1 math_counter kept the number of players -> subdivisions of the total bar (Let's call it C)1 math_counter counted the number of players and stayed that way (Let's call it D)1 func_movelinear (Mov)1 func_breakable (Last)The system worked/works (with a few changes) like this: when you shot the boss, you would subtract 1 from both A and B. B starts disabled (as I was making the initial HP as the HP on which ragemode/last line/last effort would happen). If A emptied, it would subtract 1 from C and refill itself, also selecting the speed of the bar with the logic_case (using D, that doesn't change) and making it move. If C became empty at this point, it would kill/disable A, enable B and wait about 1 second to kill the first 'moving bar'. At this point, you would have only Last showing up. Last will break when B, which has just been activated, empties... Seems coherent, right?I 'wired' the cases with the counter (D); THE HORROR! It didn't move always! Wait! What if I make the movelinear move (open) later? Yeah, I'll add a 0.01 waiting time on the output. Ok! It works... but... it's cheap! If you are alone the bar leaves completely! What could we do?I procceded to divide the HP per player by 4 (so the semi-states would be of 50 bullets instead of 200; I believe you can go as low as 35, but I would keep those things as they are), obtaining always 4 states + 1 (initial state) always. Hey! I made a Healthbar that moves and has 5 states with 10 entities (only 2 edicts, even better!). It will also have more states with more players (4 per player, so with 16 players we get 65 states, yipee! Will it look continuous?). It was time to set the speeds. Basically, I used this: Speed = (TotalUnits*10)/(4*Players), and in my particular prefab: (512*10)/(4*X) = (1280/X)Why those, you might ask? Well, at start I used stopping times of 1 second, so the bar would move for 1 second and then stop, without multiplying TotalUnits with 10. But if I did it this way, I was afraid sometimes more than 50 bullets could happen in less than 1 minute, creating too frecuent start-stops that might bug it; I changed the time to 0.1 seconds, which means that you would need ten times the speed to 'fill' the exact same space. The 4 that multiplies the X comes from the numbers of divisions per player, as I explained before. We're almost done!I needed to count the subdivisions now, as I was working with them, so I made that C had a limit of 256 instead of 64 (64*4 = 256), and instead of adding 1 to it by player, I added 4. I could have multiplied the final value, but that would have needed another input (not that it is that important to have one more, one less, but you know...)What was left? AH! How could I forget? Nades! With those 50-bullet states, nades would be worthless. A nade, if acting only at a time, would empty a full state (good?) but... what if the state was almost empty, with 4 bullets left, when the nade hit? Hey! I can split up the nade damage in 5 parts, so if it does 75 damage I make nade take 15 points when it hits, 15 0.05 secs later, and so on until 0.20... That would at least distribute damage, wouldn't it?Whoah! What a wall of text! Are we done explaining now?Yes.BUILDING YOUR OWN (COMING FROM MY PREFAB)First of all, you'll need to understand what I wrote over this. The system is not hard to implement (I believe it's pretty simple) but you have to get it right before.The easiest way to build it in your map (and this is the one that I will explain, although you can use what I wrote to build your own) would be using my prefab .vmf and modifying it to your liking (and I would recommend you to do it the first time if you didn't fully understood what I wrote). You would have to edit it, mostly just setting the HP of your boss, changing the healthbar's size (512 units by default) and setting the speed values for each fraction using the expresion found above. I wouldn't recommend changing the speeds (you can, but going under 0.07 on the stopping time might make it work weirdly). If you want to add more subdivisions you can do it too (it will move more precisely, but as with time, I wouldn't go too low, since lots of bullets could maybe trigger it again before it has reseted and it might bug; it's your choice). For this, I recommend you to use an OpenOffice Calc/ MS Office Excel sheet like this one: It shouldn't be really hard to read and understand on Hammer, however, if it was to you for some reason, you can ask me here...NOTE: You can make the 'LastHP/Initial HP' moving too! It will behave in a different manner, though, but you could spawn a movelinear at 0.75 of it's movement, make it close (go back) so that it seems to refill, and then implement another system (with another subdivision counter) on the InitialHP. This is up to you to explore!Screenshots of this system: DOWNLOAD LINK: http://www.sendspace.com/file/52k74j-----------------------------------------------------------------------------------I hope you can use it, find it useful aaaaaaaaand that you can help me to debug the systems.