Ensemble’s Halo MMO cancelled due to Microsoft wanting to pursue “Wii” like experiences
Dusty Monk has been continued his talks with IncGamers this time expanding more on the cancelled Halo MMO codenamed “Titan” and believed to be titled Halo Universe. Confirming much of what we have read before that the change of management at Microsoft did not believe investment in the project was strategic and wanted to re-deploy resources in other games. The Halo MMO was upwards of a $90 million dollar project and there was even talk of new offices being built to support the studios MMO. However sadly the project didnt see the light of day other than some very early screenshots and concept art.
“There was a bit of a changing of the guard at Microsoft at this time, Microsoft, from its gaming division, was really changing directions. They were looking really hard at the Nintendo Wii and they were really excited by the numbers that the Wii was turning. This was about the time that Microsoft decided that its Xbox platform and XBLA really needed to go more in the direction of appealing to a more casual, broader audience.”
According to Dusty the MMO was going to compete directly with World of Warcraft by Blizzard Entertainment. Ensemble had taken on Blizzard in the Real Time Strategy genre with Age of Empires competing against Star Craft. The next step was to compete in the MMO space.
“It was going to be the Halo MMO, and it was absolutely going to compete against WoW. You have to remember that Ensemble came from a standpoint of being really good at competing against Blizzard Entertainment. We had a pretty good history of knowing the types of stuff that Blizzard put into their games to make them really successful, and the kinds of things we’d need to put into an MMO to compete against Blizzard
Just to give you a couple of examples, we were using a heroic stylised artform. This heroic stylised artform is exactly the artform that you see being used in Star Wars: The Old Republic right now. It’s timeless. It doesn’t age itself like a game that’s built with a strictly realistic artform does.
We were developing a cover system. This cover system is in Star Wars: The Old Republic. We had the idea of quests – and like I said, this was between 2004 and 2007, before Warhamer Online had been released – but we had this idea of quests where you could participate and pull them together without having to be on the same team. This would be a public quest that everyone in a particular area could work on. That idea went into Warhammer Online.”
Certainly sounds like a very exciting and thought out project. The game had been in development between 2004 and 2007 so a huge amount of work would have been put in by the studio. Once the team was informed the project was to be cancelled Ensemble lost a few key staff who later went onto join other studios to work on MMO’s. One of those was the now famous Gregg Street who joined Blizzard Entertainment.
“We had all this incredible talent, we had the right people, the right passion, we had a phenomenally successful IP – the Halo IP.”
The talent at Ensemble Studios would of been perfect for the MMO project. Looking at how Ensemble built up successful RTS games I have no doubt the MMO would of been incredibly successful as well.
“Even though a lot of people talk about how you just can’t build a WoW killer, I absolutely believe that we could have built an MMO, if Microsoft had maintained their commitment, that if it hadn’t been a WoW killer it certainly would’ve competed.”
All is not lost though. If you are after an MMO keep your eye on Windstorm Studios, Dusty Monk’s startup company out of Ensemble Studios. They are working on a single player RPG at the moment and if successful will launch into a full blown MMO. I look forward to seeing what the great minds at Windstorm come up with. Be on the look out for updates on the project later this year.
Meanwhile stay tuned also for the full interview with Dusty Monk on incGamers where there will be more talk about Windstorm Studios.
To read more about this article head over to IncGamers:
http://www.incgamers.com/News/21928/cancelled-halo-mmo-details
More Ensemble Halo MMO concept art revealed
Dylan Cole an artist who worked with Ensemble Studios on the cancelled Halo MMO has made some concept art and paintings available from the project on his website. The incredibly detailed images show what the game environments may have been like if the project saw the light of day and Ensemble was still with us. Take a look at this outstanding image showing what a Forerunner City may have looked like in game:
Incredible art
And another showing a Halo City from a distance:
If in game graphics were 1/5 as good as these outstanding art pieces the MMO would of been a marvel to play. It is a great travesty that executives at Microsoft pulled the plug on such a promising game. I recommend that everyone check out Dylan Cole’s website for more Halo MMO art plus more incredible pieces from his other projects:
Dusty Monk talks about Ensemble’s cancelled Halo MMO “Titan”
Dusty was a senior programmer for Ensemble Studios who worked on the Ensemble Halo MMO. He sure seems passionate about the MMO genre and he reveals lots of information about the project including the length of time the team were working on it – 2 years in fact. To have an insight of what Ensemble was doing between 2006-2007 have a read here:
http://ofcourseillplayit.com/?p=131
A reminder of Titan..
In case youve forgotten or arnt aware of Ensembles Halo MMO here are some of the very early mock-up designs:
Windstorm Studios’ MMO on hold – focusing on single player RPG instead
Windstorm Studios who are headed up by ex Ensemble programmer Dusty Monk has long believed to have been at work on a futuristic MMO game. There were even some concept art pieces released which can be seen below:
However in an interview with Inc Gamers, Dusty has revealed that the above project has been placed on hold, at least, in its MMO form that is. Instead Dusty’s Windstorm Studios will be pursuing the project in a Single Player RPG form.
“The plan of attack right now is to go forward with a smaller single-player game, and get that out there for people to start playing,”
Why the change of plan? It seems there were problems getting publisher commitment to the MMO project. We know from the past that MMO games have been a touchy subject with publishers including Microsoft who decided to cancel Ensemble Studios’ Halo MMO. Because MMO games are very expensive and take massive development time it can be difficult to get publishers to commit to new games based on new, untested intellectual property. Instead Windstorm are taking a leaf out of Runic Games’ book – the developers behind Torchlight. They started of introducing a game as a single player game and thanks to its success are now using the revenues brought from the single player game to help fund the larger MMO project.
“They put that game out there, and they put it on Steam for $20 USD a copy, and they did really well. And they’re using that game to fund an MMO!”
The single player game has even been tentatively scheduled for the end of this year. Perhaps Windstorm will be the next studio formed out of Ensemble to make the next great game along side iPhone developers NewToy and Fuzzycube.
The full interview between Inc Gamers and Dusty Monk will soon be made available and when it is I shall post a link here in a new blog post. For the moment check out the interview preview article on Inc Gamers here:
http://www.incgamers.com/News/21902/windstorm-studios-mmo-currently-on-hold
Halo Wars Dev Blogs (page 2)
-
How to Build a Base in the 26th Century
Halo Wars had its fair share of challenges. We were trying to bring the strategy genre successfully to the consoles for the first time. We were working with someone else’s IP. We had never done a console game. The list could easily be bigger than that, but you get the idea.
Now that Halo Wars has shipped and everyone’s had a chance to see, play, and evaluate it, we have the opportunity to discuss more about the process of making Halo Wars. For example, everyone knows how base building works in Halo Wars. Each base has a fixed set of slots (though you have to upgrade to get access to all of them). You click on a building site, make a deft move with the left stick, and tap A. Presto, here comes that Barracks you ordered. Nifty. It’s fast. It’s quick.
But is that a good thing? Most strategy games are noted for their deep city building and economic elements. WTF Halo Wars??? Why don’t you have an Age of Empires-like infrastructure game where the truly skilled players can “out econ” the newbies? The fairly un-sexy answer is that we just wanted a faster game with a larger focus on combat. Okay, fair enough. Let’s look at the iterations that base building went through to achieve those goals.
When we started Halo Wars, we had the relatively simple idea of bringing the “Age Experience” to consoles. The longer we worked on Halo Wars, the more we realized that we were doing something else: bringing a new strategy experience to consoles. Age is a PC game with PC sensibilities. Halo Wars needed to be something else given its platform. The games needed to be shorter. The action needed to be faster.
So how does that affect bases? Well, given our background with Age, the first base building system we implemented on Halo Wars involved placing buildings wherever the player wanted. Just like Age. For us, this was a logical starting point. Over the years, we’d fought hard to hold onto the idea that nothing invests a player in his base more than building it himself. And, most designers will tell you that base investment is a good thing for a strategy game.
After we got farther, though, we ran into problems. Players were spending too long building out their bases. At one point, we were even letting players rotate individual buildings. That made the problems twice as bad, not to mention exposing some brittleness in our new engine’s placement code. Players would agonize over the decision of where to optimally place a barracks instead of spending time watching their troops. On the one hand, that’s good. We want folks to care about that non-combat stuff. On the other hand, every second spent in your base was a second not spent in combat.
So, we tried to simplify building placement to make it simpler and faster. We made the buildings all the same size, so it was easier to visualize/control the layout. Yuck. The buildings all ended up being on the “big” side of the spectrum to accommodate our need to drive tanks out of them. That was a lot of wasted space. So, we made them all smaller. Too hard to tell them apart. So, we went back to varied building sizes. But, we took out buildings so you had less to build. Blech. That was definitely too far. It was clear that players didn’t have enough to do in their bases when we did that. All the time we were struggling with this issue, players weren’t having fun. Building placement was frustrating and it was killing the game.
Halo Wars has a really cool terrain system, perhaps the best we’ve ever built. It needed it, frankly, to even compete on the console. The game had to look hot. As we moved away from our random map heritage, though, things got more complicated. The terrain was more varied, so simply plopping a building down anywhere was harder because the ground was never really very flat. The code to dynamically raise and lower the terrain hadn’t turned out as well as we wanted, so we had problems just letting you build anywhere. As we looked at our options for fixing building placement, we decided to live with those limits and build the design around having players only build in “mostly flat” spots.
As you might expect, our next iterations were played on exceedingly boring, flat maps. Not good. After a while, we couldn’t take it anymore and the maps went back to having height variation. That was really a blessing in disguise. That issue pushed us over the edge on finally accepting that we needed to keep our bases “collected” in small areas. This turned out to be great for helping people parse and learn the maps quickly, which suited our faster play goal. But, that also sucked royally with our placement system. Things were too cramped.
As the playtest feedback inevitably started to re-suggest making buildings smaller again to work around the cramped towns, we stepped back. Something big had to change. After what turned out to be a couple of months of hemming and hawing, we left behind our “place anywhere” traditions and adopted the so-called socketed building model.
In hindsight, I think this was one of our best decisions. It instantly made the gameplay in bases quick like we wanted. The bases also looked a helluva lot better, too. The random, ramshackle hodgepodge was gone. There was some order, which sorta suited a heavy military game anyway. Design-wise, it was also a clear system that visibly presented you with your tradeoffs. You knew how many sockets each base had. You didn’t have to play Building Tetris only to find out that there wasn’t any space for the building you wanted to place.
It was somewhere during this 5th redo of the buildings that we realized the next problem. The bases were still too big. They looked awesome, sure, but they were too big. We couldn’t have enough bases on our 3v3 maps with the base size as it was. I think the only time I’ve ever truly feared for my life was when I had to tell the artists that we had to redo the buildings again. If only that was the last time.
The next (and last) big problem on base building and building size turned out to be the need for the units to exit their buildings. We really wanted to showcase that. It had been received very well in our E3 2007 demo. We had gutted that base scheme during the various un-fun iterations of the “place anywhere” systems, so most of the E3 2007 stuff was gone. But, we were determined to keep the units exiting their buildings. But those tanks are so f’ing big. Each building site had to be big enough to accommodate the Vehicle Depot, which was killing our attempts to reduce the base size.
I honestly don’t recall who suggested that we have each unit exit from some building. I do recall that it was met with the burning hatred of 1000 suns when I pitched it to the team. It wasn’t a popular idea. It was another piece of the vaunted “Age gameplay” that we were taking away. But, taking it away was the right thing. We could make the central building bigger and the outlying buildings smaller, which fixed our base size issue. Plus, design-wise, it made gather points much easier to manage since players only had one. Another “win” for ease of play on the console.
Okay, I lied. We actually had to redo the buildings one more time after that because the Design Department kinda goofed on some calculations with the turrets. But, let’s not go into that one.
Dave Pottinger, Lead Designer
Posted Monday, May 18, 2009 1:10 PM by Aloysius
-
Artists Blog: Map Environments
While working on Halo Wars I focused on creating the initial environments used throughout the skirmish maps and scenarios.The early phases began with our concept artist to get the look and feel of each world and working with designers on how these would be a part of the overall storyline. Also, brainstorming with programmers for terrain tools and understanding aspects of the new game engine to develop something we had never achieved before. Here are three of the major steps I would go though in creating our environments, although there were many more along the way.
Texturing-
The first step of creating a world would start with the terrain textures. This process was a definite change from the work I had done on the previous Age games. Halo Wars was a totally new game engine and our blend system had much more flexibility. Less textures were needed but the end result was much more dynamic and even the normal map generation had improved greatly. The number one obstacle for creating terrain textures was the vast difference in hue/saturation and compression from the PC monitor to the Xbox 360. What you see was not what you got. In an RTS game there is a fine balance in the complexity of textures and how the game units will read once placed on them. You have to make sure they are just the right brightness and saturation that add to the game experience and not distract from it. This part of the process is my favorite, because I enjoy making textures. Other artists like to make fun of my image files for having dozens of layers but I know what they all do. When I need to change the color of a single rock on the texture or the length of a grass blade I know just where it is at… well most of the time 😉
Sculpting-
The second step was sculpting and using the tools to manipulate the new powerful terrain mesh for the game. Before our games only used displacement on the Y axis, in Halo Wars we could move terrain vertices in all axes. While this gave us more freedom to create overhangs and more complex canyons and mountain ranges it did add more time to the sculpting. This step took the longest in our schedule and sometimes was the most difficult. To help us with the initial roughing out of the map we used a terrain generator that would create a displacement map and give us a nice starting point. Now that we had a mountain range or canyon we would go in with the finer tools and add the detailed characteristics for that particular environment. There were limitations though, and with all the new complex sculpting and higher tessellation we had to be efficient and optimized for game performance.
Lighting-
Some of the final steps were tweaking the lighting to create the mood of the world. Lighting for RTS games can be an ongoing hair pulling ordeal. As an artist you want to have the most realistic, colorful and dramatic lighting. But also as a game developer you have to make sure people can tell what the hell is going on. Some units that appear smaller on the screen could come out looking unreadable black blobs if your sun direction, inclination, ambient light and shadow darkness settings were not correct. The big difference in an RTS and other genres of game lighting is trying to pull off a night time scene, we always want to do them, but have to pull back a little. Player color and unit recognition go out the door when you turn the sun off. Scenario 2 was probably the closest we did to a night time setting. I had to add a lot of local lights but that would hurt performance. Sometimes without anyone looking my artist instincts took over and I would add a few lights here and there to get it just right. Whether I created a bright and vivid mountain valley or a dark and cold wasteland, with the lighting done right, it pulled in the player that much more into our environments.
Artists, programmers and designers all played major roles in creating the Halo War environments from look, tools, layout and storyline. I feel these environments are some of the best in a console RTS that have been done.
Bryan “bimbosoup” Hehmann
Environment Artist Posted Thursday, May 07, 2009 2:29 PM by Aloysius -
“Board” to Death: A Day in the Life of a Concept Artist
When I was first approached to write something for the website from a Concept Artist’s viewpoint, I thought that I would just do a generic, “day in the life of an artist”, type of write-up that we’ve all seen before. I thought about it. I figured I could sum up in a few simple sentences how concept art gets created and eventually put into the game. I could write about how we receive a written description of a unit, building or environment; how we create rough drawings of what we think a unit might look like; and then when one “thumbnail” is approved, we polish it so that the 3D modelers can build it, animators can give it life and then that unit can get put into the game.
In a nutshell, that is what a concept artist does. Quick, clean and summarized in a tidy little paragraph with enough time to spare to go watch the NBA playoffs.
Then I thought about it again. And I realized that it wasn’t that simple; at least not on Halo Wars and definitely not at Ensemble Studios.
You see, in order to create artwork at the highest level, you not only need a team that is talented, dedicated and stays on schedule, but you also need a team that meshes with each another. For that team to be successful in what they do, they need to have chemistry. So instead of writing about our daily tasks and attaching images of artwork, I decided to talk about what the team did that wasn’t on the task list and include photos that illustrated the “chemistry” that we had.
Throughout the studio there are white boards that are used for a variety of things like jotting down tasks and ideas, descriptions of units and keeping track of deadlines. The artists, on the other hand, had a different use for them. The concept guys would draw caricatures and create “inside joke” drawings on a daily basis. I would walk in the office and at the end of each day there would be new and often inspiring drawings on the white boards. While these boards’ original purpose was to have drawings, diagrams and written statements to help keep the team on track, the random imagery, humorous and often non-work-related material, probably kept the team more focused than unit descriptions or schedule dates and deadlines. It wasn’t long before other artists joined in on the fun as well. It wasn’t unusual to poke fun at each other, or crack a joke at someone’s expense. The ratio of laughing and having fun to drawing was probably an even 50/50. I absolutely felt that this dynamic was essential to create the top notch artwork that was done on the project. There were a lot of late nights and long hours, and without a sense of humor the team probably would have driven each other insane.
I’ve always felt that if you enjoy what you are doing and who you are doing it with, success will ultimately follow. Take a look at the art-work in Halo Wars and I think that you’ll agree that we were successful in what we set out to do: create a beautiful looking game. Laughing the whole time.
During my short time leading the concept guys on Halo Wars, I realized something- I did a heck of a lot more learning than I did teaching. Thanks to the Halo Wars concept team.
-bBelow are some examples of the crazy pix that these guys did… I’ve “edited” a few of them. 😛
Posted Tuesday, April 28, 2009 3:02 PM by Aloysius -
Under The Hood of the Halo Wars Combat System
Intro
The simulation system of any RTS can at times be hard for the players to unravel exactly what is going on so today we are taking a quick look at the core systems comprising the Halo wars combat system.
In Halo Wars every combat unit has an armor type and at least one weapon (often more), while each weapon has its individual damage, damage type and accuracy stats. Every attack in halo wars has a specific weapon associated with it even special attacks such as grenades or canister shot have separate specific weapons just for that special to use.
Accuracy
The first item we will look at it is the accuracy system in halo wars and how individual projectiles are directed when fired at the enemy. Every weapon has individual accuracy ratings that determine how accurate the attacks it makes are; the first rating is a straight chance to have the projectile be fired true while the second rating is used to determine how far off the aim is if the attack is not perfectly accurate. After the projectile is fired all that is left to find out is what unit is actually hit as a weapon can “roll” a miss and the enemy can move into the projectiles path.
Damage
After a projectile actually hits a target comes stage two of combat where the armor type of the unit being hit and the damage type being applied are used to look up a damage modification. The final damage is calculated by multiplying the base damage by this damage modifier.
A simple example of this is a marine firing on a scorpion with his rifle which for this example we will say does 10 base damage, now then the scorpion is armor type “Heavy armor” and the rifle does damage type “small arms fire” so we cross reference small arms fire and heavy armor on the table and get 0.4 modifier. The final damage will 4 damage done to the scorpion tank, calculated by taking the base damage (10) and multiplying Is by the modifier (0.4).
Wrap up
Overall the damage system is relatively straight forward with the main complexity coming from the number of armor and damage types but where feasible like type weapons share like type damage types. The machine gun on a scorpion does the same damage type as on the warthog for example. Also most game units have a fairly straight forward armor type except for a few special cases I will not be covering (but they are not important for this article).
Timotron
Some base Armor types in Halo wars- Light infantry: Marines, Grunts, Jackals, brutes, Elites
- Heavy Infantry: Flamethrowers, Hunters, Cyclops
- Medium Armor: Warthogs, Ghosts, Choppers, Wolverines, Cobras
- Heavy armor: Scorpions, Wraith, Elephants, Scarabs
- Aircraft: Hornets, Banshees, Vultures, Vampires
- Building: Bases, Buildings, Turrets
Some example damage types
-
- Plasma pistols and rifles
- Plasma cannons on ghost, banshee and wraith
- Heavy machine guns on warthog, scorpion and hornet
Heavy MG and plasma
-
- Wolverine anti air missiles
- Turret anti-air missiles
- Vulture anti-air missiles
- Vampire heavy needles
- Turret anti-air needles
Anti air missiles/ needles
-
- Marine grenade/ RPG special attacks
- Grunt plasma grenade special attack
- Warthog grenadier
- Wolverine grenade mortar
Grenades
-
- Rebel snipers
- Jackal snipers
Sniper attacks
-
- Flamethrower
- Flame mortars
- Covenant anti-infantry plasma mortar turret
Flames
Damage type/ armor type lookup table (real numbers from the Halo Wars database)
Light infantry Heavy infantry Medium Armor Heavy Armor Aircraft Buildings Heavy MG and plasma 160% 120% 120% 40% 180% 40% Anti air missiles/ needles 120% 120% 100% 60% 300% 60% Grenades 80% 60% 160% 120% 80% 160% Sniper attacks 400% 300% 40% 20% 40% 20% Flames 300% 200% 40% 20% 40% 40% Posted Monday, April 27, 2009 2:37 PM by Aloysius
-
“Five Long Years”
The last few weeks of working on Halo Wars were quite a blur. Actually, the last several months of working on Halo Wars were quite a blur. I think if you were to ask most folks working at Ensemble Studios to describe an event in their lives from the last year, they’d have a hard time remembering what season the event took place in. For us, it was all Halo Wars, all the time. Blurry days.
Today, I’ll do my best to remember the final steps of getting Halo Wars out the door.
The final months of a project are all about taking the previous years of work, mashing it all together into something cohesive, testing the game, and fixing bugs. It’s also a time of very difficult decisions. In the name of getting the game out the door, we’re forced to eliminate several features, many of which already had months of work put into them. This can be costly (literally), but it helps provide focus to the most important aspects of the game, and gives us a better chance at hitting our target release date.
Now would probably be a good time to detail out all the features we cut, but maybe that’s best left to everyone’s guesses. Or maybe those features will show up again somewhere else…
Back to it. As we approach the last 6 weeks or so of the project, we begin thinking about something called “Release Candidates”. These are complete builds of the game that we believe are good enough to make it to the retail shelf. On December 1, 2008, we created “RC1”(Release Candidate 1). Cool, we’re done! Not so much. “RC1” never makes it all the way through the testing process, and in fact, our designers run a contest for everyone of our games trying to guess the actual number of Release Candidates we will create. Guesses for Halo Wars ranged from “RC2” (yeah!) to “RC426” (no!). For a build to be considered “the” build, several parties must sign off on it from Ensemble Studios, Microsoft Game Studios Test, the Localization team, and a Production team at Microsoft. In the end, RC11 was “blessed” by this crew. Halo Wars build number 1169.
We’re almost home at this point, but we still have a crucial step in front of us, called Certification. For Halo Wars to be “certified” a team at Microsoft takes the game and runs it through a battery of very specific tests to make sure it lives up to the quality and experience expectations of the Xbox360. Tests range from making sure Achievements work, to seeing how the game responds to people yanking out their memory cards while the game is running (never a good thing to try 🙂 ).
Going through Certification is a very strange experience. It can be a multi-week process, and you can go days without hearing from the Certification team on how things are going. Ensemble had just gone through months of crunch, and we suddenly found ourselves in a waiting game with very little to do but hope the game makes it through successfully. Work hours returned to normal and people passed the day working on the demo or playing board games. Weird.
Finally, on January 8th, 2009, Halo Wars passed Certification and was declared “gold”. From there, the game was sent off to manufacturing plants all over the world, packaged up, and put on a shelf at a store near you. Good times.
Chris Rippy
ProducerDevelopers Playtesting the DLC Posted Wednesday, April 22, 2009 2:27 PM by Aloysius
-
Rock, Paper, Spartan and what it means in Halo Wars
Tim “Timotron” Deen, Lead Technical Designer on Halo Wars, is here today to give more insight on the “Rock, Paper Scissors” aspect of the Halo Wars combat system.
Coming into any RTS (and Halo Wars is no exception) can be a daunting task for new players as they learn the relationships of the game units, especially game units that are not direct counter or game units that are just soft counters. As such this article will attempt to delve into a more detailed look at the Halo Wars counter system and dissect it for the players into a set of discrete rules and show how the rules apply to the game. Finally before we start a term used often in this article is “RPS” which is shorthand in a RTS for “rock paper scissors” and is used to describe the rule sets that govern which units win fights.
Now then a detailed look at the Halo Wars RPS reveals that it is a layered system of 3 RPS systems with a specific order of priority in application. Also each RPS system provides a different flavor to the game and serves to provide a specific combat flow purpose. Additionally the RPS relationships are split into the two separate buckets of “soft kill” and “hard kill”, “soft kill” relationships are where the units have a medium advantage in combat and “hard kill” is where units have a very strong advantage in combat.
- Highest priority RPS
- Counter unit RPS
- Counter units hard kill their countered unit type
- Counter units are soft killed by mainlines that they do not counter
- Counter unit RPS
- Mid level RPS’s
- Scout unit RPS
- Hard kill counter infantry
- Soft kill air
- Soft killed by mainline infantry
- Hard killed by mainline vehicles
- Spartan RPS
- Limited hard kill normal vehicles and air
- Scout unit RPS
- Lowest priority RPS
- Basic unit RPS
- Infantry beat Air
- Air beats Vehicles
- Vehicles beat Infantry
- Mainlines are better than counters against buildings*
- Basic unit RPS
Note: * the cobra and wolverine has a minor siege counter role as a special bonus for UNSC.
The counter unit RPS provides hard counters to punish players who attempt to run a single unit army and is the highest priority counter system. Next the scout unit RPS provides balance in the early game against counter infantry and air before their main counters come online, while the Spartan RPS provides a specific counter to vehicles in tech level 1. Finally the basic unit RPS provides a low level bias to the combat so that the units not directly involved in a higher level counter system will still have a rule that applies to them.
The final item to cover in this article is to go over just what categories units fall into in halo wars for defining what they are. First all units have a role category assigned to them such as mainline or counter, and second they have a unit type assigned to them such as infantry or vehicle. The combination of those two items defines the unit’s base combat relationships to other units.
Unit Categories
- Role
- Mainline unit
- Counter unit
- Scout unit
- Special unit
- Type
- Infantry
- Vehicle
- Aircraft
- Highest priority RPS
One caveat before concluding is that results will vary in actual game play due to players employing micro management of units and in situations where the opponent has superior upgrades or numbers. Now with that caveat said hopefully this article will give everyone an idea of how RPS design is expressed in Halo wars and why many of the units have the combat advantages that they do.
p.s. I included a handy chart of Hard and Soft Counters below. Click for huge:
And since the first one was so popular, here is the Covenant Chart: Posted Wednesday, April 15, 2009 4:35 PM by Aloysius
Halo Wars Ranks and Skill Levels Explained
Halo Wars has a couple different ways of tracking our players history from matchmade, public games. Some we use primarily to get you good games, others are more oriented to helping players rank themselves against the community. Lets go through each of them:
Player Trueskill™
This is the standard Xbox LIVE Trueskill™ tracking value that rates players to help match them in competitive games. We use this only for matchmaking and we use it for all matchmade games. We track a separate Trueskill™ value for each of the different Halo Wars hoppers you can play in. So you if are great at 1v1 Standard but just getting started playing 2v2 Deathmatch games – then you will be matched with similar skill level opponents in those different games. Also for team games, we average your skill with everyone else on your team – so you don’t have to worry about the skill level of the party host versus everyone else on the team – everyone’s skill is taken into account. These Trueskill™ levels are meant only to help get our players the best matched game for all our different hoppers – but if you are ever curious about your level, you can always check it out under Multiplayer | Leaderboards. Select a Leaderboard Type of “MP Skill” and set the Filter to “Pivot” (that means “Find me in the list!”). You can also see the Trueskill™ value being used during matchmaking – right after the countdown starts you will see in the middle of the screen “Party TrueSkill™ Rank X”. X will be the Trueskill™ level averaged for the entire party (if the party is just you, then that is your exact Trueskill™ level). If you are interested in more detail about how this is calculated, here are the details: TrueSkill™ Ranking System
Skill Level
While the Xbox LIVE TrueSkill™ values are what help us get you good matches for each hopper, we also have our servers track a global skill value for you as well. If you look up on the website, the Player Stats for yourself (or any other player), right under your gamer tag is your Skill Level . That is a value between 1 and 50 for how skilled you are at playing competitive Halo Wars games. We calculate that on the Halo Wars servers with the stats from each matchmade game you play. Note that just like for the Player Trueskill™, if a player leaves early through any means (turning off the box, exiting the game, resigning, etc ) then the system will count that as a loss.
Score
Skill level isn’t always the best way for tracking a player experience with the game, so we also keep a total running score of all multiplayer, matchmade games you have played. As this global score for a player goes up, we award the players various ranks to reflect their experience with the game. See the Rank section below to see what total score is needed for the various ranks. To find your score (and rank), in game go to the multiplayer menu and select Service Record | Skirmish. Note that one of the best ways to boost your score per game is to complete the game (as opposed to resigning or disconnecting). While you get a 40% bonus if you win, you also get a 20% bonus if you just complete the game. On team games if you are defeated, the award happens right then – not at the end of the game – so you don’t need to wait around in that game unless you want to watch the action.
Rank
Rank | Score Needed |
Recruit | Play 1 Game |
Lieutenant | 80,000 |
Captain | 200,000 |
Major | 400,000 |
Commander | 800,000 |
Colonel | 1,600,000 |
Brigadier | 2,400,000 |
General | 3,200,000 |
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.
Tim Deen discusses Halo Wars combat system
Another developers blog appeared on the Halo Wars website today. Tim Deen a Halo Wars designer and Ensemble veteran discusses the damage system in Halo Wars and how things like accuracy and range affect the damage units dish out.
I will be continuing to mirror blog posts from Robot, Bonfire and others so that fans of Ensemble Studios can continue to find blog posts of their well respected developer in one place.
Blog post from HaloWars.com follows courtesy of Community Manager, Aloysius:
Under The Hood of the Halo Wars Combat System
Intro
The simulation system of any RTS can at times be hard for the players to unravel exactly what is going on so today we are taking a quick look at the core systems comprising the Halo wars combat system.
In Halo Wars every combat unit has an armor type and at least one weapon (often more), while each weapon has its individual damage, damage type and accuracy stats. Every attack in halo wars has a specific weapon associated with it even special attacks such as grenades or canister shot have separate specific weapons just for that special to use.
Accuracy
The first item we will look at it is the accuracy system in halo wars and how individual projectiles are directed when fired at the enemy. Every weapon has individual accuracy ratings that determine how accurate the attacks it makes are; the first rating is a straight chance to have the projectile be fired true while the second rating is used to determine how far off the aim is if the attack is not perfectly accurate. After the projectile is fired all that is left to find out is what unit is actually hit as a weapon can “roll” a miss and the enemy can move into the projectiles path.
Damage
After a projectile actually hits a target comes stage two of combat where the armor type of the unit being hit and the damage type being applied are used to look up a damage modification. The final damage is calculated by multiplying the base damage by this damage modifier.
A simple example of this is a marine firing on a scorpion with his rifle which for this example we will say does 10 base damage, now then the scorpion is armor type “Heavy armor” and the rifle does damage type “small arms fire” so we cross reference small arms fire and heavy armor on the table and get 0.4 modifier. The final damage will 4 damage done to the scorpion tank, calculated by taking the base damage (10) and multiplying Is by the modifier (0.4).
Wrap up
Overall the damage system is relatively straight forward with the main complexity coming from the number of armor and damage types but where feasible like type weapons share like type damage types. The machine gun on a scorpion does the same damage type as on the warthog for example. Also most game units have a fairly straight forward armor type except for a few special cases I will not be covering (but they are not important for this article).
Timotron
Some base Armor types in Halo wars
· Light infantry: Marines, Grunts, Jackals, brutes, Elites
· Heavy Infantry: Flamethrowers, Hunters, Cyclops
· Medium Armor: Warthogs, Ghosts, Choppers, Wolverines, Cobras
· Heavy armor: Scorpions, Wraith, Elephants, Scarabs
· Aircraft: Hornets, Banshees, Vultures, Vampires
· Building: Bases, Buildings, Turrets
Some example damage types
-
- Plasma pistols and rifles
- Plasma cannons on ghost, banshee and wraith
- Heavy machine guns on warthog, scorpion and hornet
Heavy MG and plasma
-
- Wolverine anti air missiles
- Turret anti-air missiles
- Vulture anti-air missiles
- Vampire heavy needles
- Turret anti-air needles
Anti air missiles/ needles
-
- Marine grenade/ RPG special attacks
- Grunt plasma grenade special attack
- Warthog grenadier
- Wolverine grenade mortar
Grenades
-
- Rebel snipers
- Jackal snipers
Sniper attacks
-
- Flamethrower
- Flame mortars
- Covenant anti-infantry plasma mortar turret
Flames
Damage type/ armor type lookup table (real numbers from the Halo Wars database)
|
Light infantry |
Heavy infantry |
Medium Armor |
Heavy Armor |
Aircraft |
Buildings |
Heavy MG and plasma |
160% |
120% |
120% |
40% |
180% |
40% |
Anti air missiles/ needles |
120% |
120% |
100% |
60% |
300% |
60% |
Grenades |
80% |
60% |
160% |
120% |
80% |
160% |
Sniper attacks |
400% |
300% |
40% |
20% |
40% |
20% |
Flames |
300% |
200% |
40% |
20% |
40% |
40% |
Five long years. Chris Rippy ex producer at Ensemble Studios discusses the last few months working on Halo Wars
Chris Rippy discusses in the latest developers blog on the HaloWars.com website what the last few months at Ensemble Studios felt like as the Halo Wars game started to go through its final stages of quality testing. The post provides a valued look into the life of the studio during this time and what the developers felt knowing this would be the last game.
The blog post as obtained from HaloWars.com follows:
“Five Long Years”
Today, I’ll do my best to remember the final steps of getting Halo Wars out the door.
The final months of a project are all about taking the previous years of work, mashing it all together into something cohesive, testing the game, and fixing bugs. It’s also a time of very difficult decisions. In the name of getting the game out the door, we’re forced to eliminate several features, many of which already had months of work put into them. This can be costly (literally), but it helps provide focus to the most important aspects of the game, and gives us a better chance at hitting our target release date.
Now would probably be a good time to detail out all the features we cut, but maybe that’s best left to everyone’s guesses. Or maybe those features will show up again somewhere else…
Back to it. As we approach the last 6 weeks or so of the project, we begin thinking about something called “Release Candidates”. These are complete builds of the game that we believe are good enough to make it to the retail shelf. On December 1, 2008, we created “RC1”(Release Candidate 1). Cool, we’re done! Not so much. “RC1” never makes it all the way through the testing process, and in fact, our designers run a contest for everyone of our games trying to guess the actual number of Release Candidates we will create. Guesses for Halo Wars ranged from “RC2” (yeah!) to “RC426” (no!). For a build to be considered “the” build, several parties must sign off on it from Ensemble Studios, Microsoft Game Studios Test, the Localization team, and a Production team at Microsoft. In the end, RC11 was “blessed” by this crew. Halo Wars build number 1169.
We’re almost home at this point, but we still have a crucial step in front of us, called Certification. For Halo Wars to be “certified” a team at Microsoft takes the game and runs it through a battery of very specific tests to make sure it lives up to the quality and experience expectations of the Xbox360. Tests range from making sure Achievements work, to seeing how the game responds to people yanking out their memory cards while the game is running (never a good thing to try 🙂 ).
Going through Certification is a very strange experience. It can be a multi-week process, and you can go days without hearing from the Certification team on how things are going. Ensemble had just gone through months of crunch, and we suddenly found ourselves in a waiting game with very little to do but hope the game makes it through successfully. Work hours returned to normal and people passed the day working on the demo or playing board games. Weird.
Finally, on January 8th, 2009, Halo Wars passed Certification and was declared “gold”. From there, the game was sent off to manufacturing plants all over the world, packaged up, and put on a shelf at a store near you. Good times.
Chris Rippy
Producer
Robot Entertainment at PAX (Part 1)
Some of the bots from Robot Entertainment have been hanging out at PAX Prime this weekend, hosting their very own PAX panel titled “An afternoon of fun with Robot Entertainment”. In our first part of our two part series we cover the first part of the panel which looks at Robot history including their time at Ensemble Studios and the games that lead up to Orcs Must Die! Unchained. For anyone who was in attendance there were plenty of free things being given out including a bag, poster, buttons, t-shirt, band and “Founders PAX” access to the Closed Beta. Read more
Game Informers “Directors Cut” interview with Patrick Hudson
In the latest edition of Game Informer you will find an interview with Robot Entertainment’s CEO, Patrick Hudson. There is also a directors cut version of this interview available online at the Game Informer website. The interview discusses the Halo MMO that was cancelled mid-development at Ensemble Studios and then goes on to talk about the visions for Robot Entertainment including the desire to work on smaller scale products with shorter development times. This vision has been realised already with Orcs Must Die! and Hero Academy which have been markedly smaller projects than say, Halo Wars at Ensemble. Read more