Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 22, 2014
arrowPress Releases
October 22, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
A "Dark Intelligence" - Part One.
by Mike Hanson on 06/04/13 10:47:00 am   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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.
Space Debris - as simple as baddies come.

Finally, I topped the attack-wave off with a nice big, tough monster chunk of debris... something of a little sub-boss.

A few of my actual design ideas were beginning to bear fruit, mainly the need for focussed powering-up of the player's weapons... but I'd also seen how once created, a solid bit of code could easily be re-used and adapted for the next enemy.

And that's exactly what I intended to do...

---
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.
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.

It was at this point I noticed the flaw in my BAT-plan... No matter how I fiddled the speed numbers, all of the ships in the wave were attacking one area of the screen. there was always somewhere you could hide in a bid to pretty much avoid any fight whatsoever. The solution was fairly obvious...

I created two more sets of BATs, each with fiddled numbers, each designed to attack areas of the screen in which the player was likely to take refuge. I now had medium range, long range and short range BATs. I even segmented the attack waves so that the medium range ones attacked first, lulling the player in to a false sense of security, before hitting out with the long and short range assailants.

The overall effect on myself as a player was just as I'd intended... to force a fight. I quickly found myself seeking out my most effective weapon for dealing with BATs and then using it in abundance. again, my weapon-swapping design ideals were being validated nicely in a way that I was capable of manipulating as I created more of PowerUp's enemies.

---
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.
Things are escallating now: Taking on multiple enemies with the BUSCraft and some GLOBalls.

Even by now, you can probably see how with each baddie I was adding another bunch of tricks to PowerUp's host of enemies. I'd decided to go chronologically through the game, creating enemies which drew on the skills of the previous enemies while adding a few moves of their own... and it proved to be quite an effective way of going about things.

---

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 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.

...but in turn, HAIL was forming another little plausabillity issue at the back of my mind. In a bid to make the source of the rockets a bit more believeable I'd included the HAILCraft. In order to make this attack wave about the rockets and not about the HAIL, I'd put a very distinctive flickering, turquoise forcefield around the HAIL. This made the craft invulnerable, while the rockets were fair game.

As the HAIL was a ship I'd come back to add, the flickering, turquouse force field had already become a staple across the game. It popped up quite a lot as a functional thing, creating challenges for the player in focussing firepower on certain areas of bosses, and avoiding certain types of baddie, rather than shooting at them... The question forming in my mind was this:

"If the enemy forcefield is completely impervious to Weapon-F damage, and if some of the baddies use it... why wouldn't all of the baddies use it?"

A valid question, and I suppose that in terms of the story, the question can be answered by explaining that Weapon-F is a new and particularly powerful Earth-created fighter prototype. Therefore, the enemy would not have prior knowledge of the ship and no time to create specialist, totally shielded ships to counter it.

Alternatively, perhaps the aliens' forcefield tech is particularly rare or risky stuff and will only work under certain conditions.

Ultimately though, it comes down to this... who in their right mind cares? Here I was, wasting precious time trying to come up with a justification for enemy technology. I might as well ask how Weapon-F's reactor core actually works or why the player's ship isn't designed to be already fully powered up at the start of the game. These things are accepted as part of shmup lore. They make for a better game.

So if you're honestly asking yourself stuff like that, and for a while I was too... it just does! It just is! There's a line in plausabillity justification for a game like mine, and I'm drawing it there.

Let's get back to designing cool baddies!

---

Enemy - RAYCraft - Biting Off More Than I Could Chew

Damnit!

RAYCraft, is it?... I was hoping we could sneak quietly around this one.

See, I knew how to make a wave of baddie instances come and go. I could even get multiple types happening at once, but this early in the game, maybe a multi-part enemy was a little ambitious.

Here's what I wanted to RAYCraft to do...

On it comes, from the right, you know, the old simple right-to-left movement. I created three instances of them too. One that had a slight vertical up movement, one with a bit of down movement and one that went pretty much straight. There were to be generally two or three on the screen at any one time and the vertical movement variants just randomised things a bit. So far, so good.

The RAY was to be all about just that. As it travelled, a big white light would build up at the front of the craft along with a menacing charge-up sound which would climax in a big explosion of light from the front of the ship, crossing the entire horizontal screen and taking out anything it touched.

I won't get too lost in the details as I shudder to remember it, but the ammount of trouble I had getting that glow to stick to the RAY's position, getting it to charge and not influence the other two instances of the RAY, and in getting the actually ray it fired to just flippin behave itself was enough to steal weeks from my meagre development time (two evenings a week, remember?)

Oh, but that's not all... after that there was the casing. See, I wanted RAYCraft to have a sweet-spot. You could kill RAYCraft but you had to focus all your firepower into that light on the front, balancing risk with reward. See? Nice idea... absolute nightmare to implement.

I'd opted to create the RAY itself in two pieces, a front image of the ship in good, working order, and a back image of the ship, horribly battle-scarred, damaged beyond function, but with its forcefield miraculously intact so that while it could no longer shoot, its hulking form still made for a dodge-hazzard... Really, don't ask what I was thinking. At first it all made sense, but I think there was some element of coding compromise there in the end which started raising all those plausibillity questions.

...incidentally, it was also the first baddie I designed to use that accursed flickering turquoise forcefield. Nuff said.

Now throw all that into a big messy baddie and then include that fact that I STILL hadn't figured out how to make a baddie spacially aware and able to recognise the player's position, or for that matter, the position of IT'S OWN PARTS... and you get an idea of how delicate that particular house of cards was.

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
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 "stable".

The RAYCraft was a baddie, figuratively held together with sticky tape. It's amazing that it actually works as anything other than a harsh, long winded lesson in humillity.

Let's never speak of it again!

---

End of Level... Whatnow??

Shaken to my core by my experiences with multi-faceted baddies, I decided to skip over the boss. My reasoning was that if the RAYCraft was such a shambles, who knows what a mess I'd make of an attempt to create a level boss.

I decided that instead, I'd leave gaps for bosses and finish the bulk of the game, hopefully while gaining some much needed experience in making baddies and their AI. Then, when I came back around for the boss cycle, I'd have some good Boss ideas and the means to make them happen... It was a good call. I wasn't wrong about that.

---

Enemy: DEFCraft - Back to Basics

So it's fair to admit that my pride was somewhat wobbly when I hit the second Chapter of PowerUp. I'd lost weeks to that RAYCraft and I wasn't convinced that I'd ever fully understand the tight and tangled knot that was it's code.

For the sake of my own confidence, I needed to do some fighters! Stat!! Some simple, stupid, but noteably, rewardingly different fighters. I went back to my 5 minute sketches and within a couple of evenings I'd modelled, textured and rendered the slick and deadly DEFCraft. At least my design and modelling was becoming a reliable, textbook process.

I wanted to start the Second Chapter by again, excercising the player's Backshot projectiles so I spawned the DEFCraft accordingly. At first it sort of worked, but then I found that the random vertical positioning of the DEFs, coupled with their speed actually made the sideshot a more valuable weapon here... Still, targeting DEFCraft was fun, and when I decided to have the DEFs double back with a decremental swing and a cool little rotation animation, they became more fun still.

After the swing, I even added a little random up or down movement which made them a little less predictable and I suddenly found myself with a particularly nice fighter for accompanying larger, bulkier ships.

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

---

A Pause for Re-evaluation

Now, I'd lost so much time to the RAYCraft that I was beginning to wonder if I should keep all the normal baddies simple like the DEF to cut down on the risk of the project running away with itself. I wanted the game done by Spring/Summer 2013 and after a bit of rough scheduling it was becoming clear that in order to meet the deadline I'd imposed (basically, when our money was due to run out as things were looking dicey with my day-job), I'd have to cut down on either the overall ammount of ships or on doing difficult, experimental ships.

I settled for a compromise. Instead of going all out as I had with the RAY, I'd try to innovate within my comfort zone, bearing in mind that I'd need to keep my boss designs within the skill sets I'd have learned by the time I reached those bosses, so some push was necessarry.

On the other hand, instead of completely culling the enemies and repeating the same ones in angrier patterns, I decided I'd keep repetition to a minimum, committing to create a few completely new ships per level.

The real solution presented in this compromise was that in place of making too many new ships, I would create a RED type and a BLACK type of previously designed and coded ships. These would be introduced throughout the game alongside the completely new designs and would add new attributes to the current standard versions.

For example, a RedBAT might shoot a straight forward bullet before it takes off into it's "go" routine. I'd also increase their spawn rate, speed, durabillity, etc to match up to the player's weapon power by that point in the game. This would all combine to make RedBAT a bit more deadly than it's standard counterpart.

Then a BlackBAT might ramp up the odds further still. Appearing later in the game, a black bat might be tougher, smaller, faster, stronger, and capable of firing aimed shots at the player... If I ever figured out how to actually make that happen... Up to now, I still hadn't.

Still, things were getting back on track. I had something of a plan and it was time to put it into action...

---

Enemy: FABCraft - More Simple... but Effective

Despite the campy name, I really wanted something in a floating, automated bomb. Something that looked different to the bulky BUSs and RAYs, but nothing like the streamlined fighter style of the BATs and DEFs. I had a nice visual motif scribbled out for the FABCraft. Something of a spinning umberella with a camera-laden engine compartment underneath. Something that edged slowly upscreen but was tough to kill and spawned en masse.

I wanted early appearances of the FABCraft to give the player the impression of being pushed upward into a tight space, to put the pressure on the player to focus their firepower on clearing a path before taking a breath. In impact, I wanted the FAB to have a slightly startling explosion, bigger than it's smallish stature gave credit for... after all, it was a essentially a bomb!

All of this came together well and this very simple enemy actually made for a nice change of pace. After a bit of balance in the FABCraft's spawn rate, speed and durabillity, I was able to introduce other enemies with it, making for a nice fight that turned up the heat slightly as Chapter 2 progressed.

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

Again, Red variants and later, Black variants of the FABCraft made for very effective advances on this particular baddie design.

---

Enemy: SLOBot - The Last "Blind" Baddie?

As Chapter 2 unfolded, I went for combinations of the above enemies and began to introduce their more dangerous Red variants, but I did save one new baddie for the end. Again, fairly simple in design, the SLOBot sported another unique look. This time, instead of a ship, SLO was... well, a bot, and yes, there's definitely something of Atomic Robo-Kid to his design.

Even so, I was still shying away from ambition and had decided that any attempts at my next logical progression: identifying the player's current position and acting accordingly, would not take place until at least chapter 3.

SLOBot may be slow, simple and utterly blind to the position of the player, but with a little code-play, I managed to achieve something of a nice unpredictable, random fire rate in three set directions which made SLOBot somewhat dangerous. Add to this, the bullet offsets caused by his more intense floaty-wobble, and a wave of raging RedBATs from behind, and the difficulty level was feeling about right for this point in the game.

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
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 "see" you.

---

But Still...

...I was feeling a little anxious. I really needed to start pushing for more intelligence in the next level. I scoured my sketchbook for an enemy design that said "Evil", "Intelligent", "Intimidating", and found it in the form of what was to become the PINCraft.

If I could make this ugly little critter smart enough to see the player, then in Chapter 3 things would really kick off!

---

To be continued...

Related Jobs

DeNA Studios Canada
DeNA Studios Canada — Vancouver, British Columbia, Canada
[10.22.14]

Analytical Game Designer
University of Texas at Dallas
University of Texas at Dallas — Richardson, Texas, United States
[10.22.14]

Assistant/Associate Prof of Game Studies
Avalanche Studios
Avalanche Studios — New York, New York, United States
[10.22.14]

UI Artist/Designer
Bohemia Interactive Simulations
Bohemia Interactive Simulations — ORLANDO, Florida, United States
[10.22.14]

Game Designer






Comments



none
 
Comment: