jump to navigation

Let’s Make a Game: Short Circuit April 23, 2014

Posted by eric22222 in Game Development, General.
add a comment

Things are about to get really interesting.

I was adding more sprites to shoot at and drew up a little red and white target. It would just hang in the air, get shot at, and drop some easy loot. Then I thought a little variety would be good, so I added a target with a gemstone emblem, the idea being that it’d drop lots of loot. While drawing that one up, I threw in some other symbols for other targets. A star, an exclamation mark, a question mark… I started thinking of what these other targets could do, and I got a cool little idea which slowly morphed into a cool big idea.

The little idea was a pretty simple set-piece: hit a target over a door, and the door opens up. Really simple gameplay, not challenging aside from the difficulty of aiming properly. But maybe if the door was far away from the target it would be more challenging. So now there’s the matter of indicating to the player that interacting with trigger A will affect object B. You know what game did that well? Portal.

Pictured: not actual gameplay

Pictured: not actual gameplay. Sort of. It’s complicated.

Portal is filled with buttons and switches that activate all sorts of gadgets, and each cause is paired up to its effect by a string of dots across the floor. No puzzles require you to use those clues, but they can help you keep things organized in your head while solving the puzzles. As soon as you hit a button, the connected set of dots light up immediately, and you can follow the line to see what happened.

What if instead of lighting up immediately, the circuit moves through our bubble wires at a walking pace? Now the idea starts evolving. Entire levels could be designed around hitting a trigger and following it through the stage. Tiles that have a circuit pass through them could trigger blocks appearing or disappearing. This would be a simple way to implement the door idea, as well as a bridge that appears after you flip a switch. Even the block snake from Super Mario World would be easy to set up if the rules are well-defined.

It takes me about a week’s worth of evenings to get this working the way I want it to, and I’ve still got other circuit tile ideas to add. Here’s a brief overview, followed by a video demo.

Circuit blocks come in a few varieties, but they all have two states: off and on. Circuits are currently created whenever a carrot hits a trigger block (the target-colored tiles). The head of the circuit begins following the path. When the circuit is six tiles long, it begins to disappear at the rear, so it sort of snakes through. It will always travel straight until it hits a wall, then it will turn. Still deciding what to do in the case of T-intersections. A dead-end prevents the circuit from moving, and it is deleted when its tail catches up.


One special block is directional circuit blocks. If a circuit hits a directional block, it will attempt to travel that direction. If coming from the opposite direction, it acts as a wall.


My favorite blocks! Blue blocks can be passed right through until a circuit powers them, then they become solid. Red blocks work in reverse.



Here’s an example of a circuit-based platforming challenge. Not only do you have to keep pace with the circuit, you have to jump over the gaps that won’t have blocks filling in.



Let’s Make a Game: Physics! April 20, 2014

Posted by eric22222 in Game Development, General.
add a comment

As part of my graphics upgrading, I added lots of nice new frames for our nameless rabbit hero. I started piecing them together for a better walking (hopping) animation, then started getting ideas for some other fun movement tweaks. Check it out!

First up, sliding. When the player tries to change direction, they’ll get a split second of sliding to a halt before they can turn.

Short hops have been added to improve jumping. Previously, every jump was the same height, but now you can release the jump button to stop mid-jump.

Wall jumping is a fun addition. If the player is moving down and is flush with the wall they’re facing, hitting the jump button will trigger a wall jump. Currently these can be chained indefinitely.

For another jump tweak, I added a sort of ear flap maneuver. If the player holds the jump button while falling down, it will slow the bunny’s descent. This seems a bit over-powered for basic play, so I might make it some kind of upgrade to be earned partway through the game.

Lastly, and unrelated to the game physics, I changed how the camera operates. I’m not sure if there’s a name for it, but it’s a sort of “lazy camera” approach. The camera has a target position determined by the player’s position and velocity, then moves towards it. It actually makes a lot of difference when moving around, and gives the game a smoother feel.

I’ve got a big, fun feature that will add a lot of interesting options for level design, so I’ll talk about that next time.

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

Posted by eric22222 in Game Development, General.
add a comment

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.


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:


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.

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

Posted by eric22222 in Game Development, General.
add a comment

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!


Let’s Make a Game: Target Acquired April 10, 2014

Posted by eric22222 in Game Development, General.
add a comment

Our character can run around and shoot now, so how about we add something to shoot at? First, some quick programmer art:


This spinny diamond thing is going to be just floating in the air, soaking up our projectiles. Since he won’t have any special stuff going on, we’re just going to give him one state animating through each of the frames I made.

Now, if we were staying on this side of the code, we’d add a bunch of functions to search for colliding carrots, store the index, and all that jazz, but we’re going to take a detour behind the scenes and just build it all from the ground up.

The improvement to code access is my favorite part of SGDK2 over version 1. We could spend some time making all these functions on the front end, but we’d have to recreate them for EVERY ENEMY. With a just a little bit of code-writing, we can have every enemy follow the same rules. That way, when we decide to add a new feature to enemy interaction, we can spend 5 minutes updating a few lines, rather than 5 days updating hundreds of enemies.

I’m having the front end make one function call: Update. This function will be called by every enemy definition once per frame. It’s going to start simple, but will probably be a tangled mess before I even realize it.

Each enemy will have a value called initialized. This is a boolean (true or false) that tells me if I’ve run the update function for this sprite yet. If initialized is true, I’ll proceed with normal update functions. If it’s false, then I’m going to take a moment to set things up. I’ll set the sprite’s health counter, maybe assign him a certain amount of treasure to drop, that sort of thing. We don’t need to reset the maximum health every frame; by only doing this once per sprite, I’ll cut down on the amount of time spent running our function, and hopefully make everything run smoother.

Now that I’ve got the basics in place, I notice that it wouldn’t take much to add some neat features. I’ve got a function called “ApplyDamage.” Right now it just adds to a running total for damage, but I’ll have it update a health bar or something, too. But it would be really easy to have an “ApplyHeal” function, too. Maybe some enemies could heal their buddies, or have some slow regeneration.

Eric, why not just use ApplyDamage with a negative number for healing? Why have a different function at all? My thought is that although that would be less code, it could get me in a lot of trouble if I forget about that “feature.” Suppose I add in an item that gives the player a defensive boost, reducing all damage by 3. Ecstatic, the player leaps for joy… right into a pit of lava. Oh no! But what’s this? The usual 1-damage-per-second lava is actually HEALING the player! Now, I hope I would realize my mistake long before that kind of bug got introduced, but I feel like it’s smarter to keep these functions distinct. So ApplyDamage and ApplyHeal will not act on any negative numbers.

// Increments enemy's total damage by dmg
// Returns 1 if enemy is killed as a result
public int ApplyDamage(int dmg) {
___if (dmg < 0)
______dmg = 0;
___totalDamage += dmg;
___// TODO: CreateDamageIndicator();
___// TODO: UpdateHealthBar();
___regenTimer = regenFrequency;
___if (totalDamage >= HP) {
______// TODO: Kill();
______return 1;
___return 0;

And that’s pretty much it! This is really simple right now, and I can’t imagine it’s going to stay that way. You can see I have a few functions still to implement. We’ll look at some of that next time.