Time for action — Configuring ConTEXT

Now we'll set up ConTEXT to make reading UnrealScript easier, and use it to compile scripts with a single button press.

What just happened?

ConTEXT is now set up to compile our UnrealScript files; all we have to do is press F9. The first time we do this it will also recompile Epic's UnrealScript files, this is normal. The compiler may also show up in a separate window instead of at the bottom of ConTEXT, this is also normal.

Starting to feel like a programmer yet? Now that we're able to compile code we just need an easy way to browse through Epic's UnrealScript source code, and to do that we're going to install another small program, UnCodeX.

UnCodeX

We can write our own code with ConTEXT, but now we need something to make sense of the Development\Src folder. There are over 2,000 files in there! This is where UnCodeX comes in. UnCodeX organizes the files into a class tree so that we can easily browse through them and see their relationship to each other. It also allows us to quickly search through the source code, which is where the line numbers in ConTEXT come in handy when we're searching through our own code.

Using Memory Correctly

Did you ever hear the joke about the programmer trying to beat the Devil in a coding contest? Part of his solution involved overcoming a memory limitation by storing a few bytes in a chain of sound waves between the microphone and the speaker. That’s an interesting idea, and I’ll bet we would have tried that one on Ultima VII had someone on our team thought of it.

Memory comes in very different shapes, sizes, and speeds. If you know what you’re doing, you can write programs that make efficient use of these different memory blocks. If you believe that it doesn’t matter how you use memory, you’re in for a real shock. This includes assuming that the standard memory manager for your operating system is efficient; it usually isn’t, and you’ll have to think about writing your own.

Understanding the Different Kinds of Memory

The system RAM is the main warehouse for storage, as long as the system has power. Video RAM or VRAM is usually much smaller and is specifically used for storing objects that will be used by the video card. Some platforms, such as Xbox and Xbox360, have a unified memory architecture that makes no distinctions between RAM and VRAM. Desktop PCs run operating systems like Windows Vista, and have virtual memory that mimics much larger memory space by swapping blocks of little-used RAM to your hard disk. If you’re not careful, a simple memcpy() could cause the hard drive to seek, which to a computer is like waiting for the sun to cool off.

System RAM

Your system RAM is a series of memory sticks that are installed on the motherboard. Memory is actually stored in nine bits per byte, with the extra bit used to catch memory parity errors. Depending on the OS, you get to play with a certain addressable range of memory. The operating system keeps some to itself. Of the parts you get to play with, it is divided into three parts when your application loads:

• Global memory: This memory never changes size. It is allocated when your program loads and stores global variables, text strings, and virtual function tables.

• Stack: This memory grows as your code calls deeper into core code, and it shrinks as the code returns. The stack is used for parameters in function calls and local variables. The stack has a fixed size that can be changed with compiler settings.

• Heap: This memory grows and shrinks with dynamic memory allocation. It is used for persistent objects and dynamic data structures.

Old-timers used to call global memory the DATA segment, harkening back to the days when there used to be near memory and far memory. It was called that because programmers used different pointers to get to it. What a disgusting practice! Everything is much cleaner these days because each pointer is a full 32 bits. (Don’t worry, I’m not going to bore you with the “When I went to school I used to load programs from a linear access tape cassette” story.)

Your compiler and linker will attempt to optimize the location of anything you put into the global memory space based on the type of variable. This includes constant text strings. Many compilers, including Visual Studio, will attempt to store text strings only once to save space:

const char *error1 = "Error";
const char *error2 = "Error";

int main()
{
   printf ("%x\n", (int)error1);
   // How quaint. A printf.
   printf ("%x\n", (int)error2);
   return 0;
}

This code yields interesting results. You’ll notice that under Visual C++, the two pointers point to the same text string in the global address space. Even better than that, the text string is one that was already global and stuck in the CRT libraries. It’s as if we wasted our time typing “Error.” This trick only works for constant text strings, since the compiler knows they can never change. Everything else gets its own space. If you want the compiler to consolidate equivalent text strings, they must be constant text strings.

Don’t make the mistake of counting on some kind of rational order to the global addresses. You can’t count on anything the compiler or linker will do, especially if you are considering crossing platforms.

On most operating systems, the stack starts at high addresses and grows toward lower addresses. C and C++ parameters get pushed onto the stack from right to left—the last parameter is the first to get pushed onto the stack in a function call. Local parameters get pushed onto the stack in their order of appearance:

void testStack(int x, int y)
{
   int a = 1;
   int b = 2;

   printf("&x= %-10x &y= %-10x\n", &x, &y);
   printf("&a= %-10x &b= %-10x\n", &a, &b);
}

This code produces the following output:

&x= 12fdf0  &y= 12fdf4
&a= 12fde0  &b= 12fdd4

Stack addresses grow downward to smaller memory addresses. Thus, it should be clear that the order in which the parameters and local variables were pushed was y, x, a, and b. Which turns out to be exactly the order in which you read them—a good mnemonic. The next time you’re debugging some assembler code, you’ll be glad to understand this, especially if you are setting your instruction pointer by hand.

C++ allows a high degree of control over the local scope. Every time you enclose code in a set of braces, you open a local scope with its own local variables:

int main()
{
   int a = 0;
   {           // start a local scope here...
     int a = 1;
     printf("%d\n", a);
   }

   printf("%d\n", a);
}

This code compiles and runs just fine. The two integer variables are completely separate entities. I’ve written this example to make a clear point, but I’d never actually write code like this. Doing something like this in Texas is likely to get you shot. The real usefulness of this kind of code is for use with C++ objects that perform useful tasks when they are destroyed—you can control the exact moment a destructor is called by closing a local scope.

Video Memory (VRAM)

Video RAM is the memory installed on your video card, unless we’re talking about an Xbox. Xbox hardware has unified memory architecture or UMI, so there’s no difference between system RAM and VRAM. It would be nice if the rest of the world worked that way. Other hardware such as the Intel architectures must send any data between VRAM and system RAM over a bus. The PS2 has even more different kinds of memory. There are quite a few bus architectures and speeds out there, and it is wise to understand how reading and writing data across the bus affects your game’s speed.

As long as the CPU doesn’t have to read from VRAM, everything clicks along pretty fast. If you need to grab a piece of VRAM for something, the bits have to be sent across the bus to system RAM. Depending on your architecture, your CPU and GPU must argue for a moment about timing, stream the bits, and go their separate ways. While this painful process is occurring, your game has come to a complete halt.

This problem was pretty horrific back in the days of fixed function pipelines when anything not supported by the video card had to be done with the CPU, such as the first attempts at motion blur. With programmable pipelines, you can create shaders that can run directly on the bits stored in VRAM, making this kind of graphical effect extremely efficient.

The hard disk can’t write straight to VRAM, so every time a new texture is needed you’ll need to stop the presses, so to speak. The smart approach is to limit any communication needed between the CPU and the video card. If you are going to send anything to it, it is best to send it in batches.

If you’ve been paying attention, you’ll realize that the GPU in your video card is simply painting the screen using the components in VRAM. If it ever has to stop and ask system RAM for something, your game won’t run as fast as it could.

Mr. Mike’s First Texture Manager The first texture manager I ever wrote was for Ultima IX. (That was before the game was called Ultima: Ascension.) I wrote the texture manager for 3DFx’s Glide API, and I had all of an hour to do it. We wanted to show some Origin execs what Ultima looked like running under hardware acceleration. Not being the programmer extraordinaire, and I only had a day to work, my algorithm had to be pretty simple. I chose a variant of LRU, but since I didn’t have time to write the code to sort and organize the textures, I simply threw out every texture in VRAM the moment there wasn’t any additional space. I think this code got some nomination for the dumbest texture manager ever written, but it actually worked. The player would walk around for 90 seconds or so before the hard disk lit up and everything came to a halt for two seconds. I’m pretty sure someone rewrote it before U9 shipped. At least, I hope someone rewrote it!

Optimizing Memory Access

Every access to system RAM uses a CPU cache. If the desired memory location is already in the cache, the contents of the memory location are presented to the CPU extremely quickly. If, on the other hand, the memory is not in the cache, a new block of system RAM must be fetched into the cache. This takes a lot longer than you’d think.

A good test bed for this problem uses multidimensional arrays. C++ defines its arrays in row major order. This ordering puts the members of the right-most index next to each other in memory.

TestData[0][0][0] and TestData[0][0][1] are stored in adjacent memory locations.

Row Order or Column Order? Not every language defines arrays in row order. Some versions of PASCAL define arrays in column order. Don’t make assumptions unless you like writing slow code.

If you access an array in the wrong order, it will create a worst-case CPU cache scenario. Here’s an example of two functions that access the same array and do the same task. One will run much faster than the other:

const int g_n = 250;
float TestData[g_n][g_n][g_n];

inline void column_ordered()
{
  for (int k=0; k<g_n; k++)           // K
     for (int j=0; j<g_n; j++)        // J
        for (int i=0; i<g_n; i++)     // I
           TestData[i][j][k] = 0.0f;
}

inline void row_ordered()
{
  for (int i=0; i<g_n; i++)           // I
     for (int j=0; j<g_n; j++)        // J
        for (int k=0; k<g_n; k++)     // K
           TestData[i][j][k] = 0.0f;
}

The timed output of running both functions on my test machine showed that accessing the array in row order was nearly nine times faster:

Column Ordered=2817 ms  Row Ordered=298 ms  Delta=2519 ms

Any code that accesses any largish data structure can benefit from this technique. If you have a multistep process that affects a large data set, try to arrange your code to perform as much work as possible in smaller memory blocks. You’ll optimize the use of the L2 cache and make a much faster piece of code. While you surely won’t have any piece of runtime game code do something this crazy, you might very well have a game editor or production tool that does.

Memory Alignment

The CPU reads and writes memory-aligned data much faster than other data. Any N-byte data type is memory aligned if the starting address is evenly divisible by N. For example, a 32-bit integer is memory aligned on a 32-bit architecture if the starting address is 0x04000000. The same 32-bit integer is unaligned if the starting address is 0x04000002, since the memory address is not evenly divisible by 4 bytes.

You can perform a little experiment in memory alignment and how it affects access time by using example code like this:

#pragma pack(push, 1)
struct ReallySlowStruct
{
   char c : 6;
    __int64 d : 64;
   int b : 32;
   char a : 8;
};

struct SlowStruct
{
   char c;
   __int64 d;
   int b;
   char a;
};

struct FastStruct
{
    __int64 d;
   int b;
   char a;
   char c;
   char unused[2];
};

#pragma pack(pop)

					  

I wrote a piece of code to perform some operations on the member variables in each structure. The difference in times is as follows:

Really slow=417 ms
Slow=222 ms
Fast=192 ms

Your penalty for using the SlowStruct over FastStruct is about 14 percent on my test machine. The penalty for using ReallySlowStruct is code that runs twice as slowly.

The first structure isn’t even aligned properly on bit boundaries, hence the name ReallySlowStruct. The definition of the 6-bit char variable throws the entire structure out of alignment. The second structure, SlowStruct, is also out of alignment, but at least the byte boundaries are aligned. The last structure, FastStruct, is completely aligned for each member. The last member, unused, ensures that the structure fills out to an 8-byte boundary in case someone declares an array of FastStruct.

Notice the #pragma pack(push, 1) at the top of the source example? It’s accompanied by a #pragma pack(pop) at the bottom. Without them, the compiler, depending on your project settings, will choose to spread out the member variables and place each one on an optimal byte boundary. When the member variables are spread out like that, the CPU can access each member quickly, but all that unused space can add up. If the compiler were left to optimize SlowStruct by adding unused bytes, each structure would be 24 bytes instead of just 14. Seven extra bytes are padded after the first char variable, and the remaining bytes are added at the end. This ensures that the entire structure always starts on an 8-byte boundary. That’s about 40 percent of wasted space, all due to a careless ordering of member variables.

Don’t let the compiler waste precious memory space. Put some of your brain cells to work and align your own member variables. You don’t get many opportunities to save memory and optimize CPU at the same time.

Virtual Memory

Virtual memory increases the addressable memory space by caching unused memory blocks to the hard disk. The scheme depends on the fact that even though you might have a 500MB data structure, you aren’t going to be playing with the whole thing at the same time. The unused bits are saved off to your hard disk until you need them again. You should be cheering and wincing at the same time. Cheering because every programmer likes having a big memory playground, and wincing because anything involving the hard disk wastes a lot of time.

Just to see how bad it can get, I took the code from the array access example and modified it to iterate through a three-dimensional array 500 elements cubed. The total size of the array would be 476MB, much bigger than the installed memory on the test machine. A data structure bigger than available memory is sometimes called out-of-core. I ran the column_ordered() function and went to lunch. When I got back about 30 minutes later, the test program was still chugging away. The hard drive was seeking like mad, and I began to wonder whether my hard disk would give out. I became impatient and re-ran the example and timed just one iteration of the inner loop. It took 379.75 seconds to run the inner loop. The entire thing would have taken over 50 hours to run. I’m glad I didn’t wait. Any game written badly can suffer the same fate, and as you can see, the difference between running quickly and paging constantly to your hard disk can be as small as a single byte.

Remember that the original array, 250 elements cubed, ran the test code in 298ms when the fast row_ordered() function was used. The large array is only eight times bigger, giving an expectation that the same code should have run in 2384ms, or just under two-and-a-half seconds.

Compare 2384ms with 50 hours, and you’ll see how virtual memory can work against you if your code accesses virtual memory incorrectly.

Cache Misses Can Cost You Dearly Any time a cache is used inefficiently, you can degrade the overall performance of your game by many orders of magnitude. This is commonly called “thrashing the cache” and is your worst nightmare. If your game is thrashing cache, you might be able to solve the problem by reordering some code, but most likely you will need to reduce the size of the data.

Writing Your Own Memory Manager

Most games extend the provided memory management system. The biggest reasons to do this are performance, efficiency, and improved debugging. Default memory managers in the C runtime are designed to run fairly well in a wide range of memory allocation scenarios. They tend to break down under the load of computer games, though, where allocations and deallocations of relatively tiny memory blocks can be fast and furious.

A standard memory manager, like the one in the C runtime, must support multithreading. Each time the memory manager’s data structures are accessed or changed, they must be protected with critical sections, allowing only one thread to allocate or deallocate memory at a time. All this extra code is time consuming, especially if you use malloc and free very frequently. Most games are multithreaded to support sound systems, but don’t necessarily need a multithreaded memory manager for every part of the game. A single threaded memory manager that you write yourself might be a good solution.

The Infamous Voodoo Memory Manager Ultima VII: The Black Gate had a legendary memory manager: The VooDoo Memory Management System. It was written by a programmer who used to work on guided missile systems for the Department of Defense, a brilliant and dedicated engineer. U7 ran in good old DOS back in the days when protected mode was the neat new thing. VooDoo was a true 32-bit memory system for a 16-bit operating system, and the only problem with it was you had to read and write to the memory locations with assembly code, since the Borland compiler didn’t understand 32-bit pointers. It was done this way because U7 couldn’t really exist in a 16-bit memory space—there were atomic data structures larger than 64KB. For all its hoopla, VooDoo was actually pretty simple, and it only provided the most basic memory management features. The fact that it was actually called VooDoo was a testament to the fact that it actually worked; it wasn’t exactly supported by the operating system or the Borland compilers. VooDoo MM for Ultima VII is a great example of writing a simple memory manager to solve a specific problem. It didn’t support multithreading, it assumed that memory blocks were large, and finally it wasn’t written to support a high number or frequency of allocations.

Simple memory managers can use a doubly-linked list as the basis for keeping track of allocated and free memory blocks. The C runtime uses a more complicated system to reduce the algorithmic complexity of searching through the allocated and free blocks that could be as small as a single byte. Your memory blocks might be either more regularly shaped, fewer in number, or both. This creates an opportunity to design a simpler, more efficient system.

Default memory managers must assume that deallocations happen approximately as often as allocations, and they might happen in any order and at any time. Their data structures have to keep track of a large number of blocks of available and used memory. Any time a piece of memory changes state from used to available, the data structures must be quickly traversed. When blocks become available again, the memory manager must detect adjacent available blocks and merge them to make a larger block. Finding free memory of an appropriate size to minimize wasted space can be extremely tricky. Since default memory managers solve these problems to a large extent, their performance isn’t as high as another memory manager that can make more assumptions about how and when memory allocations occur.

If your game can allocate and deallocate most of its dynamic memory space at once, you can write a memory manager based on a data structure no more complicated than a singly-linked list. You’d never use something this simple in a more general case, of course, because a singly-linked list has O(n) algorithmic complexity. That would cripple any memory management system used in the general case.

A good reason to extend a memory manager is to add some debugging features. Two features that are common include adding additional bytes before and after the allocation to track memory corruption or to track memory leaks. The C runtime adds only one byte before and after an allocated block, which might be fine to catch those pesky x+1 and x-1 errors, but doesn’t help for much else. If the memory corruption seems pretty random, and most of them sure seem that way, you can increase your odds of catching the culprit by writing a custom manager that adds more bytes to the beginning and ending of each block. In practice, the extra space is set to a small number, even one byte, in the release build.

Different Build Options will Change Runtime Behavior Anything you do differently from the debug and release builds can change the behavior of bugs from one build target to another. Murphy’s Law dictates that the bug will only appear in the build target that is hardest, or even impossible, to debug.

Another common extension to memory managers is leak detection. It is a common practice to redefine the new operator to add __FILE__ and __LINE__ information to each allocated memory block in debug mode. When the memory manager is shut down, all the unfreed blocks are printed out in the output window in the debugger. This should give you a good place to start when you need to track down a memory leak.

If you decide to write your own memory manager, keep the following points in mind:

• Data structures: Choose the data structure that matches your memory allocation scenario. If you traverse a large number of free and available blocks very frequently, choose a hash table or tree-based structure. If you hardly ever traverse it to find free blocks, you could get away with a list. Store the data structure separately from the memory pool; any corruption will keep your memory manager’s data structure intact.

• Single/multithreaded access: Don’t forget to add appropriate code to protect your memory manager from multithreaded access if you need it. Eliminate the protections if you are sure that access to the memory manager will only happen from a single thread, and you’ll gain some performance.

• Debug and testing: Allocate a little additional memory before and after the block to detect memory corruption. Add caller information to the debug memory blocks; at a minimum, you should use __FILE__ and __LINE__ to track where the allocation occurred.

One of the best reasons to extend the C runtime memory manager is to write a better system to manage small memory blocks. The memory managers supplied in the C runtime or MFC library are not meant for tiny allocations. You can prove it to yourself by allocating two integers and subtracting their memory addresses as shown here:

int *a = new int;
int *b = new int;

int delta1 = ((int)b - (int)a) - sizeof(int);

The wasted space for the C runtime library was 28 bytes for a release build and 60 bytes for the debug build under Visual Studio. Even with the release build, an integer takes eight times as much memory space as it would if it weren’t dynamically allocated.

Most games overload the new operator to allocate small blocks of memory from a reserved pool set aside for smaller allocations. Memory allocations that are larger than a set number of bytes can still use the C runtime. I recommend that you start with 128 bytes as the largest block your small allocator will handle and tweak the size until you are happy with the performance.

World of Warcraft adds another half million subscribers

by Peter Cohen, Macworld.com

Blizzard Entertainment has announced that World of Warcraft’s subscriber base has reached 11.5 million players worldwide, continuing its reign as the world’s most popular multiplayer online role-playing game.

The Wrath of the Lich King, Blizzard’s recently-released expansion pack for the game, has sold more than 4 million copies since its release on November 13, 2008. 2.8 million of those were sold in the first 24 hours of availability, according to Blizzard.

World of Warcraft has been available for the Mac and PC since 2004, and has spawned two expansion packs. The game—played entirely online—requires players to pay a monthly subscription fee in order to play. In October, Blizzard announced that it had hit the 11 million subscriber mark.

The last time Macworld reported on World of Warcraft subscriber statistics, forum commenters voiced some questions about how that number is tabulated. So without revision, here is Blizzard’s definition:

“World of Warcraft subscribers include individuals who have paid a subscription fee or have an active prepaid card to play World of Warcraft, as well as those who have purchased the game and are within their free month of access. Internet Game Room players who have accessed the game over the last thirty days are also counted as subscribers. The above definition excludes all players under free promotional subscriptions, expired or cancelled subscriptions, and expired prepaid cards. Subscribers in licensees’ territories are defined along the same rules.”

What if, like Dr. Frankenstein, you could stitch together the best bits of your favorite games to create a guaranteed hit? What if you knew adding a few key components to a title would boost its sales exponentially or extend its shelf life? What if there was a recipe for designing a perfect game?

Those were the answers I sought when I asked Electronic Entertainment Design and Research ( to run an algorithmic regression on a mock game called "FutureNot" that I whipped up. But such a recipe does not exist, says EEDAR President Geoffrey Zatkin. Games can't be assembled like a Mr. Potato Head doll--swapping out eyes and ears until you find the most agreeable feature set. But if you look at the whole game, it is possible to project sales and determine whether it is worth including specific ingredients.

This is the sort of stuff the Carlsbad, Calif.-based research company does all the time for clients like Electronic Arts (nasdaq: ERTS - news - people ), Activision (nasdaq: ATVI - news - people ) and Ubisoft. Since 2006, the 20-person firm has been busy compiling sales data, classifying games and cataloging key components--everything from the art style to the gender of playable characters.

With its database of 6,000 games, EEDAR analysts can use historical and competitive data sets to project sales for upcoming releases. It can also determine how certain developers and publishers, marketing budgets and release dates align to affect game sales.

"Every game I have ever worked on, we've gone in blind as to which features would sell the game better," says Zatkin, who designed games for 11 years before co-founding EEDAR. Not knowing whether it would be worth an extra $500,000 to design a multiplayer mode "would scare the crap out of me," he says.

Only 4% of games that make it to market actually make a profit, he says. About 60% of a game's budget is spent reworking or redesigning a game. Armed with all this data, companies can make those tough calls early in the development process.

As for "FutureNot's" potential success, Zatkin analyzed it and says it's "a surprisingly decent game" that could sell 216,000 copies in six months. He notes that most developers won't make a blockbuster like "Halo 3," which has sold more than 3 million copies so far.

Stop wasting money: video games and energy efficiency

      

 

In Pictures: Top 10 Games Starring Female Characters

After quickly disarming and incapacitating your pursuers, you clamber up some stairs and burst out onto a sun-drenched rooftop. Running full-tilt to the lip of the roof, you leap, roll to your feet and vault over air ducts before sliding to safety beneath a descending steel gate a few buildings away. Speedily threading your way through such obstacles is essential for survival as a lone runner against an entire police force that's trying to prevent you from discovering the truth behind a political assassination.

Welcome to "Mirror's Edge," Electronic Arts' (nasdaq: ERTS - news - people ) new parkour-inspired action game landing in stores Tuesday. What's unique about the game--beyond its use of the first-person vantage point, which is usually reserved for shooters--is that the main character is a woman.

The games industry has long catered to the core 18- to 34-year-old male demographic, so game developers often choose burly space marines instead of petite heroines as protagonists. But as the general audience of games expands--thanks to devices like the Nintendo (other-otc: NTDOY.PK - news - people ) Wii--it calls into question why female heroines are so under-represented in games.

In Pictures: Top 10 Games Starring Female Characters

According to the Entertainment Software Association, 40% of all game players are female, and nearly 30% of all console game players are women. But only 3% of games appearing on the current crop of Microsoft (nasdaq: MSFT - news - people ), Nintendo and Sony (nyse: SNE - news - people ) consoles star female characters, according to the research firm Electronic Entertainment Design and Research. Men fill the lead role in 46% of titles created for the latest consoles. The remaining games feature either customizable characters (normally found in role-playing games) or don't feature a lead character (such as the puzzle game "Tetris").

The industry is not necessarily opposed to putting females in games--some of gaming's most iconic leads are women. Bounty hunter Samus Aran made waves when it was revealed at the end of the first "Metroid" game that the person behind the suit was female. Lara Croft, the female adventurer modeled after Indiana Jones, has been raiding tombs since the late '90s. And there are a host of other games like Ubisoft's "Beyond Good & Evil" and Sony's "Heavenly Sword" that star strong female characters. Still, these heroines are vastly out-numbered by their male counterparts and, historically, developers have exploited female characters for their sex appeal.

That's why EA's decision to put the sleek and athletic Faith in the leading role of "Mirror's Edge" is so unique. "I find it's wearing a bit thin and [is] kind of childish," Owen O'Brien, the game's senior producer, says about the typical portrayal of gals in games. "I wanted to create an action hero who happened to be female--but could just as easily have been male--who wasn't trading on the fact that she was a sexual being. I was trying to create a character that was aspirational but attainable...[without] gravity-defying breasts."

Besides, says O' Brien, Faith fits perfectly into the role of a hunted runner far better than a man ever would. If she were male, he says, players would have immediately entered shooter mode--hunting for bigger guns and better armor--instead of relying on Faith's speed and agility to disarm or dodge opponents.

In the action genre that "Mirror's Edge" falls into, only 3% of titles released during this console cycle starred females. Men helm 51% of action games. Male characters also drive 73% of shooters while women star in a mere 1% of the games. The only genre where women have the upper hand is in Sims-like games where they star in 14% of the games versus 5% featuring men.

See chart for a full genre breakout

The only market where women are represented with the same frequency as men is in the casual games space. "The [casual] industry has leaned toward female characters," says Jessica Rogers, marketing director of Nickelodeon's Kids and Family Games Group. "It has a lot to do with the audience being predominately women."

With respect to the industry at large, O'Brien has a "gut feeling" that it's moving toward equal representation. "There are more girls playing games, but there's still a long way to go," he says.

Sarah Hoeksma, group marketing director at "Tomb Raider" publisher Eidos, says the ratio of female to male leads in gaming overall is already increasing. "A number of top publishers are now releasing games with leading female characters in games designed for gamers rather than the casual market," Hoeksma said in an e-mail. "If consumers show there is a demand for these characters, then the industry will continue to invest in the development of more female leads."

10. Rumble Roses XX

"Rumble Roses" is unapologetic in touting this wrestling game's "visual 'enhancements'"--it renders scantily clad women entangled in suplexes. If the female wrestlers--dressed up as cowgirls, schoolgirls and nurses--weren't scintillating in their barely there apparel, they also fight with bared breasts.

9. Petz: Horsez 2

The "Petz" franchise, alongside the "Imagine" line, is one of Ubisoft's core revenue generators in its Games for Everyone initiative, which generated some 25% of the companies revenues in 2007. The "Petz" games give players a virtual animal to dutifully play, train and groom. Horses, of course, appeal primarily to wee lasses, so it's of little surprise that "Horsez" stars a young female rider who gets to raise and breed steeds and participate in competitions.

8. Disney Princess: Enchanted Journey

Disney Princess is a $4 billion brand. All one needs to do is name drop Jasmine or Ariel and the toy will sell like hot cakes. "Enchanted Journey" is no different. Playing as a young girl, gamers must help four magical kingdoms--governed by the likes of Jasmine and Snow White--return to order after a witch stole attributes like color or time from the worlds. It's not deep, but Disney Princess is just right for the brand's 3- through 5-year

7: Dead or Alive: Xtreme 2

Team Ninja, the developers behind the "Dead or Alive" franchise, is well known for its catalog of busty vixens willing to fight to the death in mixed martial arts bouts. "Xtreme 2" is the follow up to spin-off "Xtreme Beach Volleyball"--basically a game about collecting various revealing sets of swim wear. The sequel beefs up its activity line up to include tug of war and jet ski racing. Don't forget the fan favorite "hip wrestling" where the girls face "back-to-back and cheek-to-cheek" as they attempt to bump each other off a platform and into a pool with their hips.

6. Okami Loosely based on a Japanese myth, players take control of the goddess Amaterasu in a quest to restore peace and beauty to a demon-infested land. Throughout her journey, a wolf, the corporal manifestation of the sun goddess, is called upon to both help out citizens and fight monsters. "Okami" was critically acclaimed for its art style and innovative use of calligraphy--armed with a "Celestial Brush," players could wipe out enemies with a single stroke.

E-Mail | E-Mail Newsletters | del.icio.us | Digg It! | My Yahoo! | Share | RSS

5. Lara Croft Tomb Raider: Anniversary

Lara Croft is one of videogaming's most iconic women; she was even awarded the title of most successful heroine by the Guinness World Record in 2006. Modeled as a female Indiana Jones, Lara--unsurprisingly--raids tombs in search of archaeological artifacts. The "Anniversary" edition is an ode to the original 1996 classic in celebration of the brand's 10th birthday.

4. Lara Croft Tomb Raider: Legend

Lara was always meant to be a strong female lead character, but as she aged her original developer decided she needed "sexing up." For 2006's "Legend," a new development team took the reigns and rebuilt Lara and her world from the ground up in the hopes of reinvigorating the franchise. In the process--and in an attempt to appeal to more female gamers--Lara's look shifted from buoyantly bosomed to an athletic build.

3. Hannah Montana: Spotlight World Tour

Catering to the young female audience on the Wii (and the PlayStation 2), "Spotlight World Tour" lets gamers dance along with Hannah Montana as she performs musical numbers from the Disney television show at venues across the globe in a rhythm game mash-up.

2. Heavenly Sword

Nariko, a female warrior wielding a life-sapping sword, must defeat an invading army intent on capturing and harnessing the sword's deadly power. There is also a complicated backstory about how Nariko was supposed to be born the great male heir who would save her clan.

1. Metroid Prime 3: Corruption

Bounty hunter Samus Aran, the star of Nintendo's "Metroid" franchise, is one of the first female protagonists to appear in videogames. When "Metroid" debuted on the Nintendo Entertainment System in 1986, Samsus was depicted simply as a cybernetic-suited hero. It was only at the end of the game that players learned the person behind the helmet was a female. "Metroid Prime 3" is the third installment in Nintendo's popular first-person adventure reinvention of the