We begin this eighth episode of The Brick Dead Project, an experiment in creating a video game with nary a clue to our names, having completed our most challenging and difficult feature yet. We continue our feature presentation with the quest for easier work.
The time since declaring BDProto1 as complete and moving on to create Brick Dead’s more advanced features has been grueling. It was time to throttle back and take on some of the easier challenges on the wish list. Our next task: I need some new balls.
The original concept for Brick Dead involved moving what were traditionally power-up items into a player controlled ‘Mana Economy’ and invoking them as different spell types. Knowing that a lot of people now prefer gamepad’s for control, I figured I’d just use the Xbox gamepad’s face button color scheme to guide the create of four different ball types. As a bonus, I’d have a stylish, color coded control scheme.This original concept had already helped me over an early creative hump: What color is Force?
So… What next? Well, we’re left with red, yellow, and green. A fireball is kind of a no brainer for this sort of game, so let’s start there.
I have made fire! – Chuck Noland, Cast Away
Traditionally, fire is created in video games using particles, a group of small, flat textures that flutter about. Since this fireball was going to be bouncing around, I wanted something a little more solid. I found a neat solution in Allegorithmic’s Substances. Substances were those neat little procedural texture generators we spoke about way back in episode 2. I found a cool substance called Energy Liquid in the free sample pack. After a good amount of tweaking, I found something that vaguely resembled, to my mind, brimstone. As a bonus, it animated! A smoke trail was added to make the ball easier to track and keep with our style established with Force Ball. The final little bit of spice was to add another particle system over the Fire Ball to create embers or magma falling off of the surface. Tack on an orange colored light and it came together as a pretty nice ball of effects.
I did hit a couple little Gotach! moments. It turns out that using textures that are procedurally generated at runtime has two kinda big problems. First, your textures don’t actually exist before the game starts. I originally wanted to make the black area of the Fire Ball transparent, but with no texture to manipulate and no setting for transparency in the substance, this made things kinda impossible. I could have generated static textures from the substance as I did to create the terrain, but then I would loose the animation (at least exporting a bunch of textures at a lower quality and creating a sprite sheet).
Secondly, the first time you cast Fire Ball, the texture had to be created. This led to the Fire Ball being colored bright blue with the missing texture for a second before the substance made said texture and applied it. This second problem really had me stumped for quite a while. The solution I came up with was to place a scaled down duplicate of Fire Ball under the terrain where it could generate the texture safely away from prying eyes long before a player would see it. It worked perfectly.
So, what do I do with my new Fire Ball? Well… A fireball would… set stuff on fire, I guess. This could be used to take out specialized enemies too squishy or resilient for Force. It could also be used to clear certain terrain obstacles. Right now, I had neither. So… Hmm… Why don’t I make something a little more useful.
Then God said, "I give you every seed-bearing plant on the face of the whole earth and every tree that has fruit with seed in it.”- The Bible (New International Version), Genesis 1:29
We’ve got yellow and green left to work with. I did want some kind of direct-fire weapon like Arkanoid uses. It’s a modern convenience to the genre for eliminating that one stubborn block you have left rather than waiting for a bouncing ball to hit it. I was torn between an enemy disintegrating Holy Ball or something like lightning. Disintegrating things and convincing lightning effects both sounded like more than I wanted to get into right now. What else we got?
Green button. Perfect. I needed a heal. Making the heal spell a ball also created an interesting dynamic: Here was a ball you didn’t want to hit! You’d launch it forward but the intent was to let it drop back off the field and into the same boundary you normally lost a hit for letting balls go. It was a ball designed for you to loose to keep you from losing. I loved the idea instantly.
Design wise, I needed to make sure it wasn't simply green. Thus far, green had been used in Brick Dead to highlight the undead enemies. I elected to move in a more earthy, herbalist route, mixing in yellows and browns. I used another substance to create a scattering of leaves on the ground and removed the background to create the transparent style ball I couldn't achieve with the Fire Ball. A swirling mix of yellow and green particles were added to the inside of the ball to add an element of life and motion. Finally, a particle system was added to create a trail of leaves in the ball’s wake.
This last element was the only real sticking point, but not for any technical reason. The leaf trail works similarly to the other ball trails. This sticky wicket was strictly a matter of style. You see, there a A LOT of leaves in the world. And there were A LOT of auditions for the role of Leaf Trail Leaf. Some looked too cartoony, some looked to clichéd, some didn’t look like leaves at a distance, some looked bad in groups, and some simply didn’t have enough character. Yeah, I actually thought that to myself. The leaf right before the final one was discarded after a day “because it didn’t have enough character.” If the Mrs. still listened to me she’d have thought I went nuts over the course of that weekend.
I keep waiting to meet a man who has more balls than I do – Salma Hayek
Yay! I had two shiny, new balls! Now I just needed to make ‘em do something. New themed particle systems were created for when each of these new projectiles hit an object. As for code, I’m just going to copy the CastForceBall code, change a couple variable, bind it to a new key, and see if it works.
And work it did! Until I tried to break it.
It’s important to try and break stuff as early as possible before your spiffy new coroutine ends up buried under a metric ton of ones and zeros. It doesn’t make you feel good, but finding out that something is flawed or bugged while it’s still fresh in your mind (and doesn’t have a bunch of other systems sitting on top of it) is important.
In this case, everything seemed hunky-dory. All of the spells cast from their own separate keys on their own separate charging triggers. Great! Unless, of course, you were charging one spell and started to cast another spell. Or held two triggers down. Or let up on one before the other finished. In any of those less than idea circumstances the whole thing flew apart in a mass of missing balls, null exception errors, and screaming babies.
Fortunately, I knew just the right tool to handle this mashup mayhem: My good buddy, Boolean variable.
Ya know, it may be the Strings and Floats of the variable world that get all the cool jobs and hot chicks, but it is that true/false hero Boolean that keeps everything working. If you’re not charging Force or Fire, then you can charge Heal. Whenever I’m presented with some kind of stupid “I don’t want any of this crap to happen at the same time” problems, the answer is, inevitably, a boolean.
Cramming all those booleans into a series of If statements already creaking under their own weight caused no end of anxiety. Fortunately, and surprisingly, it all held. Well, except where I forgot to flip a true back to false. Is wasn’t pretty, but I headed off one major headache before I had a chance to discover it the hard way.