jump to navigation

Let’s Make a Game: Lucky Number April 13, 2014

Posted by eric22222 in Game Development, General.

Taking multiple hits to kill is all fine and dandy, but how does the player know any damage is being done? Who’s to say the attack had any effect at all? Let’s add some damage indicators.

I’m a fan of little numbers flying from enemies to represent damage. This is really common in RPG games, where numbers are flying left and right like a sales presentation made by someone who’s really excited about PowerPoint’s animation options. I’ve got an idea for this that uses some features in a way that I don’t think was intentional. First, some quick number graphics. It would probably be wise to dynamically create double-digits on the fly, but for a quick and dirty solution, we’re just having 10-19 manually drawn.


Let’s get tangential for a bit. The scale of numbers for health and damage is a big deal for me. On one end, you have games like Final Fantasy [number], where tens of thousands of points of damage is not all that much. On the other end, I remember the first game of D&D that I played, where I started with a mere 4 hit points. There’s a nice middle ground in there, but I’m not sure where it is yet. I’m putting that decision off until later. For now, 3 to 4 damage will be normal for early game, with damage above 10 reserved for after our player has… leveled up? Gotten better equipment? I don’t know.

So my idea is this: we’ll have the damage indicator be a sprite that is created whenever ApplyDamage is called. When this happens, we’ll set the frame value equal to the damage value. Usually, frame is used for different parts of an animation or different directions for a rotating sprite, but we’re going off the beaten path a bit and getting creative.

The number sprite will be created when damage is dealt. We’ll immediately set the frame so it’s showing the correct number (frames are 0-indexed, which means instead of 1 coming first, 0 is first). After that, we’ll throw it into the air. A tile or two up, and a random amount to the left or right. Finally, we’ll give it a count-down. At a certain value, the number will start fading out. Once it fades completely, we’ll delete the sprite to conserve resources.

That’s another feature of SGDK2 that I really appreciate. I can dynamically set the alpha value (opacity) of any sprite. I don’t think version 1 supported ANY half-transparent graphics. In addition, I can scale down the red, blue, and/or green channels, allowing me to give all sprites a blue tint for night levels, or make them black silhouttes. That actually sounds really cool, now that I think of it. Something for another time, perhaps.

Anyway, WordPress is none too keen on formatting code as I learned last post, so here’s a screen shot of it instead:



I’m using the same init/update method that I discussed last time. The Update function is called every frame, which will call Init only once. Our initialization function gives the number a little upward momentum and a random horizontal momentum. Sidenote on the GetRandomNumber function: it’s given two numbers a, b as input and returns an integer x, where a <= x < b. Not sure why it does it that way instead of the more intuitive a <= x <= b, but whatever. Took me a while to realize it, though.

Our timer starts at 300 and counts down (it actually decrements by 4 each frame). As soon as it gets to 255 or below, it sets the opacity equal to the timer value. An opacity of 255 is normal. 128 is half-transparent, 0 is invisible. Once it fades from view, the sprite is deactivated, which removes it from the game.

Hooray! There’s a few changes in the video I haven’t touched on, as I’m programming a bit ahead of my posts.

First: enemy regeneration. If an enemy hasn’t been damaged recently, it starts to heal. I added some code that creates a damageIndicator sprite, but then modulates the red and blue channels to 0. This makes the number have a green tint without making a whole new set of graphics or a new sprite. Reusing resources saves time and sanity, kids!

Second: loot! I used a similar random initial velocity to spread out some little gemstone things whenever an enemy is killed. They bounce around for a randomish amount of time, then start to blink (modulateAlpha again). A short while later, they disappear and create a little particle effect sprite.

Third: slightly different player graphics. I’ve completely redone the player logic. The movement and states are all a lot smoother, and I’ve added animations. I don’t want to go into details on that just yet, though.

Next time: health bars!




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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: