A "Dark Intelligence" - Part One.

Hello again,

So I'd just like to start by conceding that scripted dialogue is not my strongpoint.

I tried to make a few films back in my student days and they were, let's face it, pretty hammy... pretty bad! Still, I tried and resultantly I learned something about myself... Mainly that I'm better at drawing stuff than writing compelling stories, witty dialogue and believeable characters.

With that in mind I've been writing, re-writing, then RE-re-writing dialogue for my game, PowerUp. I know I'm not particularly good at it... but I've had some practice now, and thanks to that I'm not particularly terrible at it either.

Sure it's all an obvious mishmash of my sci-fi influences, piled up high with every "invasion" cliche in the book... but when PowerUp's HATI (your Holographic Artificial Tactical Intelligence) piped up that there was a "Dark Intelligence" at the heart of our reptillian enemy, it began to dawn on me that I might have a great subject for my next blog.

Let's find out if I was right, eh. Because in today's ramble, I'm going to tell you about...

---

PowerUp - The Evolution of Enemies

Yep. That's right. I've decided to let you in on snippets of the process I encountered when creating enemies for PowerUp!

I don't mean that I'm going to bore and alienate you with reams of badly-written code (this is my first attempt at a C# game, after all), instead I thought that as I pretty much coded PowerUp chronologically, I'd go through a load of the baddies from beginning to end in the hopes that any fellow aspiring coders, designers, artists, sound technicians and musicians who follow my shenanagans might feel that little bit less intimidated by the seemingly vast complexities of this aspect of making their game.

I can only really speak for my own experience, but once I'd mastered the control mechanics, scrolling backgrounds and pop-up dialogue of my game, I personally became sick to my stomach at the idea of populating PowerUp with challenging and engaging baddies.

I found that coming up with enough variety in visual design and attack style just knocks on to too many of the game's other facets, which in itself can make it all seem pretty daunting... not to mention the technicallities of actually making it happen! All that said, once I stopped with the panic, broke the workload down and approached it in a calm, realistic manner, I began to see some light at the end of the tunnel.

I also began to see the process for the profoundly fun, rewarding and prolifically creative outpouring that game development is supposed to be, and that the creation of my baddies actually really was.

...That sort of thing is why we wanted to make games in the first place, right?

---

A Place To Begin

So there I was. My player ship, now universally known as "Weapon-F" worked! She ducked and wheeled around the screen with grace and poise. Her arsenal was formiddable, her finer functionallity all but complete. The environment soared by in thick paralax, jumping to the next silent, abandoned game segment on cue, tracking my progress through the game as I closed in on the empty screenspace that was my first level boss. It was beautiful. It was promising... it was boring!

It was time to bite that bullet and start thinking about baddies!

I generally go quite a while between my blogs, I put most of my time and efforts into the game, so admittedly I forget what I've written in previous blog installations. still, I'm pretty sure that regular followers will remember me mentioning that while PowerUp was inspired by certain classic games I played growing up, my decision to actually try to make PowerUp was mostly inspired by the advice of a good friend and a good tutorial that piqued my interest in creating my own XNA shmup. Alongside basic controls, the tutorial introduced me to the concept of thowing instances of an enemy at the player... Just a simple animating sprite that moved from right to left while the player dodged it, shot it, or was killed by it.

So far I was coping nicely...

---

Enemy: Space Debris - Non-Sentient Moving Targets

After some head scratching and a spot of umm-ing and aaah-ing, I realised that with a little modification, I could turn this simple tutorial object into something just slightly more complex. I decided I'd start with a bit of space debris, rolling through space from screen right to screen left, but essentially mimicking what I'd learned.

Every second or so, my space debris would spawn another instance of itself, just off the right of the screen. It would then run a rotation animation (yes, animation. there was no mention of rotation in my lessons so I simply didn't have the nerve to even attempt it in code), while updating itself to move a few pixels to its left every frame of the game..... I say a few pixels, but I'd actually learned how to do this in vectors rather than real pixels. Vectors basically allow you to apply a decimal point speed, like say, "1.2" to the baddie rather than telling it how many pixels to move by. believe me, it makes things much easier later on.

Now it was just a question of what happens next... I decided that it I wanted to avoid being overwhelmed, I'd better deal with this enemy one action at a time. I started by looking at what happens when it goes off the left of the screen. The last thing you want is your game to crawl to a crashing halt half way through because over the course of a half-hour play of it, every single baddie is still running its code somewhere off the screen! Obviously, once my debris had reached and exited screen left, it was done with. I removed it without ceremony. Blink. Gone!

Next, it was a question of what happens when the debris collides with the player... Simple! I wanted the player to run its death sequence, and I wanted the enemy to remove itself. I tend to add whatever is needed as and when its needed so it actually wasn't until this point that I wrote the beginnings of the player's death sequence. It began as a take on the arc-up,-then-drop-off-the-screen death of many shmups of the retro era, but then I realised I could maintain a little control over the ship and even do something of a "parthian shot" death! Nice!!... hmm, but I digress and that's probably a story for another blog post. But what was evident was that there would need to be an explosion when player and enemy hit one another.

Adding an explosion was much the same as adding a baddie, except where the baddie was being added on a timer, the explosion was being added on a prompt. Later I went back and garnished my explosions with sparks, chunks and other bits of loveliness, but to start with, I had my explosion. And that was just fine by me.

I gave the debris the same outcome on collision with all of the player's projectile types... quite a time sink which I'm sure there's a better way of doing on my later projects, but in the meantime, a lot of player collision was copied and adapted for all of the player's projectiles, and now the player was able to shoot the debris right out of the sky.

And there it was! A fully functional piece of space debris with all of it's possible outcomes covered.

1. Hit player - remove with a bang and kill player.
2. Hit player's projectiles - remove with a bang and kill player projectile.
3. Bypass both player and bullets and get to the other side fo the screen - remove.

Upon playing the game through I came to realise that things were looking a touch repetitive. At the very least, I needed to add a few different variants of debris to this section of the game. Not only that, but I wanted to give each piece of debris some slightly different qualities of their own. I looked at what variables I had to play with and came to the conclusion that I could change the size, strength and speed of the debris pieces... so I did just that.

I made a few copies of my debris code and after creating a few graphical variants in Photoshop, making a few changes to the size of each debris' collision detection, and fiddling around with that decimal-point speed variable, I was able to forge several more bits of debris. The bigger they got, the slower they moved and the more shots they took to destroy.

Space Debris - as simple as baddies come.

---

Enemy: The Batcraft - Screaming, but Dim-Witted

For me, the most sleepless nights are caused by two emotional states, accute anxiety, or wild creative excitement. Over the course of PowerUp I've had great cause for both, but for now I was happy to be feeling the pleasurable pangs of the latter.

I had just created a baddie for my game!!

Suddenly it didn't seem like such a black art. The possibillities were opening up and if nothing else, I'd be able to create a game with simple enemies that move in a straight line... not quite what I aspired to but certainly better than nothing, and definitely cause for celebration. Over the course of nights on end I lay awake in the darkness for hours before sleep finally caught up with me, pondering, visualising, reasoning, planning out a potential means for the creation of so many complex enemies.

There was so much that I had absolutely no clue how to do, but my mindset was changing. I was beginning to trust in my future self.

I'd learned this much. I'll learn more... but I was determined not to bite off more than I could chew, and for a while, I stuck firmly to this rule.

With the debris came the beginnings of PowerUp's storyline, and the next logical step for that story included a nice simple, but suitably threatening wave of enemy fighters. I looked to my debris code and made my alterations.

These were the "BATCraft"... and it's probably important to state that there was no complexity, time investment or higher thinking to their concept. They were to look a bit like bats, the name sounded cool, and I wanted to quickly get through the conceptual side of things and into the meat of making it happen.

I scribbled a five minute sketch of a streamlined little cylon-like fighter (that ended up not really looking much like a bat at all), blasted out a model in 3DS Max, textured it, rendered it and applied it to a variant of my space debris code.

Up until now, I'd been drawing everything in Photoshop. I hadn't put much thought into the visual style of PowerUp as I was totally engrossed in learning some coding basics, but now the visuals were naturally surfacing. It was occurring to me that I'd need to rotate some of my ships, and doing that in 2D would be time consuming and much less visually convincing than modelling and rendering my ships in 3D... BATCraft would become my test subject.

So far, the BATCraft was a sliver of a ship, it moved from right to left just as the debris had done. I began to wonder if I could make the BAT do some kind of attack formation... perhaps a barrel roll off the screen or at the player, while showing off it's curves a bit... Yeah!

After a couple of frustrating evenings (I was working as a casual games artist in the day at this point, so PowerUp was getting a few hobby-hours, two evenings a-week), I was just not getting my head around how I was to make the BATs actually aim themselves at the player. "Well, it's early days" I thought. "Maybe I should keep them simpler than that". I did.

Instead of attacking the player directly, which I vowed to make baddies capable of later, I decided to set a mark exactly half way down the play area. The BAT would move slowly on from the right , then at a certain "go" point on the screen, it would assess whether it was above or below that half-way-down mark. If it was above, it would roll down, if it was below, it would roll up.

I did this by having the BAT spawn with a vertical speed (much like the horizontal speed inherited from the debris) of zero. At the "go" point, the BAT would play a firework-style scream and both it's horizontal and vertical speed would start counting. I'm told this is known as an "incremental" or "decrimental variable" depending on whether it counts up or down and while there's much more effective ways of coding its behaviour, apparently it's very good for stuff like jumping or falling through the air when a character is hit... and for a ridiculously naive and self satisfied moment (it turns out you have a lot of those as a beginner in anything), I thought I'd invented it... div!

Anyway, I applied the BAT's newly rendered frames of rotation as the craft counted up (or down) it's vertical speed and once the BAT was vertically off the screen, I applied the same bit of remove code that I'd done to it's horizontal exit and everything was pretty much tied up.

Screaming stupidity - BATCraft are the kamikaze grunts of the reptile race. At this point, each enemy took about 4 hours to design and model, then another 4 to texture and render. At 8 hours a-week, this constituted a week's work on PowerUp.

---

Enemy: The BUSCraft - "They Came From... Behind!"

I'll leave it for you, the player to discover the best weapon for the job when it comes to the vast majority of my PowerUp baddies, but with some, I make it pretty obvious. Looking at my weapon selection order, the next in line for early demonstration was the Backshot.

As the last of my BATCraft screamed out of view, it occurred to me that a further attack of fighters would look straggly and un-memorable. What the game needed next, was something big and chunky. Something akin to a flying bus... with guns!

I grabbed my sketch book and scribbled up the BUSCraft (no, really. That's what I called it... and that was why).

Another evening's work and I had my BUSCraft modelled, textured and ready to go into the game. A further batch of sleepless nights and I'd pretty much figured out how it was going to work.

This time, instead of spawning screen-right and moving left, I would spawn three on screen-left, in set positions. They'd move slowly right, hang around for a while, then if the player hadn't destroyed them with a flurry of well placed backshots, the BUSes would roll back off to the left. Once off screen, they would remove themselves and the game would carry on.

There were a few complications I hadn't accounted for here. Previous waves had spawned at random vertical positions making for an unpredictable barrage of baddies. That worked for them but these big guys needed to appear in formation, even with slight delays in their appearance if possible. It took a bit of extra work... fiddly work too, but eventually I had little timers going off at the right intervals to make the BUSCraft roll on one at a time, hang around, and roll off...

Next up was to make them a threat and give the player a reason to want them dead!

I was hoping to figure out the mystery of getting baddies to aim for the player at this point, but it just wasn't ready to happen for me, so after losing a few more nights of work to my attempts at it, I looked for an alternative... There's a lot of this sort of compromise early on. Thankfully less and less later.

I decided that if I couldn't aim directly at the player's current position, I'd create a bullet that shoots in say, eight random directions... though mostly forward so that projectiles are more likely to hit the player. I then adjusted the frequency of the BUS's shots to add to the challenge element of this slow and lumbering craft.

It's probably worth noting here that as I hadn't sussed rotation, I opted not to go with line shaped lasers, missiles, or anything like that for my multi-directional bullets. Instead, I created a perfectly round enemy projectile, glowing white for clarity. This way, an enemy bullet would be able to travel in any direction with just one animation and it could rarely be argued that an enemy bullet was unfairly hidden. the round bullet is far from an original concept, but its usefulness is worth a mention, I feel.

I was expecting to be able to move onto my next attack wave, but playing through, there was this wierd sense of static about the BUSCraft. As the three rolled on-screen, they looked oddly robotic and stunted in their movement. Quickly, it dawned on me exactly what was needed to bring these single framed golliaths to life... Floaty-wobble!

Yes, you read that right. These vicious monster-master race types, sent to wipe out humankind in the most brutal unfeeling manner were in desperate need of a bit of floaty-wobble.

Let's say I add one of those incremental integers I mentioned earlier to the vertical position of the BUSCraft... just a little one, that counts up slowly. The count-up might start at -2.0, then count up by 0.01 per frame of the game, passing zero and continuing to count up until it hits 2.0. What we get when we add this number to the BUS' vertical position is the impression that the BUS is jumping slightly, in slow motion. Arcing, if you will.

Now, if we wait until the BUS's vertical floaty-wobble speed hits 2.0 then make it switch to an identical bit of code that tells it to count down from 2.0 to -2.0, we'll get it doing the same slow motion jump thingy, but downward... With me?

Good.

Once it's done that, I'd switch it back so that it effectively loops the sequence and Voila!! A nice up/down floaty wobble for the BUSCraft! ...One swift copy of that code and a little adjustment so that it does the same thing horizontally, and before I knew it there were three big BUSCraft floating on the screen in a much more convincing and satisfying manner than I'd even hoped for before.

Things are escallating now: Taking on multiple enemies with the BUSCraft and some GLOWBalls.

---

Enemy: GLOBall - Filling The Cracks

  
After some prolonged testing with the BUSCraft, I came to realise that the static feeling I'd picked up on before wasn't just coming from the baddies. The linear paths and slow movement of the BUSCrafts' bullets meant that the player was able to hang around in one place far too readily in order to kill a BUSCraft. It seemed that even at this early stage in the game, the BUSCraft would need some additional distractions to keep the player on their toes a little more.

For this purpose, I concocted the GLOBall. A big, slow, floating mine which spawned ahead of the player and whose toughness against early projectiles put an emphasis on avoidance rather than on attack, this emphasis was made especially potent considering that at this section of the game, the player would be focussed on taking out three BUSCraft with the Backshot!

...It may have looked like an enemy craft, but as far as the code was concerned, the GLOBall was basically a very sturdy piece of space debris which borrowed the floaty-wobble code from the BUSCraft. Alone, it would make for an ineffectual and flatly, boring attack wave, but as an additional distraction for already populated areas of the game, the GLOBall worked a treat and took me out a few times, I don't mind admitting!!

---

Enemy: HAILCraft - Combining Functionality and Nifty Afterthoughts
 
So yeah, I'd definitely killed it with that "use-the-backshot, stupid!!" thing when I rolled on those BUSCraft, and now I was getting a taste for variety. I started to turn the first chapter of PowerUp into a quick showcase of the five weapons at your disposal and the next one was to be the Sideshot!
 
I wanted my next wave of baddies to come from the top and bottom of the screen. I wanted them to make it relatively obvious that you need to find the right weapon. I DID NOT WANT any kind of game slowing dialogue to explain the functionality of your game mechanics. A good game of my era would never stoop t that level. Instead, it would intuitively explain everything you needed to know by encouraging you to think latterally and experiment accordingly...

I sent in the rockets.

I'm sure I don't need to explain how I re-applied the spawning point of the debris to being just off the top/bottom of the screen with a random horizontal position... blah, blah, blah. You get it, right? I took the code I'd learned and adapted. Cool. Let's skip that.

First off the bat, I needed to slow things down! The player needs time to react. The shorter the space before impact, the slower the baddie needs to be. It sounds obvious, but there are a lot of barely playable games out there missing the rule that making an obstacle hard to dodge by simply making it too fast to react to really isn't the way to boost difficulty. First and foremost, you need to make your game fair!

Let's see. My debris was coming from screen right on a screen with 1280 pixels across. Even if we place the player one third of the way into the screen, accounting for where the player would be expected to spend most of their time and giving them ample looking room, we've still got a good 853-ish pixels of screen width for the player to see stuff coming at them.

With a height of 720 pixels and attack waves coming from both the top and the bottom, I was looking at a reaction area of around 360 pixels. that's less than half the warning space, though we do have plenty of horizontal area for those random spawns to happen over.

I'm not going to start doing any maths or anything here. I just wanted to hive you an idea of how different things are when you're spawning from the top and bottom of the screen. The only way to get your game feeling right is to play it... to trial and error the heck out of this stuff. I've worked at places where games are desinged by comittee, sat at a boardroom table with no room for diversion, then are produced without the afterthought they deserve. Then I've worked at places where the games have been crafted and improved as the need arose in an organic, evolutionary process. The latter is always the best way.

...and for the rockets of this section, trial and error was definitely a factor.

There was something that bothered me greatly though... something that shouldn't come up when creating a game like PowerUp, but it was a question of plausibillity: Where were these rockets coming from? Were they remote controlled? Were they floating out of shot, waiting for you to come by? It just didn't look right... and it bothered me!

I put the question to the back of my mind along with plenty of other implausibillities I'd picked up as I went along. Some remained ignored, some really grated on me. It might have been because I came up with this simple little baddie so early on in the game, but this one continuously grated!

...So much so that later on I came all the way back around and created the HAILCraft. Two giant floating arsenals which dwarfed a BUSCraft, heaving in from top and bottom to unleash their rocket-ey badness on you, then like the BUSCraft, at the end of the missile wave, they heaved away.

After I made the obvious further adjustments necessitated by the further loss of looking room, the job was a good un.

The HAILCraft's rockets are easily despached with a few well timed Sideshots: I would generally try to limit coding time for simple enemies like this to about 8 hours each. Another week's work in my 2-nights-a-week of free time.

The infamous RAYCraft looks deceptively sturdy, but was an exception to my 1-week rule, taking closer to 3 weeks to iron out the worst of the kinks. It was months until I was able to consider this one

A change of scene had blown out the cobwebs and now, with the DEFCraft, I was starting to have fun again.

The pressure was on with the explosive, and rather hypnotic, rotating FABCraft.

By the time I was done with the SLOBot, I was again feeling the urge to push my boundaries, push my luck and make something that could actually