I’m really excited about a console game.  It’s set in World War 2.  I’m sick of World War 2.  It has some sort of connection to Tom Clancy– that’s a minus.  The art direction looks bland, and the story hasn’t even showed up yet.

But if you check out this 8 minute gameplay vid, you can quickly tell that the design team has done a ton of heavy lifting.  (And maybe the UI team?  Do game studios even get to have a UI team?)  Let’s check out the elements:

• Positional + pitch/yaw controls.  Hey, I’m a console player, I know how to point at things in 3D– I bought Halo, remember?
• Quick zoom.  This is great for increasing precision and resolution.
• Floating cursor.  Lots of RTS games have gone with a crosshair in the middle of the screen– this floating, snap to nearest unit cursor looks a lot more useful.  Instead of trying to snap the view to a unit (see: Halo– and yes I’m contradicting point 1), snap the cursor and leave the view free.
• Tons of visualization.  Watch the player find a destination for the units.  You’ll see not only the destination, but the position and orientation of each unit when they arrive.  You can also see enemy paths, iconic views when you zoom out, and lots more UI goodness.

I’m not even going into the unit- and base-building modes, which display at least as much work, or the strategic map views, or the special abilities.  R.U.S.E. displays far, far more UI attention and innovation than almost any game I’ve seen.

I don’t see a real multi-select solution– perhaps they’ve designed a lower population cap, squad-based game to work around this.  The pace of gameplay is also short of something like Starcraft.  I’m still really excited: R.U.S.E. is clearly the most serious attempt at RTS on the console shown yet.

Here’s your typical RTS match: skirmish for a while with your level one troops. Eventually, one or both of you research some improved units, and branch out a bit, choosing units and counters. If the game continues, you tech up some more, and reach your next tier/level of units.

With this traditional ordering, each level of unit becomes rarer than the previous, since there’s the chance that the game won’t reach any level beyond the first. The casual player might get mighty sick of space marines, but not get nearly enough mecha-spacezilla.

The traditional RTS’s tech order is like a pyramid: tons of level one, a narrower level 2, and so on, and the top level is rare and pointy.

Does an RTS need this shape? Could an RTS offer up its “tiers” a la carte, any researchable at any time? Or could the research areas be arranged like a ring, which could be entered at any point, and research could continue in either direction?

I’ve been meaning to write about WoW’s Great Wall-sized social barriers for a while now, but Blizzard’s latest announcement of cross-faction transfers (for a fee) seems as good a time as any.

A while back, some devs decided to try World of Warcraft as a sort of “golf” for game developers.  It rapidly failed– not because most of them didn’t play WoW, but because most of them couldn’t play together.

The chance that a given player in the U.S. is on your same WoW server is less than 1%.  Then, the chance they’re on your faction is about 50/50.  The chance that they’re at a character level, equipment level, and commitment level to go out and productively kill something with you… well, combine them all, and they’re miniscule.

Of course, that’s not what WoW’s about.  Warcraft is about finding one group of enablers to play with regularly.  It’s not social like Facebook– it’s social like a cult, or the mob.

What a lot of would-be WoW-killers don’t realize is that it’s tough to pull people out of their cult– and if they leave, it’s not to join another cult.

The next “WoW killer” needs to be more subtle, more Facebook.  And you’re seeing plenty of it already, sneaking in through games like Call of Duty.  A Call of Duty player wouldn’t tolerate it for a second if the game said, “sorry, you can’t play with that friend– he’s on a different realm.  Oh, and level up, and reroll Horde.”

Yes, you’ll lose some of the strong bonds of something like WoW.  And maybe you can’t pull off some of the same persistent world coolness.  (If you decide to just “ditch realms”, how do you design or implement a world for 100,000 people?)  But modern, multiplayer shooters are showing you can still create a strong, enabling community out of that.  (Heck– so are the old shooters.)  They just need to figure out how to charge a monthly fee.

As a thought experiment, what would happen if WoW just made server transfers and faction transfers isntant and free?  Maybe a touch more griefing, though I’m not convinced.  The impact on server economies would give the hard core auctioneers more to do, not less.

One of the biggest losses would be the loss of the “big fish in a little pond”.  How can you be the third best guild on your server when guilds can jump from server to server on a whim?  Many game services, such as XBox Live, offer a friends-only top scores list, but that’s a bit trickier with WoW’s structure.  Plus, it’s not just the technical aspect– it’s walking around with that guild tag over your head, or recognizing the other folks in other server-best guilds, or with rare (on that server) gear.  How do you create that “little pond” again, to regain all the social pressures and rewards that come with it?

I’m using a ton of web apps nowadays. It’s mostly cool, but I have an idea.

You know that plugin you use to deploy your webapp? Or, like Wordpress, the plugin you offer to speed up the app’s performance? I think you could add a couple of key features.

First, maybe the plugin could make your app launch in its own window, with a custom icon for the taskbar. That way, I could find your app faster! Plus, maybe you could capture all input, so that I don’t worry about whether Ctrl-B is going to bold my text or make a bookmark. Also, what if you optimized the code a bit more– maybe skip past some of that browser gunk in the way, so your web app doesn’t slow down my (fairly beefy) computer? And shoot, as long as you’re doing all that, maybe you could put all the necessary code on my computer, so that I can run the “web app” while I’m offline.

I can’t believe I just put all those great ideas into one post– I could’ve kept them to myself and made a fortune.

From Joystiq’s report on the Uncharted 2 multiplayer beta.  You can see this train coming down the tracks:

Players will still take team damage from grenades as they did before…

Go on…

…but accidentally grenade killing your whole team in the first seconds of a game are being fixed for the full game.

Accidentally?  C’mon, Naughty Dog, you don’t really believe that, do you?

We are also tweaking the “kick” system.

That’s what I thought.

We (Williams Franklin Creative) are looking for around 5-10 hours a week of web dev help.  Know anyone?

The core skills we’re looking for are LAMP+AJAX: most of the work will consist of creating and customizing Wordpress-based sites, plus some other utility scripts and such.  Strong CSS skills, or even some design skills, are a plus but not necessary.  I’d think any good, web-oriented developer could fit the bill.

There are plenty of contractors available on eLance et. al., but we’re looking for someone more focused on quality, than on meeting the minimum specifications.  Toward this end, it’d also be nice if we could meet in person.  San Francisco Bay Area is ideal, but not a requirement.

If you know any good web developers who could use a few extra hours a week, let me know!  Even if you’re not positive it’s a fit, we’re interested in talking with talented people– even if we don’t end up working together right away.

In a recent discussion of game AI, someone helpfully pointed out an article from Damian Isla on the Halo 2 AI.

Despite being from 2005, the article’s still remarkably relevant (but that’s another post).  I highly recommend you read it if you’re into game AI, but it’ll require a bit of time.  It’s a solid rundown on the contemporary AI toolbox.  (It doesn’t discuss more rarely used models such as Fear’s GOAP.)

The basic approach is a “behavior tree” (actually a directed acyclic graph).  Each node consists of a list of potential behaviors, with a decision-making mechanism to choose between them.  Leaf nodes carry out the actual behavior.

The primary decision-making algorithm is the prioritized list.  Basically, you list a few behaviors in order, say: flee, fight, chill.  And then you ask them: “hey, do you want to flee?  No?  Okay, do you want to fight?  No?  Okay, then chill.”  If flee had answered yes, then you’d stop right there, and you wouldn’t ask fight.

I prefer this to another algorithm, the scoring mechanism.  Or, as the article puts it:

Numerous systems feature an analog activation desire: each child provides a floating point number indicating its relevancy, and the child with the highest relevancy wins (with the previous tick’s winner given an added bonus to avoid dithering).

The article mostly discards this option, but I’d like to go into a bit more depth.

I’ve given up on scoring systems for anything other than weighting random selection.  It’s far too easy to accidentally make value judgments.  The idea that you’re going to know every possible scoring of every competing behavior is unrealistic.  So you end up intentionally making the judgment “moving to melee range is more important than ranged against enemy X, but less important than fleeing”, but you end up also ranking your “moving to melee range” behavior against your “get in the vehicle” behavior, or more likely your “get in the vehicle when there’s driver X /Y / Z / no driver / the vehicle is on fire / you’re close to the vehicle / you’re far from the vehicle / the turret is unmanned ” behavior.

Still, I find scoring useful for weighting randomized behavior selection, but I’m unsatisfied with how I usually compute the scoring values when using it for that purpose.

Basic randomization example: you’ve decided that you’re going to perform a melee attack, but you’re thinking about which one.  The opponent is blocking, so a block-breaker is of higher value than normal, and a blockable melee is a bit lower value.

The weighting factor for that is still a black box.  ”Hey, heavy attack behavior: on a scale of 0-1, how valid are you?”  ”Uh… 0.5?”  ”Hey, standard weapon attack: how about you?”  ”Um… 0.7?”  You could restrict the return values to a descriptive enum, say, “awesome, standard, crappy, or invalid”, which each scale the score by a predefined amount, and make it easier for designers to control.  It still seems like an inelegant hack, and I’m open to suggestions.

Returning to the article, it goes into a lot of cool ways to make your prioritized lists more dynamic.  For instance, a Halo 2 squad seeing its leader get killed will cause a high-priority flee action to get inserted into one of the behavior tree nodes for several seconds, potentially causing the squad to run like hell.

An important note: I enjoyed Halo’s enemy AI, but not necessarily because it was substantially better than in competing games.  Halo did a great job of communicating what its AI was doing, through animation and voice cues.  Your AI’s awesomeness doesn’t matter if the player can’t tell what’s happening.

So, you’ve just designed a sweet new bus door. Then it goes into use, and you hear this initial suggestion:

Have informational ads in multiple languages to inform the public on how to open the rear doors.

Haven’t we figured out doors already?

Wow.  I hope my next game inspires someone to make something this beautiful. Cool if you haven’t played WoG, but better if you understand the Painter’s Sign reference:

I had a ton of SXSW Interactive thoughts I wanted to post, but this is keeping me pretty busy!  I’ll aim for some quick bites, and hopefully get the important stuff down.

First off: the panel I was on, “Playing On! Interface Lessons from Games,” went well!  Game talk was everywhere at SXSW.  Everyone wants to use games as a model to improve their app or business model, and I thought our panel was one of the few talks to bring concrete ideas to the table.

John Mark did a great job finding strong panelists and getting ‘em all to work in a similar direction, resulting in a pretty full hour of content.  (Side note: I got to check out panelist Brian Robbins’/Fuel Games’ “Vans SK8″ iPhone game before the panel.  It used a pretty cool combination of accelerometer and touch gestures to specify tricks.)

I think there’s supposed to be some audio or video of the panel made available eventually, but I don’t know, so here’s what I’ve got:

• Slides!
• Liveblog!

Neither is very intelligible without audio and video, so here’s hoping.  Thoughts in brief:

• Exploration– and correspondingly, the acceptability of failure– is a major difference between app and game design.  UX designers frequently aim for 100% success rate with new users choosing the correct way to do something.  Game designers are perfectly okay with you missing that jump a few times, or getting hit by that enemy– you’re learning.
• Why is exploratory learning fun, while other kinds can be dreadful?  How come the tutorial portion of an otherwise excellent game can be worse than learning Microsoft Outlook?  We spent a bit of time talking about safe and fun learning environments, but this area could use more study.  Note, though, that removing “exploratory” from “exploratory learning” is usually the fastest way to remove the fun.
• We talked about the interface opportunities of the Wii and iPhone.  Wii is game-specific and iPhone isn’t, but I’m still unconvinced that either can offer a deep, satisfying game experience that wouldn’t be as good or better on a “traditional” game platform.  Maybe that’s more about use scenario and target audience than interface, though.  Maybe they aren’t aiming for depth.
• There was a lot of discussion about achievements, reputation systems, and other feedback/reinforcement mechanisms.  These seem to be the most advanced example of crossover between games and apps– they’re a natural fit with social media.
• Progressive complexity, and tools as inventory items, came up.  Somebody just needs to do this already, so we can talk about why it failed.