The combination of HTML5, JavaScript, and CSS3 is going to make the Web a much more dynamic and exciting place, but is also going to require much more programming skill.

But recently, I’ve found myself spending most of my time in other languages.  Programming languages which, until recently, wouldn’t have been used by game programmers.  Things like Javascript.  Objective-C.  PHP.

One of the things which all of these languages share is that they are much more dynamic.  C++ and console programming depends on predictability.  This is helped through static typing.  Most of the “Web 2.0″ languages are so dynamic, that you do not find your errors until you run them.  This is both a blessing and a curse.  It is a blessing since your apps and libraries can be much more dynamic, not needing to resolve functions and messages at compile time.  It is a curse, since the compiler will gladly let some code through which is complete garbage, simply because it thinks that you are sending a message which will be resolved at runtime.

It is interesting to see how people deal with this.  A standard way is to have a naming and formatting convention which “shows” you what needs to be done.  This seem to be the case with create vs init functions in Objective-C.  Of course, everyone has picked a different naming convention, so when you mix and match libraries, you are completely confused how to call the various functions.   But at the end of the day, I have to realize that I’m still generally more productive in dynamic languages than in C++.  When you aren’t constrained by a console with fixed hardware and memory, then why use a language that forces you into that mindset?

And the irony?  I used to program NeXT computers about 20 years ago.  And now I have to remember what a .xib is?

One of the “must have” hacks for my terminal window is getting the current path into the title and customizing the prompt.  With a bit of Google-fu, I was able to figure out the command sequences to do this.  Just add the code below to your

~/.bash_profile

To set the title of a Mac Terminal Window:

function settitle() { echo -ne "\033]0;$@\007"; }

function cd() { command cd "$@"; settitle `pwd -P`; }

settitle `pwd`

To set the command prompt so that it displays the current directory name with the history number of the command:

PS1="(\!):\W>"

These days, everything has changed.  The console market has moved to only big blockbuster titles.  Indie and B-level games don’t sell and publishers are running away from them.  Social/web/Facebook games are all the rage these days, but they depend on millions of eyeballs where a few users spend money to support all of the free players.  iPhone and Android games are trying to figure out how to navigate a market where anyone in their garage can publish a game, even if most of them are garbage.  And the Wii market has imploded for 3rd party publishers (IOW, everyone except for Nintendo).

So does this mean that it is all doom and gloom for independent developers?  I think that it is the exact opposite.  Developers who can be quick and nimble are going to succeed.  There are a lot of opportunities out there, but they aren’t the traditional business models.  Finding ways to leverage HTML5, social games on mobile devices, connected games on XBLA/PSN, etc are the wave of the future for developers who aren’t making God of War nor Halo.

However, it also means that if anyone outside of the guaranteed funded triple-A game tells you that “they know how to succeed”,  I would question how fast they can respond to a changing market.

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.