Benjamin R. Hernandez

Tame the Unreal

  • Demo Reel
  • Gallery
  • Tigbun Arts Projects
  • UI Design Class

The HUD ( Heads up display)

Posted by tigbun on December 14, 2012
Posted in: UI Design Class. Leave a Comment

The HUD has quickly become a requirement for many games, and is the source of the most important information a play needs during game play. In a fighting game, it is your health bar, your wins, the timer, a defensive or special skills bar, and your character’s name. In a Shooter, it displays your map, ammo, and at one time it also displayed your health. In an RPG it is all your actions and options in combat.

In a nutshell, anything that could effect your experience in a game in a moment’s notice. While it isn’t necessary for every game, it is hard to make sure a player has needed information without one.  Could you image a fighting game where you couldn’t see your current health? How would you adjust your risk management of your attacks based on that lack of information? How many time do you drink a potion in games to make sure your health is full, so you can go for all out attacks and finish a battle knowing you will take some damage? 

Take Call of Duty as an example, they hardly show you a health display anymore, but the closer you are to death they find a way of letting you know by making your screen red and bloody looking. When you are in this state it makes it harder to see the game, and almost forces you to think of a retreat to let your health restore, optionally you may also be forced to finish a fight quickly to avoid death in that situation. This is playing on the Flight vs. Fight mentality that all living beings have.

The HUD allows a player to understand how they may take risks, by displaying these chunky knowledge bites. But really just how much information does a player need? In League of Legends,  a player can see how much movement speed, resistances to magic, armor values, health, mana, health and mana regeneration…etc This is great for the technical game, but there is a lot of info on the screen that doesn’t go away. When making your game HUD you must understand the most important elements of your game. Some games have a HUD that dissolves to transparent, or hides fully when the conditions haven’t changed in a while. This shows a knowledge that that information is no longer needed while those events aren’t happening.

Lately I found a game project on Kickstarter called Kaiju Combat by Sun Stone Games (http://www.kickstarter.com/projects/14214732/kaiju-combat-giant-monsters-awesome-fighting-onlin ) Which is a good candidate for this study. The game involves Giant fighting monsters with different abilities, health and defenses.

As discussed on their forums, they are going with a Health Number rather than a bar. This choice is good because all monsters have certain defense rates and different health values for game balancing. The game has a health Number ( I.E 100 or more) and conditions that state that when a monster hits 0 and goes negative there is a percentage chance for a knockout which grows as the monster takes more damage below 0.(Condition, first person to gain a 3 KO’s chain, wins. This is based on if I make a KO I get a point, if I get KO’d that point goes away.) There is also a bar which will represent defense, and another one which will be used for special attacks.

The format discussed is currently displayed like this.

(Defense bar, which empties and fills based on your use of it or damage dealt to it, this may have a different value for each monster, but regardless with be shown with a bar between 0-100 %)

(Health Display, which will show your monster’s current health value number. This will also display a negative value once the health is below 0.) One could argue using a bar as well, but in this case a bar would be a bit fruitless due to character health being based on a value, that may only lower by very small percentages.

(Energy display, which periodically fills when not in use, and empties when used)

Someplace in the display, there should also be a Knockout counter to keep score. And the developers would also like to show how much damage is taken or dealt when a monster is hit by an attack.

In the start of a match, we have to know the three basics right away. Health, Energy, and Defense.  But we don’t need to see a damage value since it hasn’t been dealt yet, and the KO counter doesn’t have any points scored yet.  So I would say these are conditional, and should be hidden while not active. There can be an argument over the Score display, it may be shown if the developers believe that that condition will never change, and that new player may need it displayed to understand the winning condition of a game.

As the game progresses, the monsters fight. Health will lower, and a damage display should show up near the attack origin (Aka bouncing numbers off a monster) or someplace near the Health number. These should be removed after a short time after they become irreverent. The only issue that could arise, is should it display a number based on a single attack? Or a succession of attacks in a short time? Many fighting games like to display a number of successful hits, but in this game there is no other score based on combos.

Simply damage. I would choose a damage display based on successive attacks, because if damage bypasses a “block” it would be nice to know how much damage you have taken. Also since energy attacks may do “beam” like attack and do progressive damage based on contact with said beam it would make sense to sum up that number for the damage taken, because it counts as one long attack.

And there you have it, apart from a profile picture and a name. You have your HUD for a Kaiju game.

Stay tuned for a Part 2 as we go into more depth about HUD use in games.

Raising the Bar on UI design.

Posted by tigbun on December 7, 2012
Posted in: UI Design Class. Leave a Comment

Bars are perhaps the best and worst thing to come to HUD and UI designs. They are simple in the concept of letting the user know how much of something is there between 0%-100%. We are seeing all the time in games now, from value of Link’s hearts, regenerating shields, and to how much work you can do this hour on your virtual farm. Why? Because people like them. They are simple when compared with older methods of this function.

Lets look at one of my favorite games, Parasite Eve for the Playstation. In game the player has three items that show up commonly in battle on their HUD. Going down the list we have a AT Bar, HP, and P.E.. In game terms an “Action bar” which when full allows the player to preform an action of their choice. The HP or Health points are listed as two numbers, Current Health/Max Health. And finally the “Mana” bar or P.E. a bar that periodically fills towards the players maximum Parasite Energy who’s number is only seen in the status screen and doesn’t seem to link with the bar itself. This bar is drained based on the extra “magic” attacks the player can choose when they have an action. Some abilities cost a little and hardly remove any points from the bar, others can take up most if not all of the bar.

Ok so first of all why show the HP as numbers instead of a bar? Well Parasite Eve is an action turn based role playing game. When the player takes damage it does points of damage that vary based on attack powers, critical hits, defensive equipment, and magical shields. Most “classical” role playing games prefer to let the player know how much damage they have taken, and how much is dealt when they are hit. This lead up to the 9999 damage joke of most RPGs because the maximum values of HP of both characters and monsters was limited to a four digit health number. But does this mentality and metrics sound a bit familiar? MMORPGs picked up on the HP bar and number combo a long time ago. In World of Warcraft you can often see your current and max healths and a display bar based on that percentage of life remaining. It can even changes colors based on the amount left! All these are clues to let a player know, rather than guess how many more hits they can take. Parasite Eve was on the edge of classic role playing games like Final Fantasy, and in later FF games past 6 you notice a huge change in the way similar problems from Parasite Eve were taken care of.

This also leads into the changes in the “Mana” bar as well. In Final Fantasy games before 7 you would have similar problems with numbers. HP was often listed, with or without the maximum volume.(Which lead to people wasting magic on healing if they thought the number was too low) And MP was nowhere to be found on most cases on the main screen. In fact some had a number on the main screen, but most had it hidden within the magic casting list with current and max MP listed in it. In FF7 we see a huge change in that layout, maybe because of better UI design, or maybe just better graphical quality. When looking at it we have a HP number with current/max and a bar under it! Also a magic number represented the same way. Compare that with today’s MMORPGs, we have hit the jackpot of using a bar and number to let the player know what status they are in.

The active time bar however has not changed much over the years, and continues to be a staple in most RPGs. But we see a similarity with today’s MMORPGs. In World of Warcraft, abilities have a cooldown time after use. These can be as small as a few seconds, or as long as hours. Often this time is represented in a greyed out icon of that ability who’s time bar fills in a clocklike way to full value. Many players however like to see that ability a different way as modding and clever UI design makes a comeback with more bars. Curse.com and other modding communities have given players the chance to use custom HUDs to make their game experience better, and maybe give them an edge in game. A common mod is to make a targeting like circle around the center of the computer screen and have two sides to it. One being your characters info such as HP, MP, Buffs, and Debuffs all represented based on a bar based on cooldown time, active use time (for how long an ability lasts), or good old percentage left. The other belonging to your currently selected target with that same data. With all this information in one area, you don’t have to worry so much about looking at all the ability icons that WoW players are often bombarded with. And when you use an ability with cooldown, a bar pops on the screen and depletes until the skill is ready to be used again and disperses, letting the player know that they can use it once more.

I am not saying that bars are the last evolution in game UI’s. But when you look at them, can you really say they are really that friendly to players? In many cases we have replaced number values completely with bars, and in some cases where it doesn’t make much sense. We also are looking at the same bland style. A long straight bar that fills and empties. What if we could take that bar and augment it. WoW had a good idea with making it into a clock, which is the same way Penny Arcade’s On the Rain-slick Precipice of Darkness deals with the active time battle mode. As in other games, a Bar of bullets is much more fun to look at than some numbers or a normal bar. We have to get better at hiding them and using them where the are appropriate. You wouldn’t use a bar to show how much money or points a player currently has, even if there is a maximum value, they just are not use to seeing something so individual in a scale like that. And isn’t more fun to see Link’s hearts rather than a long white bar that empties as he is hit? Perhaps we move past the bar, in a “realistic” game where players have to look at their character’s health based on walk animations, limps. or blood trails. Metal Gear Solid 3 is major offender of the generic health bar, but it gets a pass because of the feel of the game because it is using as little HUD as possible to let the player see the environment as much as possible.

This is just a simple reminder, remember what the game your are making is about before you place that bar into the game. Make sure it is friendly to look at and matches the world and feel of your game. Or you will just have another long bar that is boring to look at. Next class we are going to talk about how the HUD, and how it effects game play.

The User Interface.

Posted by tigbun on December 5, 2012
Posted in: UI Design Class. Leave a Comment

Since the dawn of games we have seen a blend of visual and audio cues to let players know what they are doing while exploring a game. Pong was one of the first games on the open market and will be the example for a few key principles I will been discussing over the course of this blog. Pong started off commonly with a “Title Screen” where the player could choose game mode A or B, which later became. VS mode and vs the AI. When you start up Pong there are six different items on the screen. The Players, one and two, which are unlabeled but aligned with the sides of the controllers they are playing on IE, Left side and Right side. In later generations it would be systems like the Nintendo 64 that would assign players a title “P1,P2,P3,P4″ based on the controller slot.
This was the start of split screen gaming in my opinion, mostly because of the large dotted mid section that divided the two paddles. You could clearly see when your time was to start reacting to the incoming ball before it crossed by your paddle and offered a point to your opponent. The only two items left are the scores. Player 1′s and Player 2′s, respectively displayed over each side. But what is wrong with this UI? Simply put unless you have played the game before or read the instruction manual, you don’t know how high you need your number to be before the win conditions are met.

Games now are moving away from the instruction book method, and instead are using Videos or clearly marked rules while loading for game play. Gotham City Imposters is a great example of a pre-game movie showing the rules in a simple way even without spoken word. Where as most Call of Duty games now state a score number like (34/50 +4) letting the player know that there are three numbers to pay attention to. A current score, a goal score, and even how much ahead or behind you are compared to your opponents.

So a run down of the elements discussed today.
Which we will look more into in a future blog post.

A title screen, the players first experience with a game and its functions.
A Play area, the area which a player can change or interface with.
Player title, what role the player is assigned.
Score Display, what conditions the player is currently in.

Major Site overhaul to come!

Posted by tigbun on October 2, 2012
Posted in: Uncategorized. Leave a Comment

Sorry for the delay in updates. The job at Follett kept me very busy and I have been unable to post any recent artwork in a few months. I will be trimming the fat of graduation and adding in the new works I have been doing as well as direct you to Tigbun Arts and Games for my current game design projects.

Another site update.

Posted by tigbun on April 30, 2012
Posted in: Uncategorized. Leave a Comment

With the knowledge of Maya and Unity 3D going to soon be under my belt, there will be examples of my work being posted soon. Also there will be more posts in the gallery for concept sketches and renders.

To see the work I am doing for Henshin, CPU, and Death Corgi go to the Tigbun Arts blog.

Pathfinder Scene Project

Posted by tigbun on March 12, 2012
Posted in: Uncategorized. Leave a Comment

Currently working on a simple scene and animation as a student project about a Role Playing Game I enjoy. For those who play please support by buying the books.
Art (c) Paizo

Site Updates

Posted by tigbun on March 5, 2012
Posted in: Uncategorized. Leave a Comment

New Demo Reel will be posted shortly and new art will be added to the gallery by March 7th.

Henshin! A Masked Hero RPG – Document is written, starting to develop technical writing and rules. Working Playtest in about 3 months.

 

Posts navigation

← Older Entries
  • Resume

    • Resume DOC
    • Resume PDF
  • Recent Posts

    • The HUD ( Heads up display)
    • Raising the Bar on UI design.
    • The User Interface.
    • Major Site overhaul to come!
    • Another site update.
  • Archives

    • December 2012
    • October 2012
    • April 2012
    • March 2012
    • November 2011
  • Categories

    • UI Design Class
    • Uncategorized
  • Meta

    • Register
    • Log in
    • Entries RSS
    • Comments RSS
    • WordPress.com
Blog at WordPress.com. Theme: Parament by Automattic.
Benjamin R. Hernandez
Blog at WordPress.com. Theme: Parament.
Cancel