Header

Monthly Archives: September 2010

Halo: Reach – Campaign Review

Originally written for www.7outof10.co.uk

In many ways, Halo: Reach was up against it. Much like Titanic or a John Lennon biopic, we knew it wasn’t going to end well. So if the tale itself would not be a revlation then the journey to its grim conclusion would have to be strong. With Master Chief otherwise engaged, it’s up to Noble Team to push back against the Covenant.

It’s a slow start, too. With Reach being humanity’s military stronghold in the stars, the planet’s leaders assume their world is impregnable to off-world threats and Noble is charged with no more than routine patrols to investigate a comms failure. Upon arrival, they discover the grim truth: the Covenant have not only found Reach but are planetside.

Noble Team consist of classic military archetypes, from Jorge the hulking Spartan II who has a softer side, to Kat the hardened, cold sniper. During your time on Reach, the other five members of your team will attempt to endear themselves, however they never come across as more than walking clichés, with the possible exception of Jorge. Though it is disappointing after the characterisation seen in ODST, these are Spartans, after all; bred to be intergalactic badasses, and that’s what they do best.

On most missions, you – Noble Six – will be accompanied by one or more of these walking battle fortresses. Their presence lends an air of being attached to a combat unit. Nonetheless, whilst they are effective and will aid you in dispatching everything from Grunts to Hunters, they are not so powerful as to allow you to put your feet up with a Sweet William cigar. They will cause distractions and take out obvious targets, but as combat has always been Halo’s strong point Bungie would not want to take that away with an infallible sidekick.

And as ever, the fire-fights are exceptional. At the very base level there is still the ability to only carry two weapons at a time, causing you to think and balance effectiveness and practicalities against simply wanting to carry your favourite boomstick in your back pocket. Those elements alone can allow a situation to play out in any number of ways depending on what you bring to the party, but on top of that you have the extremely cunning AI, the broad levels that encourage outflanking and outmanoeuvring, and an understanding of the “thirty-seconds of fun” mentality that continually pits you up against different scenarios and forces you to adapt. For me, the stop-and-pop nature of Gears and the monster closets of Call of Duty pale in comparison to this fluid gunplay.

From the first time you encounter a group of Elites you know that Bungie has moved its aliens back towards the original Combat Evolved. There’s no pithy one-liners from the Grunts as they stand over your body firing a plasma pistol mercilessly into your corpse; you understand that these are spry, vicious races intent on your destruction. They’ve toughened up since Halo 3 and should provide a challenge for most even on modest difficulty settings.

In many ways it’s the large and varied combat arenas that makes such a spectacle. Hunting down Jackals through a vast, abandoned water station or scurrying through rocky outcrops in search of an elusive Elite may still objectively be linear as everyone will encounter such a situation, but it is the width and quality of the corridor you are being lead down that elevates Halo above other shooters. Each is designed with the intrinsic understanding that battles aren’t just a back and forth, they are about outflanks, edging to get to just the right position, and using copious amounts of cover as the drop ship pummels your position to deliver reinforcements. There are very few mundane settings, and though they may not necessarily reach the heights of previous entries in the series, all without exception are well crafted.

As an addition to a Spartan’s arsenal, there are now loadouts that enhance the capabilities of the Mjolnir armour. The default is Sprint, but also on offer are Armour Lock, the ability to project an invulnerable shield about yourself; Hologram, generating a digital copy of yourself to distract Covenant forces; and Jetpacks, allowing a Spartan to take to the skies. All prove useful, and most can be utilised in the same situations to vary how combat is approached. Should you sprint round the back of an enemy tank? How about slowly progressing, shielding yourself at intervals from its onslaught? Or distract it with a hologram before removing a startled driver?

Rather than allow a player to specify a load-out however, they are only available as pick-ups at certain points. Though this is understandable in the case of the possibly map-breaking Jetpack, the ability to assault a level in a myriad of ways using a different load-out each time is somewhat of a missed opportunity; a feature that would have no doubt created some very interesting single-player and co-op approaches.

As a whole, Reach appears to be a considered attempt to pick the best bits of previous Halo’s. Whether this is coincidence or simply a reaffirmation of Bungie’s style is hard to say, but there’s that night-time sniper mission, that tank mission, and the obligatory assault along the coast that’s already a trademark. Individually, each section is high quality, pitching the player against a series of interesting set pieces, though personally I found at times it lacked the spark found in previous titles. This is never more evident than in the concluding portions. For the entirety of the tale, tension has been ratcheted in a slowly building spiral that promises an epic culminating battle… which never arrives. I can assure you now that there is no manic Warthog drive to safety at the end, instead it takes more of a cue from Halo 2, cutting the action when it promised something so much greater.

Had this review been penned immediately after such a disappointment, it would not have fared well. Since then however, I have wandered once more through Reach, and on the return journey the quality of the product shines through. The portrayal of epic battles, the hugely varying situations of strife you find yourself in, and the willingness to mix pitched battles with quick and dirty skirmishes kept reminding me of what I originally found so great about Master Chief’s adventure all those years ago.

It will divide opinion; some will rue the seemingly recycled environments and familiar backgrounds, but that’s like condemning the use of pipes in games featuring plumbers. Halo is what it is, and that’s a slick refinement of sand-box combat. 343 Industries have a mighty task ahead of them to keep up the standard.

 

9 /10

Inside the Industry: Data Driven

Originally written for www.7outof10.co.uk

Last time we discussed prototypes, and how programmers and designers worked closely together to trial small components of a larger whole. During such a phase, the close feedback loop that exists between the two is of great benefit to both parties. For the programmer he can quickly grasp the many subtleties that may have been omitted from a design doc, whilst the designer can request quick tweaks as the positives and drawbacks of their idea become evident.

Though this is an ideal working relationship early on, as the project progresses, so do working practices. It’s not feasible long term to have programmer and designer buddying up every time a minor change in balance or design occurs. For one the programmers need the time to implement the rest of the game’s innards, and for another designers generally prefer to work free from over-reliance on coders.

The solution is to design the infrastructure of the project in such a way that its flow it not dictated from what has been coded within, but rather by a series of external sources. This approach is called data driven, and describes a method that can prove extremely flexible. By putting the control in these “assets” (a term used to describe the files and objects associated with the game, e.g. scripts, models, textures) it allows any member of the development team alter the look and flow.

For a simple example, let us return to the scenario of a game based around a Frisbee. Imagine, if you will, that during an early iteration I was told that each player would be asked to throw ten discs at an array of targets, earning points depending on their accuracy. An easy way to express that programmatically would be to hard-code – i.e. write directly into the programme – the number “10” when asked how many times the player would like to repeat the throw. From personal experience this is a terrible thing to do; over time designers change their mind, situations shift and whims alter. Say a demo of the Frisbee was called for but due to time restrictions only three throws were required. I’d have to wade into the code, search for each use of the number 10 in this situation (for there is rarely but one place such things are referenced) and alter them to a “3” for the time being. Hardly a productive use of anyone’s time.

A far better approach would be to specify in an asset the number of throws required. This has several benefits. Firstly, it means that the value for the number of throws has been defined in a solitary place rather than scatter throughout the code. This makes great programming sense, allowing those scanning the code a greater understanding as to what a value means/does and thereby reducing the possibility of errors. And secondly, it allows anyone to change the game quickly and easily, meaning that alterations can be trialled quickly and painlessly.

Of course this is a trivial example, but if we extend this process out we can envisage the scores designated to the targets being declared in assets, the models making up the background likewise, right down to the values controlling the air resistance on the Frisbee itself. The more that can be parameterised within a game and placed snugly within assets then the greater the power that a designer can possess, and that doesn’t have to stop with mere numbers.

Markers

Those who have taken receipt of Halo: Reach this week will no doubt stumble across Forge, a map editor that allows you to customise a level in any manner you choose by editing in objectives, vehicles and scenery into existing maps. Though highly polished and rigorously refined for the home user, I have seen many development toolsets use interfaces similar to Forge where the designer can drop down enemies, trigger points, patrol paths and cutscene camera markers, to name but a few options, directly onto a background.

The first game I worked on – Grabbed by the Ghoulies, an arcade brawler set in a haunted house – had a very easy and intuitive editor based on the console in a similar vein, and allowed levels to be set up in a few minutes. Designers would edit down the player’s start point, designate predefined animations for the player’s character from a series of drop-down boxes, and then proceed to place enemies, weapons and power-ups throughout the rest of the room. Save it out, load up the scene and away you would go, instantly seeing the fruits of your labour.

An alternative is marking up everything in third-party 3D art tools such as Maya or 3D Studio Max, but the advantage to such systems is that the iteration is swift and the assets produced tend to be small. Rather than suffer after finding out you’ve placed an enemy down in such a way that it unbalances the experience, simply open up the debug menu, and head straight into the editor where you can nudge him into the right position, reload and you can trial your fix within seconds.

Scripts

So now designers can edit the parameters of objects and place them down onto a background, but to truly create a flowing game they need to be able to tie these disparate scenes together into a complete experience. It’s all well and good editing down a door that you’ve specified should be blue, but what happens when they try and interact with it? One solution is scripting, which is not just a term restricted to orchestrating grand “set pieces” that aim to grab the player’s attention, but instead runs through every facet of the gameworld.

Let’s return to our Frisbee game. Imagine that it takes place in a giant stadium and that our player’s character will emerge from behind a curtain, camera following him as waves to a cheering crowd before finally taking his stance ready to hurl some discs. All of that can be pieced together by our designer’s scripts:

  1. Load background
  2. Load whatever you’ve edited down, including the player’s character model
  3. Play cutscene that animates the player’s character and the camera
  4. When the cutscene has finished, pan the camera around behind the player’s character so we can see where the targets are
  5. Hand control of the player’s character to the player and wait for an input to begin
  6. Keep a track of how many Frisbees they have thrown, when they have reached the number specified in params play the closing cutscene
  7. When the cutscene has finished, return to the frontend

That may look ridiculously simple, but if the scripting has been structured in such a manner then it’s these building blocks that can join together to form things that can be quite spectacular. Outside of the core game logic, being able to puppeteer characters and run cutscenes are two of the staples of fleshing out experiences and, again, because they are data driven they allow a flexibility in the structure of the game that can be changed relatively simply.

Sadly, however, you can’t data drive everything. Core components such as the actual structure and nuances of the gameplay and all the bells and whistle surrounding it have to be laid down in code, but sensible software design can identify early what should or could be useful as building blocks. Make these blocks too small and you’ll be asking a lot of the design team to piece them together; make them too big and you’ll be making a lot of work for the programmers as they have to produce bespoke code for multiple situations that could have reused some of the scripting bricks. As with our last discussion, it again comes down to a synergy between design and programming striking a balance.

Cheap at twice the price

Originally written for www.7outof10.co.uk

Kudos to Capcom. The way they have handled Dead Rising 2: Case Zero has to be one of the greatest masterstrokes of recent times. Broadly speaking, although it’s pitched as a prologue, it is to all intents and purposes a demo for the imminent Dead Rising 2. The twist, however, is that you pay for it. When I first heard this, I, like most of the Internet, raised my hands unto the heavens are proclaimed Capcom to be the next evil sent to plunder every last penny from their poor, patient fanbase. Having now gotten a hold of the facts, it seems like one of the best value propositions around.

For a mere 400MSP it appears that you can grab yourself some pre-emptive DLC. You get a moderate helping of Achievements, an introduction to the game and its mechanics, but even more than that; the experience you earn during your time with Case Zero will carry over (up to a point) into the full game. Even if you find out it’s not your cup of zombie tea, for a price that is a third of most modern XBLA releases, how could you go wrong?

Out of all its cunning marketing ploys, transferring your progress into the forthcoming Dead Rising 2 is by far the greatest. Fable II was the trailblazer in this area with its pub games and the ability to import your winnings once you visited Albion proper. Disappointingly, nothing of note since then has leveraged this functionality.

Being able to carry on your progress from demo to full game is a powerful feature. I know many people who don’t enjoy playing demos if they know they are going to purchase the full game because more often than not the demo represents the initial stages of a game and going over the same ground is something they find tedious. With Fable II and Dead Rising, not only is the “demo” offering something different, but there is an incentive to play it several times over, maximising the advantage it can give you. Imagine a small management game to proceed FIFA, allowing you to hone your team in readiness; or a decal editor that gives you the chance to ready your paint jobs way before Forza 4 hits the shelves.

Of course this is not an easy thing to produce. Just a demo itself provides the development team with a massive headache as they have to get the game in a fully functioning state sometimes months ahead of schedule. The diversion of resources and distraction from the main task at hand is enough to drive a project manager crazy, and that’s even without them becoming fully fledged XBLA products like the two titles above.

Even so, I look forward to this “trend” continuing. If the prices are kept reasonable, as with Case Zero, then I’m more than willing to break my no-demo habit and sink some time into a prologue. Even if it’s half as good as the original Dead Rising demo, it will be worth it.

Blade Kitten – Hands On

Originally written for www.7outof10.co.uk

Inform others of the title and they’ll more than likely repeat it back to with slow pronunciation and a heavy dose of scepticism, culminating in a giant question mark: “Blade… Kitten?” Yes, there may be a pink haired, Manga, cat-woman leaping about on screen, but don’t judge it so readily.

The cat-woman in question is named Kit, and she’s a Bounty Hunter; one of the best in the business if you believe her website. She’s a vivacious minx, searching the galaxy for those with a price over their head and never leaving home without her floating sword. When we join her, however, she’s having a little trouble with a fellow Hunter who just blew up her spaceship.

Kit’s pursuit of her rival unfolds through the eyes of a 2D action-platformer, as she runs and jumps, slashes and crashes her way through a variety of obstacles and masked soldiers. Our pink-haired protagonist – being half feline – is rather nimble and so can spring about with a great spryness, but also isn’t afraid to get her claws dirty with a selection of melee attacks more than capable of bringing down those that stand in her way.

Combining swordsmanship, quick hands and some flamboyant special moves, combat is fun without being taxing. Vanilla guards very rarely pose a threat even in numbers, and can be hacked through without much thought. Tougher close-combat guards put up more resistance as they block your blows, and are eventually joined by a missile-toting support crew. It’s hard to say whether later levels will produce greater challenges, but early on combat sufficiently portrays Kit as the badass she’s purported to be.

Of greater interest is the world she inhabits and the sheer size of each level that we are taken through. From vast plains to deep dungeons, they stretch out seemingly for miles, switching this way and that, sending you first up to a peak before dropping you back into the maze’s heart. When viewed objectively, most are linear but they are designed in such a way as to give the impression of branching, with alcoves and detours placed throughout to distract you from your goal.

Although it may seem standard fare, what distinguishes Blade Kitten from other 2D action-platformers, and indeed other female Bounty Hunters who like to operate in a similar space, is her ability to sink her claws into the walls and scale both vertical surfaces and ceilings. Confound enemies by dropping down from the roof onto their bonces, scale cliffs to reach collectible credits, and generally act as though you’re the second coming of Gex. Although that skill would be merely tacked on if it wasn’t for the clever level design that exploits it to the full, players could quite happily plough though the dozen or so levels on offer without straying too far from the path, but the lure of hidden secrets could easily double the time you spend exploring the world. Hidden passages and chests full of treasure are both liberally distributed and add an extra dimension to play, cunningly veiled by scenery that cuts away when you get close.

Out of all the aspects contained therein, this verticality raised Blade Kitten to a whole new level. Knowing that exploring every possible direction could bring hidden nuggets made me examine each and every wall, floor and ceiling as I hunted down treasure. In doing so it not only help my bank balance as I unearthed these riches, but these asides brought me to interesting little platforming sections or nooks that showed off the game’s visual style.

So much was I taken with this that I felt quite disappointed when one level dispensed with the verticality and instead presented me with a vast, open plain that was to be traversed on the back of a giant beast. Variety it may have been, but with every moment underneath the blue sky I missed that claustrophobic feeling that meant I could jump up, jab my sword into the masonry for a handhold, and begin exploring the finer points of the ceiling.

Stylistically, it comes across as though a living comic. The cell-shading is extremely suited to Kit’s universe and comes into its own in the cutscenes, when heavy outlines combine with bold colours to reflect the series’ roots. Equally pleasing is the voice acting that is slick and professional, adding yet another layer of polish to an already accomplished game.

Blade Kitten is what I covet most in an industry full of predictability and sequels: a surprise. It’s bright, full of energy and came from nowhere to have me scrabbling about through press releases looking for a release date. As an original IP born from within Krome itself, it’s wonderfully fresh and has plenty of substance to back up its good looks. Come release, succumb to curiosity; it won’t kill you.

Inside the Industry: Prototypes

Originally written for www.7outof10.co.uk

One of the more interesting and exciting parts of developing video games is the prototyping stage. It’s here that new ideas are tested before being banked or binned depending on their success. But why prototype in the first place?

Simply launching into a new project blindly can be a risky strategy. When entering into such a venture, the unknown can be an expensive business, both in terms of finances and resources. Even with the most well-meaning and well-informed developers, they can unearth stumbling blocks or make poor decisions which ultimately lead to a dead end and the possible conclusion that the project should be canned. This could be anything from the core game concept simply proving unworkable; to a seemingly innocent design choice at the offset has meant that the software infrastructure fails to scale with the needs of a full game.

One of the many ways to prevent this (or at least finding the grim truth out sooner) is through prototyping. Prototyping is a proof of concept, there to quickly trial your ideas before committing a larger number of resources to it. In the same way that an artist will sketch in the back of a pad before placing brush to canvas, game prototypes are there to make sure that initial thoughts on the project are backed up by a working example.

Years ago, I used to think of a game prototype as the ubiquitous “vertical slice” that is forever mentioned in the video game press. This nasty term describes a demo that has usually been custom built to show off as many of the final features as possible. The truth is that prototypes should be the exact opposite and adhere to a number of set rules:

  • Prototypes should be as small and as basic as conceivable possible.
  • Prototypes should ideally test one aspect in isolation.
  • Prototypes should always ask a question.

The last point is the most important. If your prototype isn’t asking a question, what is it trying to prove?

For the sake of an example, imagine that we are trying to create a Kinect Frisbee game where a character is throwing you Frisbees and you have to catch them before throwing them at a series of targets. That may not sound like an incredibly complex concept but there are a number of possible prototypes that it can be broken down into.

Within our mandate to ask a question, prototypes revolving around what the scoring system should be or testing the collisions with the targets are unnecessary: scoring is not an unknown, we know that it is just a matter of numbers and can be decided at a later date; collision detection is nothing new and so does not warrant a dedicated prototype.

Instead, we could come up with at least three:

  • Can you write a believable simulation of a Frisbee in flight?
  • Can you detect when a player has caught a Frisbee?
  • Can you create a satisfying and natural gesture to throw a Frisbee?

Develop all three in tandem in the setting of the final game and it may be hard to distinguish just what effect each minor change has. It’s far easier to strip them down and prototype each shard individually, before bringing them all together.

Though it may seem somewhat of a faff to strip apart each major element and prototype it, the small scope means that ideas can usually be trialled in just a matter of days. Then the iterations begin. Nothing is going to be perfect the first time and so programmers and developers work in a tight feedback loop trying to bring the prototype up to a functioning standard where it can definitively answer the question set for it. Positive answers are quicker to come by than negative ones, and so if a prototype goes particularly badly, it may be attempted in a different manner or style one or more times more before, depending upon its importance, being set to one side.

These times, particularly ones spent iterating with design, are moments that can spawn new ideas or avenues of exploration. Seeing their concept in isolation allows both coders and designers to consider ways in which they can improve, streamline or expand on it that they may not have done if it were dropped into the main game straight away.

To speed iteration up further, many of my own prototypes attempt to forgo as many art assets as possible so that they can be changed as quickly as possible. This does lead to a great number of wireframe cubes and spheres littering my prototypes rather than spiffy high-res characters, but I like to think that they add a little charm to proceedings. It also has the added advantage that the focus can purely be put on the matter in hand and not be distracted by superfluous visual elements; they can be added when the concept is proven.

Of course, this is just one of many ways to prototype systems and there are entire bookshelves full with theory on the best way to do things. The one thing they all have in common, however, is that they all set out to minimise the risk for the developer. Proofing the concepts extremely early on allows developers to have a good handle on what works and what doesn’t, whether what they’re aiming for is ultimately possible, and indeed whether it will get out of pre-production.

Next time we’ll take some time to examine some practises that allow designers access to the inner core of a programmer’s world without ever requiring them to know a line code.