A few publishers have figured out that the Wii market is different than the hardcore market from before, but that requires an understanding of a very different demographic than has bought Doom, Gears of War, and Call of Duty in the past.

Now that Microsoft’s Natal and Sony’s motion controller have been announced, the day for the joystick might seem to be limited.  However, not every player nor every gamer wants to jump around the room, regardless of the genre.

This year is different for me, since I have meetings about my studio.  Normally, I am there representing EA or Sony, so I am approaching things from the publisher or platform side, instead of as a developer.  As it is, I have meetings every day, all day, which will make for a great E3!

Press release

Interview at GamesIndustry.biz

One of the most obvious issues is knowing when the file has actually been loaded.  In an asynch environment, you issue a request, and some time later, the request is fulfilled.  Most systems return a handle which the game can check periodically to see if the data has been read.  This is fairly easy to implement, works well in a multithreaded environment, and is pretty easy to debug.  Other alternatives are to use a callback mechanism or put the calling thread to sleep until the data is loaded.  The sleep option is usually done in custom scripting languages, instead of trying to do it in C++.

A standard approach is to compress the data at build time and decompress at run time.  If you are reading from DVD or Blu-ray, then it is practically a requirement due to the slow read speeds of those media.  On the PS3 or XBox360, it is common to have your file system decompress on the fly, either on the SPUs or on another core.  The complication is that you are no longer loading the data directly where it will be used.  Instead, you need to load it a temporary buffer, decompress the data, then write it to the final memory location.

On some consoles, there is not unified memory.  This means that you need to decide either ahead of time or at load time where the data will be loaded.  On the PS3, half of the memory is “main RAM” while the other half in “graphics memory” (ignoring that data can be moved and read between the two systems).  A simplistic approach is to put the data in the RAM segment based on the type of data…geometry to RSX memory, AI parameters to system RAM.  Since some types of data can be in either segment, this approach limits how flexibility the memory arrangement is.

Most file systems use a Table of Contents (ToC) to manage where and how the data is loaded.  Having a ToC for the data which is loaded gives:

• Position on disc
• Memory segment to load into
• Compression parameters
• Data type
• Resource Id
• Human readable name

A ToC also gives you flexibility during development.  The ToC can either contain all of the data in a single packed file, or it can simply list the files which need to be loaded.  Assembling a packed file can take a lot of time during development, especially when you have just changed one file.  This arrangement also makes it easy to do single file overrides.  Your nightly build system creates packed files for the game from checked in assets, but individuals can modify single files which are loaded seperately from the main packed file.

If you can override individual files, then you should look into hot-reloading of data: reloading data in the middle of the game so that artists can see texture changes without restarting, etc.  On the prototype I’m working on, I have a PC app which monitors my processed file directory and sending a message over the network to the game to reload it.  I have the file change logic on the PC in a single app, while the hot reloading is based in the game itself.  Since I’m working on a multiplatform game, this makes it easy for any new platform to load in the file.  Even the PC version registers itself with the file monitor app instead of scanning the directories explicitly.

One minor point to mention is that DX9 is not fully multithreaded.  This means that if you are allocating vertex, index, or texture buffers, they all have to be done from the render thread.  Microsoft explains it fairly well in this presentation.  This restriction makes it a bit more complicated, but it mostly involves extra signaling between the loading and render thread.

As a note, these are only my views and do not represent my current employer, SCE, EA, or any past employers.  These views are also not based on any “inside” information, but instead are based on many years in the video games industry.

It is absolutely true that of the current consoles (PS3, XBox360, and Wii), the PS3 is the most complicated.  However, there are two aspects to developing on a console.  1) The hardware and 2) the development environment.  The thing that the author of the CNET article seemed to forget is that (excluding Nintendo), selling software is what makes the money, not selling the hardware.

The games industry makes most of its money from sequels and yearly franchises.  The Madden’s, the Guitar Hero’s, etc.  These publishers need to have consumers buy their games every year.  If there isn’t something which makes the game better each year, then why would consumers purchase it?  This concept extends to franchises such as Halo and God of War.  While I would love it if new stories and gameplay drove game sales, it is not not borne out by the sales numbers each month.

For the XBox360, there is a very easy to understand hardware and a great development environment.  This means that the games made today are not going to be much different from the XBox360 games of “tomorrow.”

For the PS3, it is a complicated hardware and historically is not a great development environment.  This means that games towards the end of the console will look much better than those at the start as developers learn how to take advantage of the hardware.  Keep in mind that currently, many hardcore consumers are looking for the better shiny object and realistically do not care about “story” and “gameplay innovation.”

Between the hardware and development environment, one of these can change over the course of a console’s lifecycle (and it isn’t the hardware…).  While the PS3 is still difficult to develop for, it has gotten much better over the past couple of years.  This means that developers are able to use more of the hardware and make their games better looking.  On the XBox360, how different is Gears of War 1 from Gears of War 2?  On the PS3, it will be interesting to compare Uncharted 1 to Uncharted 2 this next holiday season.

So put Kaz’s comments into perspective.   If the software looks the same every year, then why would consumers buy the next version of something?  If the software gets better every year, then consumers are likely to purchase it to be on the best and brightest.  This philosophy served Sony very well on the PS2.  The question is if it will work on the PS3…especially when it does not have the same market share.

And I love taking BART every day.  My commute time is about the same as when I was at EA and Sony, but now I get to read and relax with my iPod.

…but something came up…

I am starting a new game studio in San Francisco.

I have noticed an interesting way that I play games these days.  Keep in mind, I have children and interests outside of the games industry.

On my home consoles (which include a PS3, XBox 360, and Wii), I tend to play games which are pick up and play, usually with no story.  This includes Boom Blox, The Last Guy, Eden, and Braid.  Basically, all games which I can play for 15-30 minutes and then turn off the console.  Also, I don’t have to worry about remembering some involved story to get back into the game.

On my portables, I am playing the long, involved story games.  I just finished Crisis Core: Final Fantasy VII and it looks like I’m going to get back to The Legend of Zelda: Phantom Hourglass soon.

The interesting thing to me is this is completely backwards to how people are “supposed” to play games.  My pickup games are on my home system with the big plasma TV, while the long session games are on my portable systems.  It reflects my life these days…I have very little time at home to play games, but when I travel, I’m trapped on an airplane for ten hours at a time.

1. It is hard to debug the tasks when there are hundreds or thousands a frame
2. I want to emulate the PS3 SPU local store, which means segmenting my memory space

To make each of these easier to deal with, all of the task entry functions take an argument. This argument is a pointer to a ClTaskArg class. Tasks are expected to derive from this class to get their arguments into, and potentially out of, the task function.

Here is the basic flow chart for how a task gets executed in my app.

The decision points are mainly decided by the settings in the argument. This is different from how most PC or XBox360 apps would work, since they have unified memory. By creating a Local Store for the Task Function, it forces the app to think about how memory is handled and when to actually do a writeback. The nice thing about my system is that a fair amount of the memory handling is done automatically without having to explicitly do the memcpy() in the user’s code.

A simplified and incomplete version of my ClTaskArg follows. It mimics the PS3 by using EA – Effective Address. The implementation is missing, as well as a lot of the header itself, but it should give an idea of how I deal with the argument into the Task Entry Function.

class ClTaskArg
{
    public :

        //////////
        // Get the size of this structure
        int            getSizeOfStruct() const    { return(mcSizeOfStruct); }

        //////////
        // Get the write back address
        // [out] ClTaskArg * - the pointer in main RAM.  NULL if no write back
        ClTaskArg      *getThisEA() const         { return(mpThisEA); }

        //////////
        bool           breakOnEntry() const       { return(mBreakOnEntry); }

        //////////
        ClAlloc        *getLocalAllocator()       { return(mpLocalAlloc); }

    protected :

        //////////
        // Constructor
        // [in] sizeOfStruct - the full size of the structure to transfer
        // [in] writeBackStruct
        //        - should the structure be written back to main RAM on exit?
        ClTaskArg(int sizeOfStruct, bool writeBackStruct)
            : mpThisEA(0), mcSizeOfStruct(sizeOfStruct), mBreakOnEntry(false)
        {
            if (writeBackStruct)
            {
                mpThisEA = this;
            }
        }

    private :

        // Address of this structure in main RAM
        ClTaskArg    *mpThisEA;
        // The memory allocator for this core
        ClAlloc      *mpLocalAlloc;
        // The size of the structure
        const int    mcSizeOfStruct;
        // Should the thread break on entry?
        bool         mBreakOnEntry;
};

http://blog.us.playstation.com/2008/06/06/playstation-edu/

It is a program to get development hardware into the classrooms of universities and colleges.

I am giving a talk about it at the Game Education Summit next week in Dallas.

[update]

Made slashdot!