The sweng-gamedev list is all a-flutter with a debate about the merits of scripting in games.  I wrote up a response that describes our experiences and figured I’d share it here too.

We had Lua integrated into the client and wrote much of our UI logic written in it. We struggled with bugs in our glue layer, difficulty debugging, and major spikes in our frame times whenever the garbage collector ran. Of course the glue code was terrible to begin with and we were exporting script hooks for much of the game instead of a nice clean interface, so that didn’t help. After a while we started moving away from Lua and began implementing new UI in C++. We’ve now removed all the Lua from the game.

On the gameplay side we use a rich data-drive system that lets designers define an arbitrary list of “requirements” with which they are able to test most any condition. When a trigger fires, object is used, or skill is activated, an arbitrary list of “results” is activated which is capable of modifying just about any state in the game.  The designers also have a few ways of maintaining persistent state on the characters depending on the circumstances.  This system is working pretty well for us and eliminates the need for any designer-written scripts.

If I ever integrate scripting into an engine again, there are several things I’ll do differently to make it go more smoothly:

1. No designer scripting.  If designers are writing scripts, You’re Doing It Wrong. Scripts are code, and need to be just as maintainable as all your other code.
2. A much cleaner API layer between the C++ code and the script code.  Exporting the whole game to Lua was just dumb.
3. A built-in debugger. Printf-style debugging is so incredibly painful when you’re used to having a rich source-level debugger.
4. Built-in profiling. All calls across the native/script interface should be timed and memory consumption should be strictly monitored.
5. Dynamic script loading. Part was stupid glue and part was just our poor use of the scripts, but the first time around we ended up loading all the scripts when the client booted and couldn’t reload most of them. This one of the major advantages of scripting and we were missing out on it.
6. Much more evaluation time. We know a bunch of things to look for the next time around including slow garbage collection, object lifecycle issues, memory corruption in the glue, testability of the scripts in isolation, etc.

On the other hand, I think writing servers in a higher-level-than-C++ language like C# or Java makes a lot of sense and would save us tons of development time. It’s the dynamically typed language with no debugger that didn’t work well for us.

I’ve been thinking a bit lately about outsourcing. Specifically outsourcing the programming on a game. You see, I have a boss who thinks it’s funny to talk about how we programmers ought to be careful not to demand too much in the way of salaries or benefits or all our jobs are going to go to India.

I’ve decided he has basically no idea what he’s talking about. There is no risk of any significant amount of game code work moving offshore. Unless he’s going to move the entire studio to India my department is pretty secure. (Or at least as secure as anyone can be in an industry where there’s news of a studio going under about once a month.)

Rands in Repose posted on the subject of outsourcing a while back. He wrote that “Cogs get outsourced” and included a list of questions that help you evaluate your offshore risk factor:

• How much process is there in your job? Do you follow a proscribed rigid work regimen? Do you know what you are going to be doing every single hour of every single day?
• Can you see a flow chart from where you’re sitting right now?
• Can you see a work-provided clock (not yours) from where you’re sitting right now?
• Do you work in customer service or technical support?
• Are there big black binders which describe the work that you do?
• Is there a glossary for new hires?
• If you work in software development, are you handed specifications from nameless, faceless designers? Do you NOT have a relationship with the people who are responsible for testing your work?

Let’s see how we game programmers do:

• Our jobs contain a moderate amount of process; we are somewhere between artists (lots of process) and designers (almost no process) on that scale. Our process tends to be in the form of best practices: code reviews, unit tests, checkin procedures, naming conventions. We never perform the same task twice.
• No.
• Yes, but no one pays it any attention.
• No.
• Nope.
• Yes, sort of. There is a lot of vocabulary for a new hire to learn when they join the team, as well as the best practices described above.
• Hah! The designers have a good idea what they want to see in the game, but will freely admit that they will need to adjust things once they see their designs in action. The artists have basically no idea what they want and require constant high-contact attention. Of all our customers, only Operations is able to write a detailed spec of what they want. We interact with every customer on a daily basis.

The fact is, game programmers are not cogs. We work on something different every day. We constantly adapt to changing requirements from all of our varied customers. We don’t work from a script, and are probably the least compartmentalized group on the team.

A recent news item on Gamasutra seems to contradict this idea. It cites a study by Amritt Ventures that says 22% of developers outsource some of their programming work overseas. Unfortunately the study itself doesn’t seem to be generally available, so I couldn’t look up who participated in the study, how “programming” is defined. And like all studies of outsourcing I’ve read it’s full of apparently contradictions. When 27% of developers have fired three or more outsourcing vendors and 27% also complain about poor quality from outsourcing vendors, why is outsourcing still on the rise?

The answer might be found here. Amritt Ventures will help you to outsource entire games overseas. Moving the design alongside the programming certainly eliminates the communication problems that 12 time zones would cause. And at a very high level it’s relatively easy to spec out an entire game. For instance: “I need a tie-in game for this movie and I need it in 12 months.” or “I need a flash game to advertise this cereal.” If you really about the low-level details of the game you get, you’re probably at least partly a designer, and this kind of outsourcing isn’t for you.

There are obviously also home-grown game designers in India and China that want to build their own visions, that just doesn’t really count as outsourcing.

When it comes to US game developers outsourcing the code overseas and keeping the design in-house, I just don’t see it happening. And I don’t see Flying Lab’s leadership transferring itself to India any time soon, so design isn’t moving overseas either. Despite the FUD surrounding outsourcing in the larger high tech industry, it seems like one thing we game programmers don’t have to worry about.

We just had our first stress test for pirates. I just posted a devlog with the details. Except for the first three hours (which were glorious) it was a 4 day long marathon debugging session. I don’t think I’ve ever been so exhausted as I was on Sunday night.

Still, it was totally worth it. We learned many things about our server and where they break that will hopefully let future tests run much more smoothly.