I’ve worked with a lot of awesome people in the games industry.  I’ve learned a lot from these people and I thought a great way of sharing their knowledge and wisdom would be to start a game developer spotlight.  This is my first attempt, I’m interested in people’s feedback.  I worked with Greg on Battlestar Galactica and on an unreleased title before leaving Auran.

• Firstly, could you introduce yourself, tell us what games you’ve worked on, how many engines you created, how long you’ve been programming and what you’re favourite games are?

I started programming as a 10 year old kid, with the Apple 2 computer my Dad bought.  My life’s passion has been making and playing games.  My work life started out porting games between Consoles, Arcade machines and PC.  I’ve been programming professionally now for 12 years . I have worked on what would be called engine technology for each of the three companies I’ve worked for.   I’ve worked on a number of projects that were not real high profile.  Some that people might have heard of are Krazy Ivan, ManxTT Superbike and The House Of The Dead for PC.  More recently, Battlestar Galactica  for Xbox.  An interesting side project was not  a game, but kind of like Auto Cad for Grandma, a 3D virtual home construction and decoration program that contained a lot of technical challenges.  As is normal in our industry, roughly half of the projects I’ve worked on have been canceled at some point.  I’ll try to refrain from long rants about the crazy way the game industry works and hopefully say things that might encourage young developers, in particular, programmers.

Here’s some of my favorite games: Master Of Orion, X-Com, Total Annihilation, Unreal Tournament, Battlefield 2. I’ll throw in Rescue Raiders as a classic and Mass Effect as a recently enjoyed title.

• You read through the source code of a lot of engines and SDK’s.  Can you tell us which ones you use, what you gain from this and whether you would recommend it to other engine programmers?

To be good at programming, you really need to read and write code, lots of it.  With the internet, open source, and mod friendly companies, there is plenty of source code to read, to learn from, as well as use to give your project a boost.  If you like a particular game, perhaps Fear, Half Life, or one of the Unreal or Doom games, I’d recommend downloading the SDKs.  Make a mod, or try to figure out how things work.  Sometimes the public source code is complete, other times it will just allow access to the engine via an interface.  I hesitate to mention specific engines or libraries, but I will anyway…  I think Ogre does lots of things the right way for rendering.  Bullet is becoming a solid physics system.  Raknet is an excellent networking layer.  The Doom3 (and related) SDK is quite elegant. The DirectX SDK is a solid place to start with graphics, sound, input and even basic maths.  I think that Microsoft’s effort on the Xbox 360 development tools make it the most enjoyable console development experience yet.

• You were one of two people that created GameMonkey Script, can you tell us a bit about what lead you to creating it and the lessons you learnt writing a scripting language.

GameMonkey Script is primarily the child of Matthew Riek.  He was the compiler writer and has a brilliant mind for such things.  I wrote some of the run time components and default bindings, and have been maintaining a public build since the code was released.  We surveyed scripting languages and their use in games (and tools), and zeroed in on Lua, which looked like what we were after, and was gaining credibility.  We almost used it ‘as is’, but after discussing what features we wanted, as C/C++ programmers, making games and tools, GM was birthed in a very short time.  The project it was intended for was canceled, but we thought the language was so cool, we sought permission to release it publicly.  Now, with more experience using scripting languages in production, and being exposed to mature managed languages like C#, we realize with hind sight clarity that we didn’t make all the right decisions.  The GM language is still fun, flexible and simple, and has a growing community, as well as street cred, having been using in a number of games and on a variety of platforms.  I don’t want to raise expectations about the future, but I am hoping Matt and I can put our lessens to use and show something exciting in the future.  I would like to say that there is no such thing as the ultimate language, but there are ‘the right tools’ for a job, and in my mind, there is currently the need for native, managed and embedded languages.

• Where do you see games and game engines going in the coming years?  What are your thoughts on multi-processor support within game engines and in general game coding?

We may have hit a small plateau with game visual quality at the moment.  The kind of specs presented by current PCs and Consoles allow stunning visuals but it is hard to see where a big leap could occur.  Games commonly contain familiar systems of audio, graphics, physics, networking.  I think there is room for improvements at two ends of the system.  1) Internally, integration of existing systems, the way game entities are configured and coded, in particular, working with content from the creation process.  2) The user interface, as a combination of hardware controls and on screen visuals.  With (1), we need simple and flexible ways to define behavior of everything from breaking floor boards to boss character robots, accessing and using art, sound, movement, and interacting with systems like collision, physics, navigation and networking, so this is still a challenge to ‘get right’ and provide new levels of interactivity.  With (2), I am convinced that most current games are let down by their interface, which is the single most important part of the game, I mean, that is where the player meets the game, what could be more critical?  I was happy to see Nintendo attempt new things with the Wii and DS systems, at the hardware level.  I recently enjoyed playing Rainbow Six Vegas on Xbox 360, renewing my faith that ‘shooter’ type games and a tactical experience can be done and done well with a console control pad.

Multi processor systems are here to stay and become more numerous.  This really is a big problem for game developers who will be under pressure to make more use of the hardware.  Unless there is a significant break through with compiler or CPU technology that eases the burden, multi processing and multi threading will add pain, and create a new generation of really hard to debug programs.  Algorithms that look simple for a single threaded system can gain a lot of complexity when turned into versions that take advantage of parallelism.  Ideally you want to put independent bits of code on different threads, but when the number of threads (I will say threads instead of hardware CPUs that may run those threads), increases beyond 4 or 8, we will have to consider restructuring single tasks into parallel versions.  If you look further down the track, all multi processor systems will do is shift the bottleneck to another part of the system.  I personally believe that to take the next step into amazing simulations and interesting virtual worlds, we need fast random access to large volumes of memory, and use algorithms with deep and varied conditional branches.  This is the opposite to how hardware is currently going.  The cost of memory cache misses and mis predicted branches is extremely high.  Not all interesting algorithms can be broken down into CPU plus scratch memory/register size chunks for accelerated processing.

• What recommendations would you have for young game engine programmers who are looking to break into the industry?

1)    Read and write code, diversely, as mentioned earlier. Study all areas of game development.
2)    Don’t focus too much on just Graphics, Physics or other fun system.  Game Engines are more about the whole process of getting Level design content and Art content into games than on those exciting, but limited game systems.  Use yearly GDC notes and site like Gamasutra to read articles about game technology and tech issues.
3)    Think deeply about the interface to the game components and technical systems. How would you feel, if compelled to be the end-user of your own code?
4)    Don’t expect to be a one man band, or start a job in the exact position you would like.  Have a good attitude about working with and communicating with other people.
5)    Do think of the game industry as a realistic place for a career.  There is plenty of work and plenty of interesting challenges.
6)    Don’t be put off by the thought that all future games will be made from the one/few licensed engines (and if they are, be the one to make or work on them).
7)    Don’t forget tools.  They just may be more valuable than the run time technology!
8)    Don’t forget performance, but don’t let it decide the interface.  Remember John Carmack’s success.  Any high school student with a PC and DirectX/OpenGL accelerator can render a 10,000 polygon level at interactive rates, but Carmack did it on a 33mhz 486.  And that is a commercial advantage.  More performance always allows a better use experience, more content, and quite reasonably, more carefree content creation, because care = time = cost.

• You’ve done some work with C++/CLI and C#, can you tell us your thoughts on how these will fit into the games industry in the coming years?

C++/CLI pretty much just puts the entire C# language inside C++ so the two can work together seamlessly.  I love it.  No longer do I look enviously across at Visual Basic or Java programmers who can whip up UI applications, I now have all the tools too.  The .Net API finally nails shut the coffin of the horrible MFC and Win32 APIs, so UI and platform features can be accessed pleasurably.

At present I use C++/CLI for tools and C++ for games.  I would not be surprised to use CLI languages in future games themselves.  I know other people are doing that already, and Microsoft is forcing people to do that with the Xbox XNA kit.  I’m not convinced it’s time to leave native code yet, at least not for internal, technical systems.  The new managed languages do offer a bunch of features that improve high level coding, however half of these features could be added to C++ if the standards process would ever hurry up and be implemented widely.

• What are your thoughts on developers using in-house game engines versus off the shelf game engines (like the quake engine)?

The companies I’ve worked for have used a mix of internal and licensed engines.  Because I enjoy the technical more than gameplay side, I am biased in my opinion.  What I do know is that modifying some engines to meet the need of your game can be a major effort that puts into question the value of using a licensed engine in the first place.  In those cases, I think the better decision is often to fit your game within the existing framework rather than try to make modifications.

I would say, it depends greatly on the kind of game you are trying to make, the kind of people you have to make the game, and finally the companies future plans.  With licensed technology, you typically have to pay tens to hundreds of thousands of dollars, per product and per platform.  If you develop technology yourself, you accumulate the technology over time and own it.  On the other hand, the cost of making and maintaining the tech can be high, the staff may need specialized skills, and hiring people with existing engine experience may not be possible.

• Do you think the growing team sizes and budgets for games is good for the industry?

I will admit I don’t like big teams.  Small teams are fun and productive.  Team members communicate quickly and efficiently, there is a level of accountability in small teams since everyone knows what everyone else is doing.  There is more variety in work because people don’t just specialize in one area for the duration.  So, no, big teams and budgets won’t make the industry more fun or productive, but will likely be done because it can allow for more content and higher quality content.  The risks of a project going bad are greatly increased as well.  When I talk about productivity, I have seen large teams working at well under say 30% productivity, while a small team can work at about 70%.  Thinking that efficiency can ever reach 90% or so is pretty much impossible.  Humans get tired, have to solve hard problems and have to work together, and that doesn’t even account for the interaction with publishers, which from my experience usually decreases productivity further due to delays, changes and restrictions, amongst many other issues.  In the end, the larger team may be more successful, IF the project is finished and is accepted by the market.  That army of unhappy people just may produce a game who’s commercial success recovers its costs and then some.  Think of the risk though, and the rate of cash burn on big projects.  So to re-answer the question, good? No, inevitable? Yes.

• What would be your perfect project to work on?

I enjoy research, solving interesting problems, and more the technical side of games.  However, the most important thing for me is to work on a game that I actually want to play.  This should be the norm for our whole industry, but it is not.  I’d like to work on a small team, with complimentary skilled people, who have good attitudes and love games.  Is that too much to ask for?