- Home /
Best way to create mini hp-bars for enemies.
What i need is a little bar right above every single enemy unit, that indicates how much hp does this unit have.
I see two possibilities:
Create 2 box game objects that have rotation equal to camera (so it will always look as simple bar, that doesn't rotate) - one bar for hp part (red), and second for rest part of bar (black). At every hp change bars lengths changes.
Make two GUI labels (two in the same sense as with boxes).
About boxes, i see 2 ways of changing their position to stay above unit while it moves: 1. One big controller that manages all bars, setting at each frame their position equals to enemy unit game object + some offset. 2. Bar simply attached to game object as child.
About gui label i see only one way of managing its position: at each frame calculate game object position vector from world to screen (Camera.main.WorldToScreenPoint)
So there are kind of 3 ways to manage hp bars that i thought of (2 ways of box solution and 1 way with GUI labels).
What do you think is best in manner of performance ? Also how do you think, how heavy solutiona are comparing to each other ?
If you have any other solution it would be also cool to know ;]
There will be many of those bars, because im working on hack'n'slash game, like diablo or torchlight, with armies of enemies on the screen ;] Thats why i want to look at the problem from performance side.
Unfortunatelly i dont know any other proper way to do HUDs then GUI, but since i read about GUI that is often bottleneck, i would like to do my work on hp bars properly right now, not when i find out that slows game down terribly.
Game is 3d, camera can rotate around player. Perspective is like in diablo, torchlight, but problematic can be that player is able to zoom in / out cammera, and rotate that. So boxes should have rotation identical to camera, so it will always look like simple rectangle.
Do you want them to scale according to distance, or should they always be the same size regardless of how big/small the actual unit is?
Hard to say at this moment, best would be have both options to test them to deter$$anonymous$$e which solution looks better.
Answer by StephanK · Jan 02, 2013 at 10:47 AM
If you want them to scale I'd suggest to go the hp-bar as child way and have one function that adjusts the rotation of all of them (preferably only those visible). If scaling is not wanted I'd probably attach an empty GO to each unit as an anchor point, then calculate the screen position of each anchor point (Camera.WorldToScreenPoint) an draw the actual hp bar in your GUI system using those screen coordinates. The first approach will automatically scale your bars, the second won't.
If you want to avoid the Unity gui system you can setup a second camera just for your hp bars and use orthographic mode. If you set orthographic size = Screen.height / 2 you can position your objects using screen coordinates.
Do you know how looks performance for those solutions ? $$anonymous$$aybe it could be possible to calculate scale factor for boxes to keep them at one size ?
From coding perspective both gui and boxes seems to be light, so most important is performance :) How about mixing additional camera just for hp bars - does it perform better comparing GUI labels + camera.WorldToScreenPoints for each label in each OnGUI ?
Doing any kind of calculation in OnGUI is a bad idea. The extra camera approach will probably be faster if you compare it to using GUI.Label, you will still have to use camer.ScreenToWorldPoint. Sure you could calculate a scale factor but then i'd go the second way so you don't have to. Performance wise I'm not sure, I'd guess that the first approach is a bit faster as you only have to "calculate" the correct orientation once (you can use Quaternion.LookRotation) and then just update the rotation. For the second rotation you will have to do ScreenToWorldPoint once per bar and then either update the position of the object (using separate camera) or draw a label at that position.
Problem with second position is that i have to calculate Screen to world point every frame, or at least very frequently, because when i move camera, my coordinates of label will mess up (object on scenes will change their positions, but labels wont, so i will need to calculate position from begining, everytime).
I think i stick with game object bars, but first ill need to write calculation of object scale factor, to keep size looking static.
Thx for this help, ill upvote your answer, but not yet, because i cannot (You don't have permission to do this action.) - this answer hub is configured really idiotic :/ When i get rights i'll reward you with reputation ;]
Another approach would be to use a second camera that is orthographic, renders only your bars and is attached to the main camera. That way you won't have to update the size of your bars.
Your answer
Follow this Question
Related Questions
How expensive are legacy GUI Matrix changes / RotateAroundPivot performance wise? 0 Answers
Cameras Switch Based On Button Click 1 Answer
creation of buttons and other gui stuffs 1 Answer
[SOLVED] HUD ammo counter showing up only when a bullet is fired 0 Answers
GUI Menu Major Performance Issues 1 Answer