jump to navigation

Let’s Make a Game: Meter Made April 16, 2014

Posted by eric22222 in Game Development, General.
trackback

Ok, health bars are coming up. But first: I’m sick of looking at this crappy semi-grassy landmass. It’s time to make a marginally better-looking semi-grassy landmass!

Admittedly, this is not my department. Making quality, natural-looking pixel landscapes isn’t the sort of thing I figured out during my last foray into game development. So we’re going in a different direction. Colorful, stylized blocks.

graphicsUp

That’s a good contrast, eh? It’s a little bit Kirby and a little bit Sonic. For once I’m actually satisfied with my own game art. Note that I’m switching from a 48 by 48 pixel grid to a 24 by 24. The little checkered tiles show the actual grid, but the game is still going to be mostly based on the larger, player-sized 48 by 48.

Let’s get back to our bad guys. The numbers indicating damage are nice, but I think it’d be really cool if we could add health bars. My initial thought against it was that it would let the player see how much health enemies have, but now that I consider it, that’s really more of a plus.

I’ve got two ideas for how to go about this. The first idea is to just draw rectangles right on the display. SGDK uses OpenGL for drawing, which I have a little experience with. I bet I could look at some of the drawing code to figure out how it works in C#, at least enough to draw some rectangles over everything each frame. The other option is to treat health bars as a sprite that follows a parent sprite (to keep the bar over the enemy). The nice thing about drawing to the screen is that once I get a basic proof of concept working, it’d be easy to extend it for all sorts of changes, like changing the width of the health bar for tougher enemies, or making the bar a little taller if I decide it’s not visible enough. The advantage of using sprites is that sprites will respect layers. So health bars will be behind the UI and foreground tiles without any special case handling. I think sprites will be the way to go.

So I’m going to use a setup similar to my damage indicator numbers. Different frames will represent different amounts of health. I could probably use different states for different sizes of bars, so that tougher enemies have beefier health bars.

As usual, we’ll start with the graphics:

healthBar

I toss this into a basic sprite, and start working on customizing the code. A lot of this will be handled by the enemy sprite, so we’ll start there.

AddSpriteHere(typeof(Sprites.EnemyHealthBar), RelativePosition.TopCenter, RelativePosition.BottomCenter);

healthBar = ParentLayer.m_Sprites[ParentLayer.m_Sprites.Count-1];

healthBar.ModulateAlpha = 0;

I’m creating the health bar when the enemy is initialized. This way, I can reference it easily from any other functions that the enemy uses. When the enemy is damaged, the health bar needs to be updated. When the enemy dies, the health bar needs to disappear. Whenever the enemy’s health changes, I call this block of code:

healthBar.frame = (int)(System.Math.Ceiling(healthBar.CurrentState.m_frames.Length * 1.0 * totalDamage / HP) – 1);

if (healthBar.frame < 0) healthBar.frame = 0;

healthBarTimer = 400;

This is just a terrible way of saying “use the health bar that looks closest to our health percentage.” The healthBarTimer decrements by a certain amount every frame that the enemy is at full health. When it gets to 255, it starts fading out down to 0.

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: