Scripting Languages are Overrated
2,601
2
Advertisement
Back when I was first starting ambitious game dev projects, I believed a good scripting system solved a lot of problems:
(1) It appeared super modular. After all, I could keep so much game logic outside of my code and only use C++ for engine development.
(2) Rapid iteration! Who doesn't want to change a logic file and instantly see the results on screen?
(3) Everyone can understand scripting languages. I mean, c'mon, Lua is the most readable thing ever.
I went down the scripting road, rolling my own, integrating outside languages, and bragging about how awesome my code was. Except that it wasn't - pretty much none of the above was actually true. And there were hidden costs I wasn't seeing.
Since then I've had the opportunity to mature a bit, and I've worked on large code bases with varying amounts of scripting in place. This has caused me to reevaluate the above.
(1) was true enough, I guess, except where you have to worry about binding. Where scripting languages are involved, a healthy portion of engine code must be dedicated to getting the engine & scripts to communicate. Scripts aren't much good if they don't know about game objects after all. This is less true with languages like C# where reflection can automagically handle a lot of the binding, but if you've ever looked at code that binds Lua & C++ you know it's a mess. Plus in the end, even if we discount binding, the scripts aren't any more modular than, say, just having separate source files in their place.
(2) is incredibly tempting, but it comes at a non-significant cost in development time. Rapid iteration isn't free, and depending on the game's complexity, can be prohibitively difficult. That's just for PC development - if you want rapid iteration over an iPhone or an Xbox, you're looking at a whole new set of challenges. It's great if you have the time to develop and maintain it, but it's a lot of work.
(3) completely depends on your people; Lua and Python are a little easier on the eyes to those who don't code all day, but in the end that's mostly syntax and semantics - the real challenges of coding are more about problem solving. Odds are if you have people who can write good Lua code, they could write the equivalent in C++ with a little added extra education (you may want to leave out pointers/dynamic memory, though). More importantly, a lot of people *don't* write good script code, and so you're looking forward to a bright future of hearing "Hey Engineer, come help!"
Those are rebuttals to the initial three points, but I also mentioned hidden costs associated with scripting.
(1) The number one thing most engine integrated scripting systems lack is a good visual debugger, and that's a crime. By far the largest boon of modern development environments (ie Visual Studio) is a quality debugger. I used to tell my operating systems class that they'd be spending upward of 70% of their time debugging problems, and I think that's true with a lot of development (especially at the end cycles). With a large group of game scripting systems, the best you can hope for is a stack trace. Helpful, but not a lot. Willfully throwing away a debugger is crazy talk. Of course, you can develop an integrated debugger, but that's tricky business.
(2) You're moving a lot of errors to be run time checks instead of compile time, and that time adds up, especially if you're developing for a system where the turnaround time between changing something and reinstalling the game is non-zero (ie: iPhone). I can't count how many times I've made a silly Lua mistake over the last couple months only to slap my forehead and have to restart the program. Depending on your system, the error may not even be immediately evident. If scripting errors cause a soft fail + error log versus a hard break, you could overlook a vital error.
So that's that.
The above might give you the impression that I hate scripting, which isn't completely accurate. If you have the time to create a proper rapid iteration solution and a real-time visual debugger, scripting can be pretty awesome. Even without that, confining scripting to small chunks of logic that can easily be made iteration friendly (ie: spell effects) has proven to save me a lot of time. But unless it can be done right, using scripting to drive game logic can often involve more work than it saves.
(1) It appeared super modular. After all, I could keep so much game logic outside of my code and only use C++ for engine development.
(2) Rapid iteration! Who doesn't want to change a logic file and instantly see the results on screen?
(3) Everyone can understand scripting languages. I mean, c'mon, Lua is the most readable thing ever.
I went down the scripting road, rolling my own, integrating outside languages, and bragging about how awesome my code was. Except that it wasn't - pretty much none of the above was actually true. And there were hidden costs I wasn't seeing.
Since then I've had the opportunity to mature a bit, and I've worked on large code bases with varying amounts of scripting in place. This has caused me to reevaluate the above.
(1) was true enough, I guess, except where you have to worry about binding. Where scripting languages are involved, a healthy portion of engine code must be dedicated to getting the engine & scripts to communicate. Scripts aren't much good if they don't know about game objects after all. This is less true with languages like C# where reflection can automagically handle a lot of the binding, but if you've ever looked at code that binds Lua & C++ you know it's a mess. Plus in the end, even if we discount binding, the scripts aren't any more modular than, say, just having separate source files in their place.
(2) is incredibly tempting, but it comes at a non-significant cost in development time. Rapid iteration isn't free, and depending on the game's complexity, can be prohibitively difficult. That's just for PC development - if you want rapid iteration over an iPhone or an Xbox, you're looking at a whole new set of challenges. It's great if you have the time to develop and maintain it, but it's a lot of work.
(3) completely depends on your people; Lua and Python are a little easier on the eyes to those who don't code all day, but in the end that's mostly syntax and semantics - the real challenges of coding are more about problem solving. Odds are if you have people who can write good Lua code, they could write the equivalent in C++ with a little added extra education (you may want to leave out pointers/dynamic memory, though). More importantly, a lot of people *don't* write good script code, and so you're looking forward to a bright future of hearing "Hey Engineer, come help!"
Those are rebuttals to the initial three points, but I also mentioned hidden costs associated with scripting.
(1) The number one thing most engine integrated scripting systems lack is a good visual debugger, and that's a crime. By far the largest boon of modern development environments (ie Visual Studio) is a quality debugger. I used to tell my operating systems class that they'd be spending upward of 70% of their time debugging problems, and I think that's true with a lot of development (especially at the end cycles). With a large group of game scripting systems, the best you can hope for is a stack trace. Helpful, but not a lot. Willfully throwing away a debugger is crazy talk. Of course, you can develop an integrated debugger, but that's tricky business.
(2) You're moving a lot of errors to be run time checks instead of compile time, and that time adds up, especially if you're developing for a system where the turnaround time between changing something and reinstalling the game is non-zero (ie: iPhone). I can't count how many times I've made a silly Lua mistake over the last couple months only to slap my forehead and have to restart the program. Depending on your system, the error may not even be immediately evident. If scripting errors cause a soft fail + error log versus a hard break, you could overlook a vital error.
So that's that.
The above might give you the impression that I hate scripting, which isn't completely accurate. If you have the time to create a proper rapid iteration solution and a real-time visual debugger, scripting can be pretty awesome. Even without that, confining scripting to small chunks of logic that can easily be made iteration friendly (ie: spell effects) has proven to save me a lot of time. But unless it can be done right, using scripting to drive game logic can often involve more work than it saves.
Advertisement
Advertisement
Advertisement
Discussion