The FPS tutorial covered using GUITexture to do health bars for the player. What if I want to put floating healthbars on top of the mobs?
My initial experiment was:
Creating 2 bar objects with healthbar textures (one with the alpha border texture, the other a plain red bar) and
Place them within the mob hierarchy and
Add a LookAt(camera) billboard script on it to ensure that the bar looks at the player at all times.
I feel that this is a crude attempt to simulate a floating health bar, My instinct tells me that this should be considered a GUI instead of an object. Any way around this?
Also can anyone help me with the health reduction script (to move the health bars)? I can’t use the tutorial’s pixelInset.xMax as this is a GUITexture exclusive script.
The billboard approach seems better to me. If the character moves behind something or is partially obscured, by other healthbars even, their healthbar will be obscured as well.
On the other hand, if this is more like a heads-up display, or a Sims-like floating menu, and it should always be in front of everything then the GUI approach might be more appropriate.
Just depends what you want it to look like, I guess.
If you go the GUI approach be aware that you may need to set the Z of the GUI object to prioritize which GUI elements paint in front of it. This might be important with multiple healthbars, or if there are GUI elements that always must be in front.
Ahh thanks metervara for the GUI tip. Attempting it now.
Thanks Bampf too for the heads up. I haven’t thought of that yet. I have to see how it turns out.
But judging from my experience with World of Warcraft HP bars/ Diablo II Loot Text. For instance, if a lot of chars/npc group together, the health bars will ‘bump’ around against each other,but not overlapping.
You’d have to write code that arranges the list of GUITexture elements so that they don’t overlap.
A straightforward method would be to mentally divide the screen up into a grid, and each GUIText would look at the nearest grid position to see if another GUIText is already there. If so, look for a position further away that is not taken. The search pattern could proceed in a spiral, going further and further out until an empty spot is found.
Let’s say for instance you decide the game screen is about 100 healthbars wide, and about 10 healthbars tall (your bars are tall but narrow.) So the screen is divided into a grid 100x10.
Calculate the screen coord of each healthbar as Metavara suggested. Then find the nearest point on the 100x10 grid. If there’s a bar there already, search adjacent grid positions, moving further and further away, until an open spot is found.
You may want to declare a 100x10 array for tracking which spots already have a bar in them. You would also need to clear the array and start over when starting to draw a new frame.
(Also, keep in mind that Unity screen coordinates for GUITexture’s range from 0 to 1 on each axis. I talk about 100x10 but that’s just to get the idea of the algorithm across.)
While it would often work, the above algorithm might put some bars right next to their critter, and others far away. A much fancier algorithm might try to minimize the distance all health bars are from their critter. Imagine each healthbar is attached by a rubber band to center of its critter. The healthbars would jostle and push until they minimized the overall energy in the system. I’m sure such an algorithm can be found on the internet if you hunt for it.
That’s probably overkill, unless you are writing something fancy, say, WoW.
A lazy alternative might be to just let the GUITextures overlap. If there’s aren’t a lot of critters it wouldn’t be too bad. You could use the distance to camera to draw them in the proper Z-order. You could also compute which critter the mouse pointer is over and highlight his healthbar, perhaps by pulling it to the front and making it opaque, or draw just the healthbar of the moused-over critter and no others.
Wow grids? Dang, gotta look it up after I solve the initial problems first.
Okay I got the code up, had a problem, though it could be silly variable practice.
var HPtarget : Transform;
var HPfabbie : GUITexture;
var HPGUI : GUITexture;
function Start() {
HPGUI = Instantiate(HPfabbie,Vector3(0.5,0.5,0),Quaternion.identity);
}
function Update () {
var mainCamera = FindCamera();
var p = mainCamera.WorldToViewportPoint(HPtarget.position+Vector3.up*1.5);
HPGUI.transform.position = p;
}
function FindCamera ()
{
if (camera)
return camera;
else
return Camera.main;
}
When I declare the HPGUI as a GUITexture, it pops out an ‘UnassignedReferenceException’ stating ‘HPGUI.transform.position=p’ variable has not been assigned.
But when I declare HPGUI as a plain variable, the HP bar works just fine. But if i leave them out, I can’t use HPGUI.pixelInset as they said they are unable to find the pixelInset variable.
Sorry if I wasn’t clear. When I’m talking about grids I’m not talking about anything built into Unity. You are just calculating positions to snap your healthbars to so that they don’t overlap with each other. By dividing up the screen (using a mathematical formula) you can take the “natural” position of a healthbar and snap it to the nearest grid coordinate, as long as another bar isn’t there already.
As for the code you posted. I think the problem is that a GUITexture itself doesn’t have a transform, its game object does. So you could declare it as a GameObject, then to get to the GUITexture you either use FindComponent or the built-in property .guiTexture. Alternatively, declare it as a GuiTexture and then get its GameObject via the property .gameObject.
I program Unity in C# so it’s possible there’s some implicit conversion in JavaScript that makes the above steps unnecessary. Or maybe there’s an easier solution. But it would explain your problem so that’s my guess.
OMG you’re right Bampf, thanks!. guiTexture solved the problem. I wasn’t aware of the concept of a GUITexture WITHIN a Gameobject and needing to call a guiTexture before calling its native property until now. XD
Here’s the fixed code.
var HPtarget : Transform;
var HPfabbie : GameObject;
var HPGUI: GameObject;
var healthGUIWidth = 0.0;
function Start() {
HPGUI = Instantiate(HPfabbie,Vector3(0.5,0.5,0),Quaternion.identity);
healthGUIWidth = HPGUI.guiTexture.pixelInset.width;
}
function Update () {
var mainCamera = FindCamera();
var p = mainCamera.WorldToViewportPoint(HPtarget.position+Vector3.up*1.5);
var healthFraction = 0.5;
HPGUI.guiTexture.pixelInset.xMax = HPGUI.guiTexture.pixelInset.xMin + healthGUIWidth * healthFraction;
HPGUI.transform.position = p;
}
function FindCamera ()
{
if (camera)
return camera;
else
return Camera.main;
}
And yeah Bampf I get it about the grid, thanks again for clarifying.
The HP bar follows the mob fine. But if lets say the mob is directly behind the camera view/character, the HP bar pops up right in front of me.
I guess its displaying exactly as where the screen position is, but doesn’t take to account the mob’s Z position relative to the camera’s local Z position.
Trying to solve this, currently my idea is that ‘if mob is behind camera, disable HP bar?’ any other suggestions is welcomed.
