Back when I was in college, I thought scripting languages solved all my game development problems. I could write some scripts to do everything I needed and keep my code clean. I got rapid iteration and my code was in a form other people can muck with. How awesome is that?
Of course, the situation isn’t nearly so neat and tidy. Scripts themselves are code, and keeping those clean is work unto itself. Getting proper rapid iteration working requires a fair bit of work. And letting people edit scripts who don’t have a programming background can very often explode in your face.
But that’s not where my biggest problem resides. No, my biggest problem is that most scripting systems lack sufficient debugging capabilities.
(Side note: When I talk about debugging throughout this post, I’m specifically talking about the context of using a scripting language within the larger framework of a game. The situation changes when using a scripting language as the primary development medium).
Visual Studio has made some amazing strides in the realm of debugging such that virtually every other tool - Eclipse and XCode included - is living in the stone age. Developing code is much more pleasant when I don’t have to litter code with print statements and call out to a command-line debugger. I can jump around the call stack, set break points and watch variables, setup watches for when memory changes, and easily step through the code line-by-line.
Unfortunately, when we use scripting languages in our games, we’re generally giving all that up. When something breaks down, about all we can do is get a call stack and (if you’re lucky) inspect some variables. We can’t even trace through the code to identify when things break down.
In essence, we’re taking the single greatest boon modern development environments provide (or try to provide but fail miserably in the case of XCode) and you’re throwing it out the window. We are forced to go back to caveman debugging - placing print statements all over the code to try and spot when things break. How is that a good idea?
Emergent realized this. A significant chunk of one of my co-worker’s time while I was there was spent developing an integrated Lua debugger that mimicked Visual Studio as best it could. I used it a few times, and it was refreshing to gain the advantages of scripting while avoiding the biggest pitfall.
Unfortunately, this isn’t always the case, especially with indies who don’t have the time to develop a fully featured script debugger. Integrating a full scripting solution then becomes work that generates more work for not so much gain. That’s… not good.
Scripting still has appropriate domains in the indie space. For small chunks of functionality that are modular and easy to write and require fast iteration - for instance, the spell effects in an RPG or weapon behavior for a shooter, or transitions for a UI - scripting is still invaluable. But I definitely don’t think script code should drive the bulk of a game.
This line has no context. It is not tied to the above post in any way.