Halo Wars Dev Blogs page 1 (most recent)

Halo Wars Unit Stats

This Excel Spreadsheet has all of the Unit Stats, but they are a bit complicated, so I’m going to do a walk through for a UNSC Unit and a Covenant Unit so that fans can get an idea of how much damage each unit does to another. Right click on the link, and Save to your computer. Then open it up in Excel or you can download the Microsoft Excel Viewer here: Microsoft Excel Viewer 2003.

It looks a bit complicated but I’ll try to break it down for everybody. I’ll start off with explaining some of the terms: At the top of each section is the name of the unit, for example Marine Squad. Below that, in this example, Infantry is the kind of Armor the unit has. (See the third tab for the Weapon Type vs. Armor chart). Bounty is how much Experience (XP) the unit gives to units that kill it. This Bounty is shared by all units that destroy the enemy unit.

Hitpoints are how much health a unit has.

DPS stands for Damage per Second. This is how much damage the unit’s specified weapon does without any upgrade. The Weapon Type is what type of damage that Weapon does. (See the third tab for the Weapon Type vs. Armor chart).
Some weapons have a Damage over Time effect (DoT) that affects a unit after it has been attacked in addition to normal damage.

Upgrades are the techs you research that affect each unit. They usually have a damage or health multiplier in addition to their main effect. Multipliers stack, that is, the 2nd upgrade builds on top of the first in terms of hit points or damage.

Veterancy is the stars that appear over unit’s heads after they gain a certain amount of XP from killing units. Each unit has its own Veterancy table, and they do more and take less damage for each Star they gain through killing other units.

Below is the math for the Marine and Banshee, hopefully it will give players a guide on how to calculate the units health and damage at a given level.

An un-upgraded marine squad has 5 members.

Assault Rifle
11 x 5 = 55 DPS
Grenades
280 x 2 = 560 DPS (Only 2 marines throw Grenades)
Hit Points
720 x 5 = 3600 Hit Points.

Getting the New Blood Upgrade adds a new marine to the squad, giving them an additional marine and upgrades damage dealt by their grenades. This upgrade has no HP Multiplier.

Assault Rifle
11 x 6 =66 DPS
Grenades
280 x 1.25 = 350 (x2 = 700 DPS (Only 2 marines throw Grenades))
Hit Points
720 x 6 = 4320 Hit Points.
Getting the RPG Upgrade gives the marine the following stats, adding 25% to health and all damage.

Assault Rifle
11 x 1.25 = 13.75 (x 6 =82.5 DPS)
RPG
350 x 1.25 = 437.5 (x 2 = 875 DPS (Only 2 marines shoot RPGs))
Hit Points
900 x 6 = 5400 Hit Points.

The Medic Upgrade, in addition to providing the medic for the squad increases RPG Damage by 25%. It does not give an HP Multiplier (although it does add a Medic to the squad, increasing over all HP).

Assault Rifle
13.75 x 7 =96.25 DPS
RPG
437.5 x 1.25 = 547 (x 2 = 1094 DPS (Only 2 marines shoot RPGs))
Hit Points
720 x 1.25 = 900 (x 7 = 6300 Hit Points.)

The final ODST Upgrade (only available to Cutter) changes the entire squad to ODSTs, giving them a 25% bonus to health and damage.

Assault Rifle
13.75 x 1.25 = 17.2 (x 7 =120 DPS)
RPG
547 x 1.25 = 684 (x2 = 1368 DPS (Only 2 marines shoot RPGs))
Hit Points
900 x 1.25 = 1125 (x 7 = 7875 Hit Points)

So, as you can see, upgrading can make a huge difference in the game. The base Marine Squad does 66 DPS with 4320 hit points, and the ODST Squad does 120 DPS with almost 8,000 hit points. Pretty awesome!
If you have an ODST Squad that happens to have gained 3 Stars of Veterancy, they’re even more powerful:
Assault Rifle
17.2 x 1.15 x 1.25 x 1.35 = 33.4 (x 7 =234 DPS)
RPG
684 x 1.15 x 1.25 x 1.35 = 1337 (x2 = 2674.5 DPS (Only 2 marines shoot RPGs))

But Wait, there’s more! A 3 star unit takes a lot less damage from incoming fire as well! Using fourth order vector calculus, we can see where that gets us:
1125 x (1/.87) x (1/.8) x (1 / .74) = 2183 hp (x 7)= 15282 effective hit points with 3 stars

Here are the stats on the Covenant Banshee:

A brand new banshee with no upgrades has 3258 Hit Points and does 90 or 60 DPS depending on which weapon it uses.
With the Boost upgrade:

Plasma Cannon
90 x 1.25 = 112.5 DPS
Fuel Rod Cannon
60 x 1.25 = 75 DPS
Hit Points
3528 x 1.25 = 4410 HP
The Repeating Cannon upgrade adds health and increases the damage of only the Fuel Rod Cannon (It has no effect on the Plasma Cannon).

Plasma Cannon
90 x 1 = 112.5 DPS
Fuel Rod Cannon
75 x 1.25 = 112.5 DPS
Hit Points
4410 x 1.25 = 5512.5 HP
The Sacrifice Ability adds the 1500 DPS suicide dive as well as health and damage to everything else

112.5 x 1.15 = 129.3 DPS
Fuel Rod Cannon
112.5 x 1.15 = 129.3 DPS
Hit Points
5512.5 x 1.25 = 6890 HP

So by the end of the day, upgrades can make a huge difference in the combat effectiveness of units.

The third tab of the spreadsheet has the Weapon Type/Armor table. It details how much damage each Weapon Type does against the various armor types in the game. Each weapon’s type is along the top, and its damage multiplier against each kind of armor is in each column. I hope that this guide has been helpful and players can use it to help them with their strategies and tactics.

Lessons Learned

Post Mortems feel right, though. We’re supposed to look back on what we’ve done and talk about how it can be better, right? Unfortunately, we never feel good at the end of a project. We’re tired. We’re angry about some feature that had to get cut. There’s no regular Red Bull left in the fridge, only that Sugar Free crap. It’s hell! We’re in no mood to think logically or be constructive.

And what comes out of Post Mortems? That’s right. Lessons learned. Thus, by crafty logic, any so-called learned lessons are similarly indictable offenses. What chance do we have to get any decent feedback on improvements when all we want to do is drink until we throw up in the corner of our favorite German beer establishment? Or sleep. Take your pick.

Final Bier Garten Day

Despite all my blustering, three guesses as to what we did after Halo Wars finished. You’ll only need one if you’ve been paying attention. Yup, we did a post mortem! Hell, we even did a two-fer. One on Halo Wars, one on Ensemble. Fun incarnate, I tell ya.

I hope someone has read those post mortems because I haven’t. Instead, I’ve been trying to focus on what we’ve been dealing with on Halo Wars over the last 6 months. Where has our patch time gone? What are the fans saying? What cut feature do I really miss? THAT’S THE STUFF TO REMEMBER. That’s the stuff to focus on first, in my opinion.

So, without further ado, here’s a rambling list of the things that have been grafted into my brain regarding Halo Wars.

1. Good gameplay can work on any platform. If something is fun on one platform, it stands a really good chance of being fun on another platform. Sure, you’ll spend a lot of time finding the perfect control scheme and making endless tweaks to the game. But, good gameplay is good gameplay. Start with good gameplay you know and then go from there. If you’ve followed Halo Wars, you know that we started the project by making Age of Mythology playable with a gamepad. Once we had that, we knew we had solid basic gameplay to rely on. That was essential.

2. Halo is HUGE. It’s hard to understate or underestimate this. Everyone knows Halo. Admittedly, not nearly as many know the difference between Halo and Halo Wars, but that’s beside the point. It was a surreal, humbling experience working on something associated with Halo.

The Chief never reminding us what was up on the way in to playtest.

3. If you’re going to work on someone else’s IP, you have to immerse yourself in it beyond just being a ‘fan’. This sounds kind of obvious when you read it, but it took us a while to figure it out. Most of us were pretty hardcore Halo fans, but that wasn’t enough. We had to understand the motivations behind the existing characters in order to create compelling new characters. We needed to realize where the canon was flexible in order to squeeze in the things we needed. And, in a few cases, we decided to go against canon to make a better game/experience (e.g. the Spartan’s shield and sound). I don’t know how we would have made those calls without tons of research, chats with Bungie, etc.

4. Sex appeal still wins. Be it an E3 demo or getting dragged into your bud’s living room because “YOU GOTTA SEE THIS”, cool graphics are always sexy. Doubly so because it’s a console game. Triply so because it’s a Halo game. While there are healthy debates about the relative balance aspects, no one forgets seeing the Arbiter ride a smashed Hornet into a cliff or MAC’ing that enemy Scarab. People crave memorable game moments; graphics are a critical tool in that proverbial box.

5. Console cert processes are a confusing black hole. We finish. We think. The discs get sent off. Time passes. Sometimes more, sometimes less. Sometimes it’s a good answer, sometimes it’s not. We were lucky that the Microsoft Game Studio testers we had were so good; they saved us countless headaches that would have killed us in cert.

The banner still flies high.

6. Balance is never over. Ever. Well, maybe if the Arch of Time collapses and the continuum implodes. But, then the Lord Foul is probably still pissed about those OP Gremlins.

7. Passion beats Talent. Team beats Individual. Finishing Halo Wars was the hardest thing I’ve ever done professionally. For so many reasons, the project was just a ton of work to get out the door. Amid uncertain futures, the Ensemble team pulled together in a way that exceeded every possible expectation I had. I’m proud to say I worked on Halo Wars just because of that.

We tried to avoid this.

Well, there you go. Those are the big ticket items I’m going to remember from Halo Wars. I suppose you can call them Lessons Learned if you really want to. 🙂

dave
Dave Pottinger
Lead Designer on Halo Wars

Halo Wars Playtesting

One of the great Ensemble traditions that we’ve carried forward to Robot is universal company playtesting. We try to get our games up and running as soon as possible, get an early version into playtest, and iterate based on feedback. Everyone is expected to help test and offer constructive criticism, find bugs, and be familiar with the high-level concepts of the game.

I was a late addition to the Halo Wars team, joining up for the last six months. Halo Wars had been a long project, and needed an “all hands on deck” approach to get the game to the level of quality we wanted before it went out the door. As a designer, I wasn’t as important an addition as the extra programmers and artists that were rolling onto the game, so my job was to pick up secondary tasks from other designers who were overloaded. I ended up with a grab-bag of responsibilities, such as writing a bunch of the battle chatter for the Covenant units and organizing the game’s many text assets for voice recording sessions.

The 15th Floor Playtest Lab.

In addition, along with Kevin Holme and a few other folks, I ended up running a bunch of playtest sessions. This was something I’d done a lot of back on Age 3 and Warchiefs, though I was out of practice. Justin “Bear” Rouse had been handling most of the playtest sessions for Halo Wars, but he was busy fixing bugs on the multiplayer maps. The end of the project required us to keep our fourteen playtest seats busy all day long, so running playtest was a full-time job in itself.

Managing a Halo Wars playtest session was a lot like herding cats. Some of the playtests were scheduled, but late in the project, a lot of sessions would get called on an as-needed basis. I’d page for testers over the intercom, but since everyone had other responsibilities, I’d often only get four or five people on the first call. Usually a second page would fill the rest of the seats. If that didn’t work, I’d start walking around the office – it was hard for my co-workers to turn down a personal request, especially if I groveled.

Often we needed to test specific game features. An artist would come down, excited to take on their office mate in a 1v1 multiplayer match – only to be told that I needed him to run through scenario six on easy difficulty level. A group of testers might get asked to keep playing the same map over and over again with one particular Covenant leader, trying to find an elusive out-of-sync. For traditional QA folks, this was familiar ground – their primary job was to find bugs and play the same content over and over again. But for the rest of the team, the playtest process often felt like a grueling slog.

The 16th Floor Playtest Lab.

Toward the end of the project, Ensemble faced the closure of the studio. We wanted to make Halo Wars a great game and go out with a bang, but we were also under enormous pressure. The studio’s imminent demise definitely made for a few grumpy playtest sessions, but everyone remained totally professional throughout the difficult process. The feedback we got from those final sessions proved to be invaluable in helping us make the last few tweaks to the game.

Though we’re slowly developing our own identity at Robot and re-evaluating our old ways of doing business, we always assumed we’d continue to playtest our games early and often. Our new test lab may be eight seats instead of fourteen, and it may not have mood lighting and fancy automatic window shades (or, in fact, windows at all), but it’s still where the development magic happens.

The new Robot Entertainment Playtest Lab.

But before we could turn over the test lab to Robot’s new games, we had some Halo Wars business to attend to. About a month after we settled into our new office, the playtest kits were humming and the first cut of the Halo Wars DLC was ready to go. One afternoon, I was in the middle of working on a design problem when I saw Justin heading in my direction.

That day, it was his turn to herd the cats. I’ve been in his shoes. I immediately knew what he was going to ask me. I knew what exactly what I had to say to make his afternoon just a little bit easier and help make the Halo Wars DLC just a little bit better.

“Sure – I’ll come playtest!”

Halo Wars Dev Blog: Leader Powers Part Four

Rage

The Rage power started with a pretty simple idea: the player should feel like a badass while killing things with the Arbiter. Easy enough, right? Having just come off of getting the basics of Cryo done and understanding some of the nuances of our code based powers system, Rage became a prime example of prototyping a radical idea really quickly to evaluate how fun it was before investing serious effort into it. I really wanted the player to feel like they were in control of the Arbiter, that they could steer him around and direct him to attack. I felt like it was necessary to try a much more direct control scheme, something closer to the traditional console experience.

It didn’t take much time to get something up and running, showing the Arbiter running around and teleporting to attack by flicking the right analog stick. It turned out that controlling the Arbiter like this and hopping across the battlefield in a matter of seconds was just crazy fun. I knew we were getitng somewhere when I could bring a coworker over to my desk to try it out and the result was a giddy smile on their face and a thirty minutes of brainstorming ideas on how to improve it. That process of just excitedly throwing ideas around with fellow gamers is absolutely one of the best parts of game development.

Arbiter’s Rage power is the only way he can hit Air units.

There were certainly a lot of difficulties with Rage, not least of which was the fact that our simluation was made for indirect movement of units via commands, not at all for direct control of a unit. Plenty of complications arose around our pathing and obstruction systems, such as how to address pushing up against static and dynamic units, what to do when the unit got stuck, etc. Additionally, we started to question how asychronous we could make the control of the Arbiter on the local player’s machine to make input tighter (check Marcin Szymanski’s dev diary about how this was solved for Cleansing). This was a very complex problem, since there was more state to simulate with the Arbiter than there was with a beam. Given where we were in the lifecycle of the project and what we felt it would be irresponsible to take on work that we couldn’t polish, and instead work inside the system we had in place. In that regard, we actually solved the problem of the Arbiter’s movement in the opposite way of the cleansing beam (a little ironc, since the Arbiter has more complex movements). The Arbiter is actually controlled the same as any other units in the game: the controlling player sends movement commands to all connected machines, and each machine simulates that command in a synchronous manner. There’s a little bit of delay there, but I think the compromise was worth it.

The power only improved in quality as we added in camera shake, controller shake. particle effects, impact decals on terrain, sound effects, and serious area of effect damage. The initial versions of all of those were a little overpowering, but they certainly were fun. A good amount of custom code went into pacing the actual movement of the Arbiter, and really nailing the speed at which you could jump from one target to another. It needed to be quick enough that you felt powerful, but not so quick so that you felt totally out of control. Throw game balance into the mix, and adjusting that speed and pacing became very important. Because of those pauses between jumps, we focused on making each individual jump feel as impactful as possible. The Rage power actually had quite a few complex code systems interacting within it, marking the first power that had variable cost based off of the action that was executing, as well as the most elaborate upgrades within the leader powers. (the final upgrade of Rage is just so powerful).

There are lots of interesting edge cases with the Arbiter’s Rage power.

The final piece of the Rage puzzle happened during what I can only describe as the “final weeks before all polish features are done, so if you have any pet polish items you really want to get in, you *** well better do it now” phase of the project. I was pretty happy with how Rage was coming along, but when attacking air units the Arbiter would jump towards them and strike the ground underneath them, dealing damage in a clearly unfinished manner. We were at an turning point where the Arbiter either wouldn’t be able to deal damage to air units in Rage mode, or we needed to find another solution. Enter a little excitement and support from an animator, and we managed to find a way to reuse some of the code systems created for Spartan jacking to allow the Arbiter to jump onto and destroy air vehicles. It’s something that literally came together in a matter of a day or two to prove the concept. It took a while after that to polish it all up and find a good balance of the physics impacts to the aircrafts when he hit (an initial impusle when landing on the unit, and another each time he struck it). When it all came together, It was pretty awesome to see the Arbiter destroy a unit and ride it in down into the ground, reminscent of riding a bomb down to impact (Dr. Strangelove, anyone?). After all that came together, I think I could watch people destroying hornets with the Arbiter all day long in playtest laughing maniacally.

Vortex

Vortex was the final power to come online. Rage was finished enough to where we needed to seriously figure out what the final power would be, and I was ready to go with two power’s worth of implementations under my belt. I remember sitting around an office with a few other people throwing out ideas on what direction we wanted to take the Brute’s power. Inspired by some of the modal controls from Cleansing and Rage, we had ideas all over the board – a wave attack accomplished by swinging the thumbstick, a ground slam attack that split the ground underneath units, and even a mode where the player controlled two different gravity wells, each moved by an analog stick. We settled on a starting point: driving one gravity well around that gathered debris until it reached critical mass and exploded for massive damage. As an interesting aside – the Brute’s power was originally called Wave in all our in game text, until we came up with a new idea during implementation it, at which point Vortex seemed somewhat more appropriate and we had to go back and re localize a bunch of strings.

The initial version of Vortex did nothing more than instantly kill infantry units and snatch them up into a ball, in which they immediately disappeared (certainly quite rudimentary). Kind of like what it would look like if you dropped a black hole onto the battlefield. As we iterated on it a little more, we were fortunate enough to reuse some code in the building and vehicle destruction system added in for the Cyclops’ throw ability, specifying what pieces were able to be torn off to be used as projectiles. Prototype Vortex also involved finding the perfect amount of force to apply to the objects, somewhere between comically sending them into orbit and sadly nudging them along the ground. These first implementations were racked with bugs as we dealt with entire buildings that would go flying around the screen and even a case where the Brute got pulled into his own Vortex (a side effect of being rammed by a Warthog while casting). However, through all the chaos it showed us one thing with certainty: a power with physics effects can be *** fun.

The Vortex Leader power had its own problems as well, this situation would be very bad for the Brute Chieftain player.

One of the most interesting tidbits of information when it comes to physics in games is that a real world physics simulation is very rarely what you want in a game context. More often than not you want something that appears to be a real physics simulation, but is carefully crafted to create the effect you’re looking for. In this case we had a very specific effect we were trying to accomplish: a swirling mass of objects, not under complete control. Needless to say, many different attempts and approaches were taken to try and get the orbiting behavior we were looking for in the most general case. There were plenty of times when pieces would launch across the map, or where every piece conglomerated into a blob of polygon soup in the center of the Vortex. The final solution involved remove all object to object collisions inside of the vortex and completely disable their gravity. The ideal distance from the center and the initial force used to pull the object to the center of the vortex were dynamically scaled based off of how many objects the vortex had currently picked up, which allowed the chaotic swirling mass to very gradually grow each time a new piece was picked up. Tweaking those values and finding some creative solutions inside of the physics simulation was certainly one of the most challenging part of the Vortex power, and without a doubt the source of the most bugs.

It became important to have Vortex stand out from the other powers: it needed to have its own chaotic nature and feel in its camera and controls. We prototyped a variety of potential solutions, from a fixed camera over the shoulder of the Brute looking forward onto the Vortex to directly controlling the Vortex the same way as Cleansing. There was even a version where the player controlled both the horizontal and vertical movement of the swirling death ball with both analog sticks. As we iterated, freer camera control stood tall and I’m quite glad that we could find something in the middle, controlling similarly to Cleansing but with some unique twists. In the final version, the camera is focused on a point between the Brute and the Vortex, effectively keeping both in the player’s visibility, and the Vortex’s vertical movement is automatic in a sinusoidal pattern (which also helped to give the internal objects some more motion). Finally, Vortex employs a similar system to Rage in that its cost changes based off of the state that it is in. It is the only power that costs nothing to maintain, (only taking resources when dealing damage), and is also the only power that actually improves its potential damage the longer it is active. As the Vortex picks up more and more pieces, the power of the final explosion increases to devastating amounts, which combine with the damage inflicted by the thrown debris, providing an effect that was a bit more chaotic in nature.

The Vortex power also had the ability to throw other leaders around, getting this Arbiter stuck.

Even after all of this work, it was pretty cool to see a multitude of your enemies swirling helplessly in a wild gravity induced mass and blow them to kingdom come, but it still didn’t feel as badass as it could be. There are a lot of little polish features that really brought the effect from cool to over the top and really awesome. We gave the lightning bolts that strike down enemy units intelligent behavior to find the most effective target unit in its area of effect and added the slightest rumble of the camera and controller on each blow. We again found that adding a delay to cascade the objects that were picked up off of the field gave the visual effect a much better pacing. As each piece is picked up (or gloriously ripped off a vehicle), there is a distinctive controller rumble, a quick bolt of lightning, and a physics impulse applied lateral to the ball which starts the piece off in a perfect orbit around the Vortex. It’s a lot of little meticulous work that it seems like noone would notice, but the sum of all the parts add up to make the power just feel better when playing. It all comes together to really make the player feel like they can dominate the battlefield with a little bit of controlled chaos. One of my personal favorite illustrations of the Vortex power came from a playtest where a player started spiraling the power around in circles until the pieces got enough momentum orbiting the vortex horizontally, and he managed to time the explosion perfectly to effectively shotput a spray of tank pieces and marines into an enemy base. Not exactly the most practical attack, but you have to give the guy points for style.

Conclusion

It was certainly a challenge to try and create all the experiences we wanted to illustrate with the leader powers, especially under the gun of the inevitable deadline. We quickly learned that in order to make any of the powers live up to the intensity they needed to portray, a high level of polish was necessary. The meticulous details like adding a tenth of a second delay to an effect, a subtle controller shake, or Spirit of Fire chatter in the targeting UI may not have been overtly noticeable, but they were absolutely pivotal to taking the powers over that last step from pretty good to really great.

This early Halo Wars Development Screenshot, shows some temporary art of BorgTim, and the Orbital Bombardment Leader Power, as well as some early UI.

Being sure we had the time to add that polish meant that we were always evaluating the cost and benefit of the work we were doing. Not many people know, but there was actually a point where we were short on time enough that we talked about the potential ramifications of giving all three of the Convenant leaders the cleansing power! Fortunately, I’m very happy that a little passion and some hard working late nights from all of our disciplines let us create and finish the Rage and Vortex powers, which in my personal opinion, feel pretty *** great and added a lot of depth to the Convenant side.

Taking point on creating and polishing the leader powers on Halo Wars was a spectacular experience for me personally – rewarding because of the end result as well as the process in which we got there. The excitement that came out of the team during brainstorming and the cross discipline work while creating the powers is really the passion that comes together to make a great game in this industry. I know that I was excited to make the player feel like a badass on the battlefield in an RTS, and I feel like we accomplished that.

This other early Halo Wars Development Screenshot shows the Orbital Bombardment power in action, as well as very early base buildings.

Probably my favorite part of working on the powers was watching people play during our company playtests. Each time a new power went in or had a new feature added, it was awesome to see it immediately become the “power of choice” for everyone playing. It was easy to tell how well we were doing with the current version by seeing how many people said, “Holy crap that’s awesome!” or were laughing maniacally while devastating their opponent while trying out the new power. I hope all of you have had a similar experience when you used the powers in Halo Wars; I would certainly consider that a victory. Thanks for reading, See you on Xbox Live!

Halo Wars Dev Blog: Leader Powers Part Three

Good news everyone! I’ve decided to give you a little insight into the leader powers in Halo Wars. I’m Vijay Thakkar, currently a programmer at Robot Entertainment and was a programmer on Halo Wars at Ensemble Studios. I spent a good deal of my time working on many parts of Halo Wars, most notably the leader powers. Hopefully you after reading this, you’ll have a more insight into how we got to the powers we have in the shipping game and the game development process in general. Enjoy!

The leader powers in Halo Wars had a variety of roles to fill: they needed to illustrate the identity of each of the leaders, to stand out as different gameplay than the traditional RTS, to break stalemates in games, etc. Most apparently to me, they really needed to make the player feel powerful and dominating on the battlefield. All this needed to, of course, fit inside of an RTS world and be balanced. Quite the challenge we had ahead of us.

I personally took the reigns on the power system during the latter portion of the project. We had a few of the powers implemented via our scripting system and had recently created a code driven power system (see Marcin Szymanski’s dev diary for some history there), but we still had over half the powers to create and all of them to polish. We were in a pretty great place at that point: lessons learned from previous powers and a new system that made prototyping simpler, it was a rich breeding ground for some awesome out of the box ideas.

The actual process of creating the powers in Halo Wars was something that depended on strong collaborating from all disciplines: art, design, programming and sound. All the departments needed to work closely together through the entire process to get them right. The environment that we fostered at Ensemble Studios made this process a blast – ideas that anyone on the team had could be a source of inspiration (not just design). This made for a flexible environment where even a programmer had opportunities to contribute to the design and prototype ideas. Trying out new ideas is one of the best parts of game development, hands down.

Heal / ODST

The secondary powers (powers shared between leaders) were some of the first that actually made their way into the game, because of a necessity to demonstrate their influence on the minute to minute gameplay. They were simple in their concepts and involved a fairly basic input system – fire and forget, for the most part. Fortunately, this was an excellent illustration of the strength in our visual scripting system. Our designers were able to jump and implement a simple version of the effect they needed without lots of programmer support. Embracing the attitude of being able to quickly experiment with and try out an idea in game became pivotal to iterating towards some amazing powers.

The Healing Power went through many different iterations on whether or not it worked in combat.

Heal and ODST are great examples: they were added into the game very early and actually stayed in their initial state until fairly late in the lifecycle of Halo Wars. However, as the edge case bugs started to appear (dropping ODST squads inside of buildings, oh no!) and as we entered the polish phase of the project, it became evident that we needed to move their implementations to code. This allowed us to tailor the timing and effects to each power, gave us the chance to more easily reuse parts of the codebase that were not exposed to the scripting system, and to maintain consistency between the other powers that had been implemented in code. Inevitably, a single code path for one system produces significantly less bugs than trying to maintain multiple systems.

Early ODST pods may have been a bit strong and broke the ground.

Disruption

Disruption was actually one of the powers that was on the chopping block until the absolute last minute. In a technical sense it wasn’t a necessary power to balance the game, but not including it would have required us to scale down the strength of the other powers (especially the Covenant) dramatically, since the game would lack a direct counter. Personally, the concept of lessening the impact of any of our powers hurt me down to my gamer core. Needless to say, I was very happy to see that quick turnaround on the concept and implementation allowed us to include it in the end.

Cryo was so good at one point, it even stopped Disruption from working.

Disruption was probably the fastest power to go from concept to final implementation in game. We relied heavily on reusing pieces that we had built for the other powers: the fly by of the Shortsword bomber, the targeting UI, the Spirit of Fire sound effects, and much of the basic structure were lifted almost directly from Cryo. The unique elements were only finished in time because of fast work from everyone involved. We used a custom animation for the motion of the bomb’s arc and its explosion, the sound crew contributed to really getting the effect of the lightning crackling and the ticking down of the bomb, and programming added in the decaying radial pulse and the bolt of lightning emitted when a power was diffused (when a Covenant leader came into range, for example). Some great teamwork and intelligent compromises late in the process are what let us keep Disruption in the game, and helped keep the other powers as strong as they are.

Cryo

Cryo was the first of the major leader powers that had a high level concept where I was able to work with the design team to try out some ideas out and see inspiration took us. The concept behind Cryo was to create something that illustrated the very scientific nature of Anders’ character via a freezing effect. On the surface, Cryo doesn’t appear to be as powerful compared to the other powers, and that is because it was coined as a support power. It was designed to really shine when combined with an army or with another player’s powers (the exception being air units, which it can be particularly devastating against). Armed with some ideas on how to make freezing feel awesome in an RTS, I cracked my coding knuckles and jumped right in.

Cryo also froze entire Firebases into blocks, sometimes unintentionally.

The first implementation of Cryo felt astonishingly bland, however. The first design dropped down a persistent whirlwind-style area of freezing that gradually froze any units that got stuck inside of it. Unfortunately, this presented as a pretty confusing mess to the player, not fully understanding why their units were sometimes freezing and sometimes not, and not fully understanding what the penalty was. For a variety of reasons, it just didn’t work. We had to iterate on the design of Cryo quite a bit to get the effect somewhere that really felt as good as it needed to.

We really started to get there when we took a fundamental shift to making the power closer to an instant effect. Even with that change, something didn’t quite feel there. Once we tried cascading the freeze effect on the unfortunate units that were to be frozen is what really started to make the effect shine. Essentially, the instant the power goes off (with that oh-so-satisfying ice explosion sound), all units that will be affected are found, and we freeze each one individually from the center to the outer edge with a very slight time delay between each unit. The whole effect happens in under a second, but that heartbeat between freezes helped tremendously to give the power a better execution time line.

Cryo is the bane of every air unit, even Pelicans on your side far away from the bomb.

However, the complexity of the power quickly started to spider web out because the Cryo power was created after the wide majority of the units were completed. It became evident that many different pieces of the simulation would need to be touched to really support the concept of being frozen. What happens when you freeze a spartan that is in the middle of jacking a vehicle? How about if you freeze a reactor? Or a unit that is in the middle of walking out of a base? (Sadly, the first implementation answered the last question by having the unit permanently stuck inside of the building. Doh.) All of those problems needed to be solved and then implemented. Before we were finished, we actually customized our entire building and unit destruction system to include the concept of a ‘frozen’ part, containing slightly different behavior than parts that were normally thrown off. That is what allowed frozen tanks and frozen air units to break apart into chunks of ice that felt heavier and more dense instead of sending their parts everywhere, in the case of a normal explosion.

Once the larger pieces were solved, a little tightening up of the visuals got the power up to a level that really made it feel awesome. By that point, another programmer had finished the necessary code work to render an additional material layer on the units (an effect we also used for the Mac Cannon’s targeting system) which let us put an ice texture on frozen units giving a stronger effect than cold particle effects alone. Frozen air units were given the appearance of struggling to fly via physics impulses, and their instant kills were cascaded over a short period of time (similar to the initial freezing effect) , and the power really started to tighten up. I think we knew we finally hit the mark when it felt awesome to see a flock of banshees attacking your base, because you knew you could send them to the ground to shatter under the force of a fully upgraded Cryo bomb. Beautiful.

Well, that’s all for this week. Tune in next week for more about the Arbiter’s Rage and the Brute Chieftain’s Vortex. Thanks for Reading!

Leader Powers Part Two

MAC Blast

This was a really fun power to work on. Ok, I actually liked working on all the powers, but how awesome is it to fire a giant sniper round from orbit? This actually brings me to my first point: the initial version of this power, while very impressive, wasn’t quite differentiated enough from the other powers. It also lacked a certain feeling of impact and focus. Finally, the size of the blast was so large and overwhelming that it didn’t work very well for a design that called for shooting multiple MAC blasts in a short period of time.

An Early Minigame version of the MAC Blast, hitting the buttons at the right time improved the power of the MAC Blast.

We decided to compact the effect into a smaller area and speed up the overall visual. The faster the visual appeared to slam the round into the terrain, the better the power felt (see sniper rifle comparison). The final iteration had a near-instantaneous effect that dealt damage right away. I think that this really distinguished it from the other powers, and made it very satisfying to use!

There was one thing missing after we got this far: the impact of the MAC round didn’t seem to leave enough of a footprint; it didn’t feel like it did enough damage to the terrain. Without going as far as to demolish half the planet with a single shot (I’m lookin’ at you, canon holders ;), we decided it would be cool to try throwing boulders out of the impact point. I had spent a great deal of time working on Age of Empires III’s building destruction system, so I hacked together a quick test to see whether we could make a rock break apart in a similar way on impact. To my surprise, it worked on the first try! The boulders flew out, they shattered into pieces, and KABOOM, the game crashed! Ok, maybe it didn’t quite work on the first try. Regardless, we thought it looked cool enough that I spent the time to polish it up into a shipping version. So now, when you see those rocks breaking apart, you’ll know that they’re just buildings masquerading as rocks.

Transport

Transport may not be the flashiest power in the game, but it probably took the largest amount of development time overall. It was passed around among a few programmers, went through several design iterations – you used to control the transports directly! – and it had to work seamlessly with many other game systems.

The Covenant at one point had Spirits to transport their units, and their Powers were more similiar to the current UNSC than the Leader based ones they have now.

The initial implementations weren’t quite robust enough to account for many edge cases. For example, what happens when you try to transport a vehicle, but that vehicle is commandeered or hijacked by a Spartan while the transport is en route? What should the transport do when it reaches its pickup targets and they’ve all been Cryo’ed? Many of these questions had no obvious answers, so a few times we just went with the faster and easier solutions.

Transport always had lots of interesting edge cases, and sometimes they were quite unexpected.

One of the common cases where Transport failed with some frequency was when unloading troops into a congested battlefield. It was essential that this worked, because several scenarios relied on Transport working every time. Scenario 6, in particular, had many bugs due to Transport breaking in some way. I tried several tweaks to address the unloading problems, but eventually decided that the code would need a partial rewrite. I had hesitated because this was very late in the project, and it was risky code to change at that point, but we decided that it was still the best avenue of attack. Thankfully, we had some code from the Age engine that did a very good job of finding empty spaces for units. I retrofitted Transport with this code, and the vast majority of our unloading bugs disappeared.

Closing Thoughts

One major element that we wanted to add to the leader powers was some sort of arcade-style timing. We actually brainstormed some cool minigames, unique to each power, that would allow a skilled player to add a small boost to each power. For example, we prototyped a “golf swing meter” input method for MAC Blast that allowed an expert player to crank out a perfectly timed series of max-quality shots. Unfortunately, the realities of scheduling meant that we had to cut this feature – implementing the full array of minigames, in a polished and fun way, would simply have taken too much time.

After I finished my work on the Halo Wars power system and several of the powers, I went back to working on Top Secret Prototype Team™ (the last prototype Ensemble would do, actually). Another programmer, Vijay Thakkar, took up the mantle and implemented several more powers. He will talk about his experiences in his very own blog entry.

Just like with Age of Mythology, working on the leader powers was extremely gratifying for me. Developing these kinds of gameplay systems relies on a well-oiled feedback loop that incorporates input from art, design, sound, and programming. It also requires a very broad kind of thinking, and when all cylinders are firing, progress on iterating cool new ideas is nothing short of astonishing. I hope this blog has provided you with a little bit of insight into how this process works. Thanks for reading!

Leader Powers Part One

Script vs. Code

Halo Wars is a game about tactical control of dozens of military units, but we decided early on that we wanted to have a series of over-the-top “signature” abilities for the various leaders. These would serve a dual purpose: amping up the console nature of the game, and adding a way to help break stalemates.

We initially prototyped most of the powers in Halo Wars’ strong visual scripting system. This allowed us to get the powers up and running very quickly. It also helped us quickly iterate on the gameplay, because designers could jump right into script code to modify each power.

There were some areas, however, where the scripting system was slowing us down. It didn’t allow for very precise control over power execution, it didn’t support cool programmatic effects, and it was very difficult to debug. Being the greedy developers that we are, we decided that we wanted more! We could have retrofitted the scripting system to support the needed functionality, but it became clear that the right direction was to move everything into native C++ code.

I had a lot of experience working with the god powers in Age of Mythology, so I was asked to help out with the Halo Wars leader powers. When architecting the new power system with another programmer, I applied several of the lessons I learned years ago. For example, the system would need to allow for a lot of data-driven customizability for rapid iteration of each power’s gameplay and visuals. I also knew that it would need to support a variety of user interface modes to address each power’s unique needs. So, I opened up a blank sheet of code and dug in.

Once we got most of the fundamental systems in place, we began moving the powers from script into code. By the end of the project, I touched practically all of the powers in some way. In the following sections, I talk about a few of the powers where I spent the most time. Enjoy!

Cleansing

The script-based version of this leader power did its job well enough, but it wasn’t very satisfying to use. The beam was controlled like any other unit: you scrolled over to a spot on the ground and gave the beam a move command. This felt very indirect and just not badass enough. I decided to give the player direct control over the beam.

One problem: Halo Wars is a peer-to-peer synchronous game. When a unit begins to move on your screen, it’s after the move command has bounced across the internet and back. This meant that the beam still felt too sluggish to control.

An early version of the Cleansing Power, and a mock-up Covenant Base.

The solution? Split the beams! This is sort of like crossing the streams, except in reverse, and it doesn’t cause every molecule in your body to explode at the speed of light. The way it works is that the player controlling the power only sees a fake beam that reacts immediately to controller input. This fake beam exists only on the caster’s Xbox and deals no damage (if it dealt damage, the game would immediately go out of sync). However, there’s also a real beam that follows the fake beam. This real beam exists on every machine and is updated synchronously (i.e., it’s in the same place on all players’ machines), but is invisible to the casting player. The second beam is responsible for dealing the power’s damage to enemy units, and trails the fake beam by a meter or two depending on network latency.

The split described above is why it works so well to lead a moving target with the Cleansing beam – the real beam is just a touch behind the beam you see on your screen.

Cleansing was always one of the harder things to get to look right.

Carpet Bomb

This power illustrates one of the main advantages of going to code: we were able to have very specific input handling and UI feedback for targeting the power. The arrow that you use to target the power would have taken significantly more time to implement if we’d tried to go through script.

The bulk of the work for the power’s delivery was spent on customizing the blast pattern. We didn’t know right away what kind of pattern we would want for the cluster bombs, and we didn’t know how it should upgrade. My approach here was to make a very customizable pattern, with the ability to configure everything from its length to the size of the intro “wedge” for the pattern’s shape. It was pretty basic stuff, but it allowed the designers and me to experiment with several different looks for the power as it upgraded through its stages.

The aiming arrow for the Carpet Bomb.So, I had this blast pattern worked out, but the initial version still didn’t feel very cool. In that version, the bombs dropped down and exploded instantly, dealing damage right away. It felt bland, as if there was something missing about its tempo. Maybe it was too slow? Too fast? Eventually, I started experimenting with a dual-stage approach – bombs impact, then explode a few beats later — and that started to feel tons better. By splitting the impact from the explosion, we got a cool little chunk of tension after the bombs drop, but before their explosion sends everything flying.
The carpet bomb’s devastating effect on Warthogs.

Tune in next week for the next part in our Leader Powers Dev Blogs. Marcin talks more about the Mac Blast and the Transport Powers, along with more never seen before screenshots, including ones from Halo Wars Development.

The Birth of a Halo Wars Mission

The first thing we do when we start a new campaign is to do some research. Instead of hitting the history books like in our Age of Empires games, we grabbed anything we could from Halo and absorbed it. We read books, played through the games, and talked with Bungie to make sense of any questions that arose. I personally spent a few days doing nothing but playing the Halo campaigns in the office to refresh my memory and get some inspiration. This helped more than I even hoped… people would stop by my office to watch me play and learned some things they may have forgotten about the games – or to yell at me to turn it down!

The content designers got together and brainstormed. At this point the story was still in the works, so we threw out crazy ‘what-if-we-could-do-anything’ ideas. For example, I really wanted to do a mission where two Scarabs were destroying a city, and the player’s job was to stop them before a certain number of buildings were destroyed. That ended up on the cutting room floor with a bunch of other cool stuff, but the process gave us a lot of good gaming fodder – we ended up morphing that idea into the Super-Scarab in mission 07. So, once the story started becoming more concrete we found places to use those ideas.

Unfinished Super Scarab in Mission 7

The missions don’t live alone though, they have to work well within the campaign as a whole. Through a series of designer meetings we made an outline of all the missions for the whole game. We decided how many there will be, what the story is for each, and hashed out the gameplay. We also went through the Ensemble tradition of “the scenario auction.” We list all the missions on a whiteboard and “barter” over them. The idea here is that the designer who has the most interest in any particular mission will fight for it the most and will end up doing a better job in the end – basically “do what you love”. We looked at the missions on the board and made sure we had a good mix of gameplay without being repetitive.

Once the mission ideas are set and assigned to designers, it’s time to start production. The designers go off and write what we call “Tear Sheets”, which are quick and dirty summaries of the gameplay with the art and sound requests for the mission. These get reviewed for sanity, then we make drawings and quickly sculpted versions of the missions in our editor.

A “Tear Sheet” and a quick editor mockup.

Usually the missions are the last things to get “done” in our game. They are mocked up, triggered, and tested, even in this very preliminary stage, by select people that can handle the hacked-in nature of them. We got here very early and had to wait for the rest of the game to catch up, not to mention dealing with any rewrites or game design changes that derailed our mission designs. I used to joke that being a scenario designer is like being on a submariner’s schedule – 6 months of not much to do then 6 months of bone-numbing work in the last months of the project, when the pressure is on to polish up the missions to their final state and ship them.

The mission designers also affected the game’s story during this time. The story was written by the lead story designer, but the mission designers are the ones that have to make it feel real when you play the game, so they requested changes to make the playable part of the story seam up to the cinematic part. In this case, we had the benefit of working with Blur on the game’s awesome videos so we got to use their stuff for inspiration as well. For example, the Spirit of Fire’s hull was used in missions 11 and 12, which Blur had a big part in designing – we actually requested the upper deck of the ship be redone so Marines and Spartans could walk on it. Blur did this on the high resolution model for the ship, and our artists matched it in our missions.

Spirit of Fire Model in Mission 11 and 12

In previous games, the designers had to do a lot of the texture painting and beautification in the missions, but for Halo Wars we decided it was time to let the artists loose on the missions, and the results were awesome. First they did concept paintings based on our designs, then once we had tested the missions to a point where we knew they were not changing, we handed them over to the artists.

An artist’s mockup of mission 15.

Concept art for the Relic object in mission 03.

Now we’re in the home stretch. And that means “test, test, test, and test some more.” Although we don’t change the missions drastically during this step, we do thousands of little tweaks based on feedback. We run round the clock playtest sessions and beat on the missions, finding every possible way we can find to break them and ways to make them more fun. It’s a cool time as a designer because you baby is starting to walk here. The art, programming, and design all [hopefully] come together into a fun, interesting, and memorable experience for our customers.

I, and all the other designers on Halo Wars, hope that you really enjoyed them.

Joe Gillum, Designer

What it takes to make Halo Wars art, look like Halo?

I have to admit that when I heard we got the Halo IP for our first console RTS, I had never played Halo or Halo2. Mainly because I never owned the original XBOX and my 360, that Microsoft handed me for free, was still in the box! Now, I had nothing against consoles, but when you’re married and you only have one TV, not many wives want to watch their husbands play games, so I was stuck with playing on my PC. Turns out many of our artists had not played either, so we had a lot of catching up to do with those games.

First thing we always do is start gathering as much reference material as we can find; downloading screenshots from the internet, getting marketing material from Microsoft, and the most obvious one, asking Bungie for all their art files. That last one seems like a no brainer right? After all we are both part of Microsoft and they own everything, right? Nope. As it turns out it’s really hard to get in contact with someone at another studio to provide assistance, when that company was behind schedule on their latest installment of Halo AND we had no idea about the negotiations they were having with Microsoft about becoming an independent studio again. It didn’t take long to realize that our concept department would be on their own in figuring out this art style.

So the big question was: What makes Halo, Halo? Well you have to start making mistakes to learn from and it didn’t take me long. I got the concept for the Covenant DropShip, modeled it, textured it, and got it in game, but since I still had not played any of the Halo games yet, I had this thing flying in the wrong direction! Yeap, I had my home 360 setup with Halo2 that night.

We had a lot of iterations early on trying to nail down the look of our models and materials, but with time we put some simple guidelines in place that kept all our artists following a consistent process. In fact most of our iterations on the art came more from design changes than style flaws.

The UNSC and Forerunner had to maintain the same geometry angles throughout their structures and vehicles while the Covenant had to maintain the same curvy organic look in theirs. The UNSC vehicles and Spartan armor all had a similar green metallic look that we tried to emulate with our materials. Using a similar Army green with a broad, gold, specular highlight worked really well for our camera distance and sun angle.

To get the Covenant right, we broke down the look of the alien armor by creating a purple base color, with a tighter, orange specular highlight that included a honeycomb pattern and then added a blue, inverted honeycomb pattern for the reflective property. We then added the trademark tiny, blue lights and that was pretty much it.

As we finished models and exported them into the game we always had to ask the question: Does this unit look like it belongs with all our other units? We had scenarios saved which contained every single UNSC/Covenant building and unit, so it was fairly easy to spot the units that needed more work to get the look correct. Most of the problems we had were more related to our memory limitations verse what the concept actually looked like on paper.

One thing we did that worked out extremely well was the decision to define and limit each races player color. I think this mainly came about because it just didn’t seem right to play the Covenant as the green player, because everyone knows that color belongs to Master Chief. So to get back to the question, what makes something Halo? I believe the answer applies to any IP someone would try to recreate; break things down to the smallest details, derive a process to keep those small details throughout, and always keep comparing your current progress with progress already completed.

Paul Slusser, Artist

Animation Exploration

There are two animations I want to focus on in this production diary. I want to highlight these because I took time to thumbnail and choreograph them; which is typically something I don’t have time to do at a video game studio. So, I really tried to get it right. Both of these are exploratory animations developed to have a loose visual guideline for what the fatality system would look like. Fatalities in Halo Wars happen when one awesome melee powerhouse, such as the Arbiter, kills one of the other infantry units.

The first exploratory animation I was tasked to do was the Arbiter taking out a squad of marines. I soon got the idea that I would portray the Arbiter as an unstoppable shocking killing machine. And the marines would be dumbfounded and unable to react because they were paralyzed by fear and the ferocity of the Arbiter.

I was going to do a lot of drawing/thumbnailing to plan out my shot and I wanted to make sure that I knew how to, at least, crudely and quickly draw the Arbiter. That’s where this first page comes in as it was my attempt to understand how to produce quick gestures that I could read.

The next set of drawings was a loose choreographing of the massacre. I had the Arbiter twirling, twisting, spinning, and all other sorts of acrobatic movements that would make him appear graceful and bloodthirsty.

As thumbnails go, they are just a guide, and as much as I adhered to the drawings I also strayed from them. The Arbiter is pretty much pose-to-pose animation, and the marines are all straight-ahead animation. Here is the result:

From this animation we learned that all fatalities will be done one on one: person killing person rather than person killing a squad or groups of people. It would have been too much unique work to animate the fatalities in such a way where multiple people are killed. The fatalities also locked the attacker and victim in game while they played their animations. And only once they finished could the attacker be selected and moved by the player. (Which is really the only way you’re going to see the animation.) So, on average, we limited fatalities to three seconds, but never going over five seconds. This gave us enough time to create something worth seeing, and thus, losing control over your character for 3-5 seconds.

The next task in fatality exploration was to pit hero against hero: Arbiter versus Spartan. I wanted to make the Arbiter as swift and savage as in the first animation, but this time, his foe would prevail. Portraying the Spartan as instinctual and reactionary rather than purely dexterous: he moves fast and hits hard.

Once again this first image was done to get to know the subject, and to be able to draw him to quickly plan out the fight sequence.

Again, these thumbnails were a loose choreography guide to follow while animating.

The attacker is pose-to-pose and the victim is straight-ahead reacting to the blows. Here’s the result of the planned work.

Unfortunately, the animation workload over the course of the project never allowed us to do special case (hero vs. hero) fatalities. Rather, we had to reuse the victim’s animation and copy it on to the different heroes. Though, if we did have the time, animating hero vs. hero would have been really cool to do!

Neither one of these exploratory animations was ever taken to a true final stage. I only took them to a certain quality level of animation; setting the bar as high as I knew I could reproduce under actual production deadlines.