More Co-op — Schizoid Review

Posted in Game Review with tags , , , , , on July 19, 2008 by nickhalme

Co-op is the name of the game this week.  If you haven’t checked it out already, take a gander at the latest design exercise too.

So what is Schizoid, and why should you pay attention to it?

Schizoid is, I believe, the very first published game built on Microsoft’s XNA platform, and was developed by Torpex Games.  Well, that’s nice and all, but it’s not the reason why Schizoid is exceptional.

Read more »

The Developer Complex

Posted in Game Theory, Industry Comment, Opinion with tags , , , on July 17, 2008 by nickhalme

The developer complex is something that I like to attribute to someone on the production side of videogames.  I have it, and so do many others.  In such a creative industry we keep looking for absolutes to fall back on; a process we can follow that will always be correct, the way a Hollywood writer will point to his three act structure.  There’s nothing wrong with it.  It only becomes dangerous when those absolutes aren’t tried and tested — then the theory looks fallible.

Over at Lost Garden, a design blog penned by Dan C, I came across an interesting post: “Soul Bubbles: A classic game ill treated by expert reviewers“.  First of all, I really respect Dan for all the theory he’s put forward and shared, but I can’t help but point out the bias in his post.  Not only does the article suggest that there is a process to be followed that produces classic games, it suggests that anyone who disagrees is a bad designer.  I cannot do the introduction justice, so I’ll let Dan take the reins.

Read more »

A Design Exercise: Resident Evil 5 Co-op Mission

Posted in Design Exercise, Game Theory, game design with tags , , , on July 16, 2008 by nickhalme

So, Resident Evil 5 has just announced that it will support co-op.  Yes, the series has dabbled in cooperative play, but we’re talking two player online co-op here.  And what does that mean?  There need to be some pretty awesome scenarios to warrant the addition of co-op.  And you’re going to make one.

The challenge this week is to describe a Resident Evil 5 mission wherein cooperative play serves a vital role.  Approach this as a pitch, as if  you’re convincing your lead designer that your level is going to complement the gameplay best.  Please try to keep it brief and concise.

To give you an idea of what kind of missions have already been exposed, take a look at the video below, narrated by Capcom’s Gearoid Reidy.

The video shows that RE5 has room for context-sensitive ‘team moves’ over terrain, and gives you an idea of what a scenario could be like, with Chris (player 1) providing sniper support for Sheva (player 2) and then having Sheva open a door for Chris by shooting off the lock.

Here are your three constraints:

  • The scenario must hinge on cooperation between the two players, and provide either lots of back and forth or interesting static roles.  An example of back and forth would be the two players taking turns covering one another as they move down a street, while an example of interesting static roles would be having Chris cover Sheva from the rooftops while she makes her way through the street.
  • The scenario must keep players informed of where their teammates are — it’s fine to separate the players, but separate them for too long and they will lose track of one another and forget they are supposed to be working together.
  • The scenario must be designed to function with one player in single player.  For instance, in the video example, we can assume that Chris could have completed the mission using a different route.  We have no idea how Capcom is handling this, but for the sake of this exercise, assume that one player will have to be able to complete your mission.

Co-op has become increasingly popular in videogames, but remember that the mark of a good co-op level is team work.  If your players are not working together and exerting some control over each others survival, then it’s not really cooperative is it?  Just putting two players in a game and leaving it at that does not a co-op experience make.

Dawn of War II Over At Rock, Paper, Shotgun

Posted in announcement with tags , , , on July 15, 2008 by nickhalme

RockPaperShotgun is an awesome site; doubly awesome because they posted what I suspect is the new introduction cinematic for Relic’s Dawn of War II.

Having just purchased the new Warhammer 40k rulebook, I couldn’t help but intervene.

That means the current faction roster for Dawn of War II is so far composed of the Space Marines, Orks, Eldar, and Tyranids. Although who knows if the Tyranids will be a playable race, and not just the looming ‘bad guys’ in the campaign.

Here’s a direct link to a higher quality version of the movie. We’re working on getting a movie plug-in for the site, but for now you get a link!

And yes, I know; I’m a whore. Being mentioned on RPS makes me giddy.

Design Review: Create a Starcraft Unit

Posted in Design Exercise, Game Theory, game design with tags , , on July 15, 2008 by nickhalme

“Starcraft” is not a word to be thrown around lightly.  As the number of insightful comments we received this week clearly shows, mentioning Starcraft is like a rallying cry for both Blizzard fans and game designers alike.

For those of you just tuning in, every week starting on Tuesday we announce a design exercise and review the top three designs submitted on the following Monday.

So lets dig into the comments and see what we’ve got.

Vanadoss suggests a new Protoss land transport unit called the Behemoth: It’s built from the Robotics Facility, costs both minerals and gas, begins with no shield, and has no attack but rather relies on an energy-based area of effect attack.

Minerals: 125
Gas: 100
Produced: Robotics Facility, no additional requirements.
Population: 2

Abilities:
2 unit Transport -When destroyed occupants survive (different to shuttles and similar within which the units will die).
“Shock” - Ranged AoE ability,[edit:energy cost of 50] deals 25 damage in a small AoE (about 3 tiles) over 5 seconds
Has no other attack.

Health: 200
Shields: None, but +100 shields can be researched at the Shield Battery.
Energy: 100 max, starts with 50.
Armor: base 1, can increase through upgrades.
Shield upgrades do not affect this unit.

Speed: Similar but slower than the Dragoons.
Size: Similar to a Reaver

PROS: At first I was inclined to think that this unit infringed upon the usefulness of the Protoss Shuttle, but after some deliberation I believe it is quite situational.  The Shuttle is one of the fastest units in the game and has a 60 energy shield from the outset — while compared to the Behemoth it is an easy choice in most situations: Take the faster, hardier of the two.

However, the Behemoth is not vulnerable to enemy air defense, meaning that it can act as an efficient transport in most situations and when controlled by a skilled micromanager.  While a Behemoth can be maneuvered away from enemy ground forces, the Shuttle is susceptible to lock-on anti-air defenses, which deliver 20 damage a hit before armour mitigation.  Under the best circumstances this means that the Behemoth can deliver its troops and provide fire support with its AOE, attracting enemy units to attack it unless micromanaged and giving the disembarking troops a slight advantage.  The opponent has no real hard counter against this unit, although a small group of light air units could make short work of it as they can against the Shuttle — enemy players can safely build a small group capable of defending against both the Shuttle and the Behemoth.  Although the Behemoth has another plus: Should it be destroyed, the units inside still have a chance at survival.

CONS: Unless a player is building for it, the Robotics facility is a later game building  — even with the benefits the Behemoth has over the Shuttle, most players would probably need to conserve that 100 gas for more Dragoons or air units, while the Shuttle is less risky costing 200 minerals.  This doesn’t mean the unit is not viable though, implemented as is it just would not be particularly popular to produce, especially as it can’t be used for proper Reaver drops.

Next up is Ameen’s Zerg Creep Molter, a unit that sacrifices itself in order to lay down a carpet of creep large enough to support a Hatchery.

Zerg Creep Molter

Tech Tree requirements: Queen’s Nest
Cost: 100 mineral 250 vespene gas
Type: Ground Unit
HP: 150
Energy: 0
Armor: 1
Size: medium
Build Time: 50

Can it attack?
No. The Creep Molter cannot due it being able to create a new creep patch.

What are the Creep Molter powers?
Spawn Creep- Creates an area of Creep that is large enough to place one Hatchery.
Spawn Creep glands (research) - This increases the size of the Spawn Creep by 25%
Burrow (Research) - Allows the Creep Molter to burrow.

PROS: As a Hatchery does not require any creep to build, I assume it is just being used as a rough size guide.  This unit would excel at tagging along with some Drones to sneak behind enemy lines, place a patch of creep, and build some Sunken Colonies.  As it requires the Queen’s Nest to build, we can safely assume that this patch of creep produced will not affect Zerg rushing strategies (if the Creep Molter could be accessed early game, imagine Zerg players building Sunken Colonies outside your base, no matter the race) and is concerned only with late game strategy.  This does mean that it would be possible for the Zerg to set up a forward base, or fill a chokepoint full of Sunken or Spore Colonies far away from their bases.  While it has no attack it can use Burrow — so if your covert group of Drones gets ambushed, you can save your Creep Molter.

The idea of a Zerg creature that exudes creep upon its own voluntary death is an interesting one, and would probably make for a horrifying creature design!

CONS: Everything about the unit is fairly conservative — which in this case is a good thing.  There are no glaring imbalances, although playtesting would surely expose some flaws, as well as ways to improve the unit.

Pieter has suggested a Protoss ground unit called the Interloper: A kamikaze drone that inflicts some heavy splash damage upon death.

Minerals: 150
Vespene Gas: 250
Build Time: 40
Supplies: 3
Hit Points: 1
Armor: 0
Shields: 40
Type:ground; robotic; small

VERSUS GROUND
Weapon: Concussion blast
Damage: 400 concussion splash
Cooldown: n/a
Range: 0

Sight: 6
Upgrades: n/a
Prerequisites: Robotics Facility
Abilities: n/a

PROS: So first of all, this unit is pretty much a Protoss adaption of the Zerg Baneling unit announced for Starcraft II.  But that said, it has still been appropriately balanced for use by the Protoss and will have an effect on Protoss tactics.  While the Baneling will equal the cost of a Zergling plus a few more resources, the Interloper is significantly more expensive (as with most Protoss units).  The Interloper could be used for an attack on enemy resource gatherers, as a way for Protoss to take down buildings faster with the added burst damage, or perhaps less successfully as an assault unit.

CONS: The problem with the Protoss having access to a unit such as this is that in order to be especially useful it would have to be more sturdy to match the added expense, or much cheaper and deal less damage.  Blizzard is giving the Baneling unit to the Zerg in Starcraft II because it accommodates their general playstyle by being cheap enough to mass produce from Zerglings — their low hp problem is mitigated by the fact that so many can be produced, thus increasing the chance that a few get through.

A unit such as the Interloper, however, could not really be used in the same way.  Unless the enemy was simply not paying attention, or the Interlopers were dropped off by a transport and approached from behind, it would be easy enough for an enemy unit or units to focus fire for a second and destroy it.

Used as a utility unit though, it makes sense.  If a group of Zealots and Dragoons have just finished mopping up enemy units defending a base, the Interlopers can roll in and make short work of the buildings and allow the other units to massacre the resource gatherers — or vice versa, allowing the normal units to burn down the buildings with the Interlopers blowing up resource gatherers.

And that’s about it.  All in all, a very impressive turnout this week — all of the entries were viable and inventive, and it was tough to choose a top three.  Everyone seemed to grasp the idea of creating a single, balanced unit with its own purpose, while not relying on the other side having a tailored counter.

Keep on the lookout for the next challenge tomorrow!

A Design Exercise: Create a Starcraft Unit

Posted in Design Exercise, Game Theory, game design with tags , , , on July 10, 2008 by nickhalme

I think we’re all familiar with Starcraft, and hopefully this means a wider range of people can participate this time around.

The challenge will be to design a new unit that fits into Starcraft — for the purposes of this exercise, the unit will be created for Starcraft 1, as all of the unit info is already exposed.

The last submissions will be accepted on Monday (the 14th).  I know, it’s short, but just give it a shot; sketch out a design at lunch — more time spent does not equal a better or more sound design.  Keep your designs short and concise, but feel free to submit multiple designs.

As with the TF2 exercise, this challenge will take game balance into consideration.  Designer David Sirlin usually comes along with the words “game balance” and he explains the strategy that should be taken when considering units in Starcraft:

Starcraft teaches us another useful balance principle as well: purity of purpose. For the most part, units in Starcraft are designed to each have a specific purpose that doesn’t obsolete any other unit. The more functionally independent each unit is, the better. The reason is that balancing is made that much easier.

So, where to start?

First up will be the constraints; for simplicity’s sake we’ll keep it to three:

  • The new unit cannot infringe upon another unit’s usefulness; it must be a viable strategic option for players.  Whether the unit promotes a new tactic or expands an existing one, it cannot upset the game’s balance.
  • The unit must fit into the Starcraft fiction, and the unit’s aesthetic design should reflect its mechanical utility within the game.  For example, it’s obvious what a Marine can and cannot do.
  • The unit should create the smallest impact possible.  This sounds counterintuitive, but while the unit must be fun and different, it still needs to play like Starcraft.  For example, a unit that requires another building to be produced is going to disrupt resource allocation and change build orders — this isn’t necessarily a bad thing if done right, but done WRONG it can have an unwanted impact on the game.

For this exercise we will also be following Sirlin’s definition of balance:

A multiplayer game is balanced if a reasonably large number of options available to the player are viable–especially, but not limited to, during high-level play by expert players.

Keep in mind that with its three different races, Starcraft is an asymmetrical game — each race has different choices to make, even if they lead to the same end.  The Terrans handle air defense differently than the Protoss, and the Zerg build units differently than the other factions; but all races are able to meet the same end goals of effective air defense and unit production.  This is a trend that continues throughout the game and is something Starcraft has managed to balance very well.

This means the existing balance is tentative, and any changes, especially a new unit, are going to have huge consequences that need to be planned for.

Have at ‘er.

Design Review: TF2’s Heavy Class

Posted in Design Exercise, Game Theory, game design with tags , on July 9, 2008 by nickhalme

Thanks to everyone who participated this week!  Valve was nice enough to give the site a look-see, and plan to update their TF2 blog weekly; so for those who missed out on this exercise, rest assured that there will be more TF2 related challenges in the future.

As we are just getting this off the ground, we are still working to structure the exercise and review process.  The plan is to release the review post on Mondays, and start the new exercise on the following Tuesday.

This means you will see an exercise go up on Tuesday, and you should try to get your comment submitted by the next Monday.

This week, however, the next exercise will be going up tomorrow, on a Wednesday.

Now let’s take a look at the top three most viable designs from the Heavy exercise.

First up is Scott’s idea to give the Heavy a pair of big red boxing mitts to replace the standard fists in melee.

New Melee Weapon (Boxing Gloves)
The heavys big mitts are covered in big red boxing gloves. As a result the heavy loses the ability critical and gains a knockback ability (like the pyros). The heavys normal melee is rarely used and usually because the player isn’t really trying to play rather just trying to be silly.

As the Heavy fills his primary combat role with the minigun, this melee weapon doesn’t risk imbalancing Heavy/Medic pairing, while producing a new game mechanic for the Heavy to consider: pulling out the gloves to knock someone around or push enemy shots away.  This gives the Heavy some more utility, but doesn’t change his main role.  It fits with TF2’s style, and seems like it would make sense to users — it would also be easy for others to see if the Heavy is using the big red gloves.

The only concern is what governs the ability to knock back enemies; for the Pyro to blow back projectiles he has to use a substantial chunk of his primary ammo, but melee is inherently ammo free.  Changing another variable, like punching speed, might be something that would balance the knockback effect.

While officially the idea was to come up with a new weapon for the Heavy, StillBetterThanSasha’s idea still works towards the goal of making solo Heavies viable, although it does so indirectly.

Get Up Dummkopf!

Medics gain the ability to give fallen heavies a swift kick in the butt to get them back into the fray with 1 starting HP. It works like a taunt, the medic renders himself defenseless for the duration of the animation - better hope the sniper or spy that got the heavy isn’t still hiding somewhere… The ability only works on killed but not gibbed heavies (if characters take a lot of explosive damage they gib into pieces of meat). I think this is my new favorite idea, mainly cause it solves the problems I have with the class and plays off the already existing medic - heavy relationship. It’s too risky to use in battle so it should mainly work to drastically reduce the downtime for heavies that got picked off as easy targets on the fringes.

How does this help the solo Heavy at all?  By reducing the risk of death, the Heavy player will be inclined to fight and wait for a Medic to show up, instead of pairing up and then attacking.  It appears fairly balanced, as there is still a chance — especially with Sentry rockets, etc — that the Heavy will go down completely anyways.  But it’s enough of a gamble that perhaps players would change their play style a bit to accomodate such a feature (ie. Medics would tear their attention away from healing to see if any Heavies needed help up).

The only problem with the idea of a taunt that has such an integral role in play is player awareness and positioning.  But by adding a new icon to indicate to Medics which Heavies can be helped up, it would become easier for Medics to use and understand the ability (a key prompt might be needed as well, to show new players where taunt is!).  There would also need to be some sort of ’sticky’ positioning, to halt the Medic for a couple seconds and lock him in the appropriate place over the selected body.

Last but not least, Scott has suggested a replacement for the Heavy’s coveted main weapon, the minigun.

New Main Weapon (Yasha and Roids)
The heavy loses his beloved Sasha and instead gains a one handed, lighter mini gun in his right hand and a syringe full of roids in the other. The smaller mini gun, Yasha, would need no ramp up but the damage would be decreased. Replacing the ability to spin the barrel (alt-fire) would make the heavy inject himself with the steroids or stim-pack or what have you, and take 50-75% less damage for 5-10 seconds. This new alt-fire would be either on a timed cool-down or something the heavy must build up (like the medi-gun) by killing enemies.

Of course, the most direct way to make the Heavy more viable on his own is to give him some of the Medic’s functionality.  This idea is especially clever in that the Heavy takes a hit to his damage output with his main weapon, making him less of a threat when paired with a Medic (he’s no longer a powerhouse to throw into the fray) but making him more balanced otherwise.  The idea of a smaller one-handed minigun and a syringe shouldn’t be foreign to TF2 players, and enemy players and teammates would be able to clearly see if the Heavy was lugging his minigun around, or his lone wolf combo.

The downside is that there may be, at least initially, some confusion surrounding the combination of the stim ability and a Medic’s healing power.  Since the syringe doesn’t render the Heavy invincible but rather reduces damage taken, the Medic’s Ubercharge ability would have to override the damage reduction should the two overlap.

But only playtesting could determine whether the Medic’s new critical charge ability would be overpowered if it worked alongside the damage reduction, or if it should override the syringe’s effects as well.  It may very well turn the Heavy back into the support role that he had forgone when choosing his new gear: He would output more damage, and still be able to survive with his healing ability (which would be boosted by the kills he has accrued with the critical charge).

Well, that’s it for the Heavy exercise.  Thanks again to everyone who participated, and I hope everyone had some fun thinking about this.

Stay tuned tomorrow for this week’s belated exercise.

Indiana Jones and fiddy collaborate?!?!

Posted in funny, new games with tags , , on July 8, 2008 by McElroy Flavelle

And more proof God DOES have a sense of humour…

The plot for the latest 50 cent game:

G-Unit are putting on a show somewhere in the Middle East. The crowd is pleased, but the promoter refuses to pay 50 Cent and G-Unit. The promoter does not give them money, but a very valuable diamond encrusted skull instead. G-Unit are about to leave the country when they are ambushed and the skull is taken away from them. The game then continues with the group trying to get what’s rightfully theirs and finding out who ambushed them and why in order to get revenge.

-Wikipedia

I know you think I’m kidding.

I’m not.hahahahaha

A Design Exercise: TF2’s Heavy Class

Posted in Design Exercise, Game Theory, game design with tags , on July 2, 2008 by nickhalme

The aim of this site is in part to entertain and provide news, but its primary focus is undoubtedly to provide new and aspiring game designers with some insight into what it is exactly that designers do.

So, in an effort to build a working knowledge of the game design process for readers, I’m going to be starting these exercises.

Here’s the jist of it: We will present a compelling game design problem and give you some restraints and limitations to work within; once you have a solution that you feel satisfies the requirements post it in the comments section.  All of the comments will be read and evaluated, and the top three will be reviewed in a follow-up article, detailing what those designs do well and what they do poorly.

Unlike the Design Challenges we also hold on the site there will be no cash prize, as we hope to run this more often than the contests.  You will, however, grow as a designer.  Besides, it’s fun.

Down to business then.

Valve has released some info on how they’re going to go about updating the Heavy class in Team Fortress 2.

The challenge will be to design a new weapon for the Heavy.

Here’s the primary design goal Valve has set:

Goal: Make the Heavy more viable when he has no Medic to pair with.

Here are the constraints you’ll be working with:

  • It shouldn’t have a cumulative effect when being healed by a Medic as well. Heavy/Medic pairs do pretty well as it is.
  • It shouldn’t significantly change the Heavy’s role, relative to other classes. In particular, it shouldn’t significantly encroach on another class’s role.
  • It should be understandable for both the user and the player it’s being used on.

For more info, please visit Valve’s blog; they list some other important issues to take into account.  For instance, you should take design economy into consideration: Can you make a small change that results in a big payoff?

Good luck, and have fun. :)

Diablo 3 Announced

Posted in announcement with tags , on June 28, 2008 by nickhalme

It’s here. You know. It.

*Update*

The Diablo 3 site is live.