Mark Danks

Moving back to development with my studio means that I have seen a lot about what publishers are looking for these days. Wii is, of course, very popular, but there is generally a desire to be “casual.” The interesting thing is that most publishers are unsure what that means. They want the popularity of the Wii, but still want to make games like they did for the PS2 and before.

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.

I am incredibly excited to launch my studio today.  I am the co-studio head for Zoë Mode San Francisco!  We are hard at work on a number of games and I am extremely honored to be working with such a great group of people.

Press release

Interview at GamesIndustry.biz

In most modern games, asynchronous file loading is a standard requirement.  This is especially true for open world games or games which never want to show a loading screen.  On the surface, it seems like an easy thing to do: spawn a new thread and load files on request.  However, there are a few complications which get in the way.

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 Continue Reading »

A recent CNET article has much of the blog-o-sphere commenting away like crazy.  The article contains a quote from Kaz Hirai from SCE that the PS3 is hard to develop for.  In reading the article, the author does not appear to have thought much about why Kaz might have said that.

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.

Continue Reading »

Due to the holidays, I actually have some time to get back to programming.  Up until now, my code has been focused on the machine and engine layers…rendering, memory management, job control, debug scaffolding, etc.  All of the items which are needed to get things on screen, but do not have any of the behavior nor game play parts.

Most game engines have gone away from trying to describe game objects with explicit C++ class hierarchies.  Very quickly, there is a base object called CObject which has everything but the kitchen sink in it.  This also creates an interconnected mess between the tick cycles for the object and all of the game systems.  It is very hard to parallelize the tick loop and impossible to move the objects off to extra processors such as the SPUs.

Continue Reading »

I made the leap.  Today was my last day at Sony.  It has been an amazing time there and I am truly honored to have worked with such talented people.

…but something came up…

I am starting a new game studio in San Francisco.

I am heading off for the next few days to an SPU seminar that I am running.  At work, I spend a lot of my time dealing with the SPUs on the PS3.  In fact, if you are using the libswcache libraries in your game, then you are using code that I wrote.  The SPUs are interesting beasts for multiprocessor work.  They are not as easy as the homogeneous multicore solution for the XBox360, but for raw processor power, not much can beat the SPUs right now.

My work tends to be around making the SPUs easier for developers to use.  Software caching (like libswcache) are ways to deal with non-uniform memory systems and making the architectural complexities more transparent to the end programmer.  I have a lot of experience with C++, so I have been looking at how templates and auto_ptr’s can help.  Libraries like these do not give you the peak performance, but it makes it much easier for the general gameplay programmers to work on the SPUs.  I have found that game development is a constant trade off between easy to use architectures which any generalist programmer can code for and extremely high performance architectures which require a specialist.

I spent the afternoon adding Lua to my code.  It only took about an hour to get the Lua library compiling and running.  The rest of the time was setting up the various hooks to make the scripting language actually functional.  I did not have time to add an interactive parser, that is on my list of things to do.

I have used Lua on previous games and never been that happy with it.  It tends to run slowly and require more memory than you would expect.  Also, most people tend to use it during development by reading in text files and doing on demand parsing.  This scares me since I prefer doing type checking and variable checking at a compile time…one typo and suddenly your run-time can blow up.  In some games, I have made the memory allocator throw an assertion if someone tried to allocate a var, string, etc. that was not seen before.  This seems to stop the typo problem, assuming that the game (and testers) have coverage over every script.

Continue Reading »

I have implemented a task system for my brushing program. In many ways, it emulates a PS3 by creating 6 threads which sleep until told to do something. That “something” is a function which does a task and then exits. There are two issues with this that I am resolving at the moment.

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.

Continue Reading »

I am only 20 pages into it, but The Art of Multiprocessor Programming has become my new reference book. It deals with all kinds of lock-free algorithms, queues, and synchronization methods.

Going forward, it is critical that programmers understand how to deal with multiprocessor systems. While this book focuses on shared memory systems, the concepts are still applicable to the PS3 (which does not have a shared memory system due to the SPUs).