I've been into several tutorials and links for how to integrate scripting into games--but most of these don't start early enough in the process for me. I am trying to wrap my head around the basic structure of an effectively scripted game. Here are the basics:
I'm working on starting a basic 2d RTS game in C++. The mechanics of the game and the graphics are pretty standard/simple, rather the logic and data will be extremely complicated compared to a standard RTS. Obviously, I have a lot of planning to do--and really, the point of this is more to learn C++, scripting, game programming basics rather than actually complete my project.
I'm trying to figure out which elements of my project should be handled by scripting and which should be included in my core "game engine".
For instance, the all powerful "game loop" -- do I program this in C++ as part of the engine, or will my "engine" be solely what I use for displaying graphics (tiles, characters, etc...), processing the large amounts of data, and similar tasks--and these classes get "plugged into" the game loop, which is scripted?
I would like to use C# as a scripting language, from what I've read it offers good speed while still allowing to develop in VS, which I like. But really, I'm more concerned with how it's all supposed to get set up, more from a pseudo-code level than the actual coding. There's plenty of resources I can use when I get to this point, I'm just looking for advice on how to structure the whole thing.
Any tutorials, resources, advice would be greatly appreciated! Thanks!
icnivad's recommendation for Programming Game AI by Example is an excellent one, it's chock full of practical information.
In terms of actual engines, Unity does the job and lets you script in C#, but for someone, such as yourself, who wants to learn the nuts and bolts, it may hide too much and do too much for you. Irrlicht is a pretty solid C++ engine and comes with lots of tutorials to get you started; it also has a very clear interface and a pretty active community. In terms of what you want to write in C++ and what you want to script, I suggest taking a hard look at what you actually need to script--if you need to script anything at all. You could write the entire thing in C++, which has the advantage of being more easily debuggable. Speaking of which, if you're still new to C++ and game dev you might want to stick to just C++ at first (if not, just ignore this).
"Debuggability" is one of the things you should be paying attention to, since it can often be extremely hard to debug C++ and script code at the same time (when you're shuttling data and instructions back and forth). That said, once you have your framework up and running, implementing new features and tweaking stuff can be a breeze.
You may want to take a look at Lua as a scripting language, as it's quite popular for game scripting. Luabind, a popular binding library for C++ and Lua, is pretty easy to use. SWIG is also available (a short tutorial on it popped up on a blog at GameDev.net recently).
No matter which scripting language you choose (if any), make sure you work on some separate toy programs with them first. Get used to the language and fiddle around with it. Then try small programs with minimal C++ <-> script interop. Do only a few steps at a time so you can spot errors and note what works and what doesn't. Once you feel ready to start integrating scripts into your game, do only one step at time and test it to death before moving on. Speaking of which, make sure you also plan how and where you'll connect your scripts to the game on paper first--it makes things much easier.
Generally, you'll want to put all the heavy work on C++'s shoulders (like the game loop, graphics, pathfinding, etc.). I've found that scripts are usually best for things like configuration files, behavior code for AI characters, UI, and event handling. Basically, if you're going to tweak/change something a lot or you want other people to be able to change something, it's a candidate for scripting (no recompiles for the win!). Just remember that a lot depends on your specific game--if scripting something would be too slow (use your profiler to check), too cumbersome, etc., don't be afraid to do it in C++ and call it from the script or just do it entirely in C++.
Hope that helps!
The book Programming Game AI By Example is superb, and touches on just what you are looking for regarding game loops, using scripting (like LUA), and tons of examples of stuff that seem especially pertinent to you.
By the way, potentially relevant is the Unity3D game engine that lets you use C# for scripting. And there is also Garage Games engines, including the game builder kits that could help you create an RTS type game, and I believe you may be able to code in C# for Torque as well.
Related
I've studied a bit of Lua, and I'm relatively familiar with C++ but I still don't see any real reason I would want to use Lua (or any scripting language for that matter) in conjunction with C++. If I'm already making a game in C++ (a fast language) why wouldn't I just do everything in C++? After all, I'm already familiar with C++. Why should I spend time learning a new language and how to integrate it into my C++ code? I'm sure there would be issues just getting the interface set up and working. Learning would take some time, how would it really pay off? Would it really only be beneficial to large development teams?
I echo what has been said, and I want to add my own thoughts as I am integrating Lua into my game engine this very moment!
It depends on what kind of game you are making, but regardless of your feelings on allowing fans to mod your game, it's just good practice to separate engine components from gameplay components.
The first major benefit is rapid iteration. The best decision I made was connecting the F5 key to reloading the Lua state (just like a browser's F5 refresh, in case that wasn't obvious). I can edit the script and then just mash F5 in my running engine to see the result right away. This is much more effective than rebuilding native code. You are less likely to lose your train of thought, and you can debug (gameplay) problems very quickly.
I find that working in Lua makes me more creative. It helps me set aside my rigid, unforgiving engineer brain and bring out my experimental, #YOLO brain. Why does my character's HP need to be carefully and precisely stored as a 32-bit integer in a C++ object? No part of the engine needs to know about that kind of information. The higher level gameplay is the only thing that cares. HP is updated only occasionally, and it relates to "the rules", not any kind of engine consideration.
Think of C++ as your master violinist and Lua as your conductor: your violinist better be really good/fast at playing the violin, but your conductor doesn't ever play the violin; he just tells your violinist to play louder/softer/faster/slower.
Lua is slow (relative to C++), but that is fine. Lua does not need to decompress an OGG into PCM in under 5ms; that is your engine's job. Lua makes extremely high level decisions: "This is the audio I want played at this moment."
I do many projects alone, and I can honestly tell you that integrating Lua is a very good thing. It creates a very clean separation between low level technical mumbo jumbo and your actual game.
It is generally good practice to split layers of an application from each other with abstraction.
Quite often part of your application is highly performance insensitive.
If you place a scripting interface between the high performance core and the performance insensitive scriptable portion, you first gain a huge abstraction layer benefit. If done right, no errors in the scripting portion can cause memory corruption or otherwise invoke UB.
So now that code cannot intermingle, and mistakes in it are insulated from the rest of the app.
On top of that, you now get to work in a language that makes many things (object lifetime, string manipulation, runtime modification of logic, etc) really easy. The lower risk from errors plus the ease of expressing things can massively increase your ability to prototype new functionality, and reduce QA overhead before shipping it.
On top of that, because you have a scripting engine, your game can now "safely" rewrite itself: doing so in C++ pure would be much harder. And rewriting yourself is a powerful tool, if dangerous (even "safely")
Mostly for flexibility, if you want to later change the behavior of something its easier just to change your script and reload it instead of having to re-compile your server.
Here is an overview as to why Cryengine uses it(engine for the popular game series Crysis): http://docs.cryengine.com/display/SDKDOC5/Script+Usage
and this is an MMORPG project that has its core in C++ and scripting in Lua: https://github.com/otland/forgottenserver/
Okay, so I've been getting into 2D game developing/programming , and many games I've seen use some sort of scripting language too. So I'm wondering - What's the purpose of using scripts in games? I know there's not simple one reason answer, and I've been trying to consider all the possibilities. Here's what I 'think' I know so far:
1) Scripts allow for changing the game without having to re-compile.
2) Scripts are easier for non-programmers to use.
3) Scripts allow me to separate the engine from the game itself allowing me to make other games with the same components quicker?
That's about all I'm aware of. My next question is, if I'm going to be Dev/programming a game alone - do I really need to use scripts? Or could I prototype the game using something like python or ruby, to allow for rapid testing, then rewrite the code in C++ saving time and compiler bugs, etc?
Another thing I'm wondering, Am I better off using Ruby or Python since I'm most experienced with those? Or should I use Lua, Perl or something else if it better fits what I aim to achieve? Speaking on that matter, what really should I use scripts for? should I use them to position and model game menu UI's, write/read save-files, load map levels, hold arrays or structures of game terminology such as "New Game" or "Quit," all of the above, none of the above?
If I make use of scripts, won't that allow game mechanics to be edited by the end user? Or is there a way to package the scripts into one compressed file that the engine can read?
Most basically, I'm wondering:
What should I use scripting in my game for? And why?
Do I need use scripting languages if I'm working alone or with programmers as opposed to Devs?
What scripting language 'should' I use if I were to be making platformers, RPGs, or what-have-you?
your top 3 reasons are all 100% correct and are the main reasons for using scripting languages along with your game engine.
Personally I've only really had experience with Lua through Luabind. It's a little tricky to setup but it was worth it. What you can do with scripting languages is expose the data structures and/or functionality that you want the 'user' in this case yourself, to be able to use. Generally speaking the only game mechanics etc that can be editted would be the ones you allowed them to.
What should I use scripting in my game for? And why?
Asset loading, exposing features/types, ie, for our game engine (written in c++), we had a base level, and then many different types of level inherriting from it, such as wave level, death match, etc. The user simply states in the script what type of level they need, and then chucks in the assets here too. In my demo we had;
Level="wavelevel"
--Level Initial number of enemies
EnemyNumbers="3"
--Level Total number of waves
WaveNumbers="4"
--Wave coefficient
WaveCoeff="1.1"
--Size of terrain
TerrainSize="256"
--Terrain file
TerrainFile="resource/Models/mountainous.raw"
Don't worry too much about the numbers and all of that.
As you can see that does some asset loading as well as determining the level type
We also gave a lot of control for the AI to scripts, in fact, the data structures were almost completely exposed to Lua.
Do I need use scripting languages if I'm working alone or with programmers as opposed to Devs?
Yes no maybe? We all prefer 'real' coding of course. If you can make your game engine abstract enough to build completely different games just with Lua, then it means you've done a great job and have designed it very well.
The other thing you have to think about, especially if you're game engine is quite huge, and lets face it, there isn't really going to be a small one, each time you compile, it can take minutes! It's the linker that's taking time here.
What scripting language 'should' I use if I were to be making platformers, RPGs, or what-have-you?
I've only ever used Lua, so that's the only advice I can give here.
Hope this is helpful info for you.
Honestly, as this sounds like your first attempt at a game ever, you shouldn't even be worrying about this sort of thing. Instead, I'd be more worried about keeping the scope of your project down to a level where you have a snow ball's chance of actually completing something. If you haven't done something at the level of Tic-Tac-Toe or Pong yet, do that first. What you learn there will be more valuable than worrying about a scripting language.
Oh and if you are doing an RPG as your first attempt at a game. Don't. They are by far the hardest type of game to do even for professional developers with many, many times the resources available to them. Keep it simple and and use this as a learning experience.
Back to your questions:
If you are the only one who will ever see your game, your choice on using a scripting language or not. If it will save you time overall or you want to learn how to do integration of scripting with code, go for it, but beware it will be a bit of a time sink.
Yes/no/depends on your second. If the scope of your game is small, scripting isn't as important. If you doing this alone, scripting isn't as important.
Your choice on what you know or what your engine will support (or what engine tools you cna buy to support). Lua is popular, but even hand rolled scripts will work as well. It's more about decoupling data from code and design type work from engineer type work.
Your initial points above apply. Scripts keep non coders out of code and allow anyone on a team to easily change data related stuff that should be in code anyways. Scripts also act as a very high level language allowing lots of game level changes in controlled ways that would/will look ugly if placed in code. I've personally worked on games that were done both ways. Scripted games were a bit easier to maintain at the end of the game cycle - IF IF IF the script support code was mature and had been run through some debug cycles. New script support code is harder to debug than coding things straight because there are more possible points of failure. Games that were coded without scripts tended to get done a touch faster, but required a lot more programmer/engineer time which means the overall scope of things had to be limited to stay on budget.
I will say that well designed scripting and overall gaming system will always beat straight coding. Look at Unity for an example of how scripting and code and everything else can be coupled into a slick interface that allows very quick game development.
What should I use scripting in my game for? And why?
The reasons you cited are good ones. One thing that you might need to understand is that most professionnal games are still built with C++ and it's far from being flexible to change if the code base is big. So if you use C++ you'll need scripting languages to make quick changes where it's imporant to be allowed to do so accordingly to the reasons you listed.
If you don't use C++, maybe you use a language that can absorb changes quickly, making the main purpose of scripting not so obvious. I wouldn't use scripting language in a Flash or Python game for example.
Do I need use scripting languages if I'm working alone or with
programmers as opposed to Devs?
As my previous answer : it depends on the timing of changes. Think that the core rules of games rarely change but everything relative to level design will, and should be testable ASAP. If you can do it in the game's programming language, why bother? If you can't, then any way to speed-up change integration will pay.
What scripting language 'should' I use if I were to be making
platformers, RPGs, or what-have-you?
Frankly, there is no one solution to any problem. I personally use Falcon and ChaiScript, Lua is well known but any scripting language that can be used with your game programming will do. That's a question already asked around and if you have doubt, just choose Lua as it's the most common in gaming.
I'll give you a quick and short answer. Scripts are mostly for changing things while the game is still running which you can edit things faster. This is much better then recompile, reloading the assets, going to the specific point in game, activate certain conditionals (items, talking to people in specific order, etc) and etc.
Things done in script are character speech, NPC interaction with triggers (for example walking somewhere stopping to talk to another NPC, then run somewhere, scripting is used for timing), triggers or events in general and enemy stats (health, speed, accuracy, sometimes logic for said character).
The reasons you list are all valid reasons for using scripting languages in games. I'd also add another reason though: different languages are better suited to different kinds of programming tasks and a high level scripting language allows you to write parts of your game in a language that might be a better fit than C++.
The main reasons C++ is widely used in games are performance, easy access to low level native APIs or hardware (on consoles) and inertia - most games are written in C++ so most third party libraries and middleware for games are written in C++ and most easily interfaced with from C++. For many tasks however higher level languages like Python, C# or Ruby have programmer productivity benefits over C++ that can outweigh the advantages of C++ for code that is not performance critical or does not have to interface with native APIs.
A well designed C++ game engine with a high level scripting language can give you the best of both worlds - the performance and low level access of C++ where it's most needed and the productivity benefits of a high level language where they are most needed.
As a matter of fact, almost all MMORPG game servers are programmed in script.
All the C++ engin will embed a script language for logic handling, lua is a suitable script language for it.
In bigworld, python is the default embed language.
And node.js is also a good candidate for game server programming. Because its network io ability is superior. There is an open source framework in node.js:
https://github.com/NetEase/pomelo/
I've found it unhelpful to use scripts, both when I was employed in a large game studio and in my work as an indie developer. On the other hand I have friends who've used professional-grade, modern engines with scripting technology successfully. As you're doing indie game development on your own (or in a small team), I think you should avoid it. The main reasons are:
It adds overhead pretty much everywhere: one more language to master (per developer in the team), performance is slower than native, and the API the weakest link which means you often need to rebuild the binary anyway.
The only real gain with a higher-level language is less development hours up front (if you're using a mature engine), but in my experience that time is eaten up by time-consuming bug-smashing in the end.
Many game scripting languages uses dynamic typing (Lua, Stackless Python, Pawn), which I find error-prone compared to statically typed languages. If you too feel it's only good for simple things, you might as well do it natively instead.
As a side-note I do find game scripting languages exceptionally useful, but only for quick-hack/prototype apps, not for huge components within games. See my answer here.
I'm not convinced scripting interfaces for games you write yourself are so useful. I did some work on Freeciv once, and immense effort went into enabling "modding" using the scripting interface. A feature that seemed little used. I think there is a danger of the inner platform effect. You don't need a scripting language to customize your game: you already have a perfectly good programming language (C++, in your case) for doing that. It's a WTF.
What should I use scripting in my game for? And why?
As everyone (including you) has said, scripts make your game easier to edit. On a larger team scripting also has a very good productivity effect: the tech-savy folks can continue to polish the engine, while the creative people can work on the actual game, and the two teams don't have to get in each other's way.
Do I need use scripting languages if I'm working alone or with programmers as opposed to Devs?
You don't need it and depending on what you're final goal is, it might actually be a waste of time to implement scripting. I also develop a 2D scriptable game atm; I'm alone but I'm making it scriptable also as a personal challenge and also because I want the game to be easily modifiable.
What scripting language 'should' I use if I were to be making platformers, RPGs, or what-have-you?
The top two most popular options are Lua and Python. Most people recommend Lua because it's slightly faster. I went with Python because it has (native) support for classes — which works well with my existing C++ architecture — and also because I find it to be a much more enjoyable language to work with.
Okay, I know this is a bit dead, but I have to say this. There is literally no such thing as programming without scripts. It honestly doesn't matter if you write them in yourself or not, fact is, somebody wrote those scripts. Like ruby, in order to use it, you need a program like say notepad+ in order to set it up, or any computer based RPG Maker from enterbrain uses a form of ruby to operate. like it or not, when using computers to design a game, learn to script. Now as for the language, look some up and try different ones out. Don't cheap out with using a pre compiled engine, just work from scratch. trust me, you will be better off. I am still trying to decide which I like better, Lua(C++) or Ruby. I may just use pure C++
I have a game which has different game types, i.e Time Trial, Infinite Game etc.
Each game type has different timing rules and potentially collision rules.
Obviously in the Time Trial the game ends when the time runs out.
I am currently adding game types by 'hardcoding' them into the program, therefore each time I want to add a new game type I have to recompile the whole program.
Basically to make adding game types easier I don't want to have to recompile everything. So potentially new game types could be downloadable content and would work simply by putting the new type in the game folder.
How would one go about doing this? I assume it is with the use of libs or dlls or something (I have very little knowledge about that so I might be completely incorrect).
I hope that all makes sense and I hope you guys can help me out or atleast point me in the direction of a book or article that explains this methodology.
Thanks in advance.
Using native DLL for game extensibility is IMO not a good idea, especially if the code is not designed for this from ground up.
You would best employ some scripting language like LUA or Python, so game modes can be added without writing and compiling C++ code. These are quite easy to implement (especially with if you use some binding/wrapper library), but require you to design a scripting API which can be a nontrivial task (depending on how much you want the game to be modifiable). This is now quite standard approach in game industry - most commercial games have some sort of scripting support these days.
Generally, the trend is to move as much code from core (C++) to scripts, because these scripts are easier to develop, maintain and modify. Many modern games have quite clean distinction between gameplay logic (written in scripting language) and game engine (written in C++ or another compiled language).
Background:
I have been working on a platformer game written in C++ for a few months. The game is currently written entirely in C++, though I am intrigued by the possibility of using Lua for enemy AI and possibly some other logic. However, the project was designed without Lua in mind, and I have already written working C++ code for much of the AI. I am hoping Lua can improve the extensibility of the game, but don't know if it would make sense to convert existing C++ code into Lua.
The question:
When, if ever, is it appropriate to take fully functional C++ code and refactor it into a scripting language like Lua?
The question is intentionally a bit vague, so feel free give answers that are not relevant to the given background.
Scripting languages are useful for things that might change frequently or be extended, and can afford the trade from speed.
It wouldn't make sense to use a scripting language in your core libraries, because those are relatively static (all they do is process stuff over and over) and need to be quick. But for things like AI, it's a perfect idea. You may tweak the AI without recompiling, and allow future changes quite nicely. Once you ship, you can pre-compile the scripting language and call it good.
It's also best for extensibility. Provide a Lua interface to your game and anybody can write plugins using a simple language, without the need for compiling. The more fleshed out your Lua interface, the more expressive and powerful those plugins can be.
If you've already got everything working, unless you intend on trying to improve it or allow extensions I don't really see a reason to strip it out; you're done. It would be something to keep in mind for your next game engine.
That said, if you're not completely done and this is a hobby/practice kind of thing, I would recommend you do. It will be your introduction into adding scripting capabilities to the game engine. When you get to making larger and more complex engines you won't need to worry about something new.
When, if ever, is it appropriate to take fully functional C++ code and refactor it into a scripting language like Lua?
Rarely. Here's when I've done it:
I wanted to change the design or add functionality in ways that would require me to revisit the C++ code anyway.
I found parts of the C++ code that I kept changing over and over.
I believed that by migrating from C++ to Lua that I could make the code five or ten times smaller.
The first two bullets are things anyone can do. The third requires some experience.
So I've been running into a debate at work about what the proper role of a scripting language is in game development. As far as I can tell there are two schools of thought on this:
1) The scripting language is powerful and full featured. Large portions of game code are written in the language and code is only moved into C++ when performance dictates that it's necessary. This is usually something like Lua or Unrealscript.
2) This scripting language is extremely limited. Almost all game code is in C++ and the language is only there to expose the underlying functionality to designers.
My frustration comes from seeing approach number two frequently abused, with large systems implemented in a language that does not have the features that make that code maintainable.
So I started out supporting approach number one, but after talking to some designers I realized that many of them seem to prefer number two, and its mostly programmers who prefer one.
So I'm still left wondering which approach is better. Am I just seeing bad code and blaming the tool instead of the programmer, or do we need really need a more complex tool?
The compile-link-run-test cycle for compiled C++ code when you're dealing with something as complex as a video game is very, very slow. Using a scripting engine allows you to make large functional changes to the game without having to compile the program. This is a massive, massive time savings. As you say, things that need optimization can be moved into C++ as required.
AAA engines are highly driven by scripting. Torque, used for Tribes II (and many other games!) is scripted, Unreal has Unrealscript and so on. Scripting isn't just for mods, it's key to efficient development.
I think designers need to see a language suitable for them. That's not negotiable: they have to spend their time designing, not programming.
If scripting allows fast development of product-worthy game code, then the programmers should be doing it too. But it has to be product-worthy: doing everything twice doesn't save time. So you have to keep scripting in its place. If a developer can script the inventory system in a week, or write it in C++ in a month, then you want full-featured scripting, if only to give you more time to hand-optimise the parts that might conceivably hit performance limits. So not the inventory, or the high-score table, or the key-mapping system, or high-level game logic like what the characters are supposed to be doing. That can all be scripted if doing so saves you any time at all to spend on speeding up the graphics and the physics: programmers need to be able to work out exactly what the bottlenecks are, and senior programmers can make a reasonable prediction what won't be.
Designers probably shouldn't know or care whether the programmers are using the scripting language to implement game code. They shouldn't have an opinion whether (1) is good or bad. So even if the programmers are right to want (1), why is this inconveniencing the designers? How have they even noticed that the scripting language is full-featured, if all they ever need is a fairly small number of standard recipes? Something has gone wrong, but I don't think it's that Lua is too good a language.
One possibility is that using the same scripting language for both, becomes an obstacle to drawing a sharp line between the interfaces used by designers, and the interfaces internal to the game code. That, as I said at the top, is not negotiable. Even if they're using the same scripting language, programmers still have to provide the designers with the functionality that they need to do their job. Just because designers use Lua to code up AI strategies and conversation trees, and Lua is full-featured language capable of writing a physics engine, doesn't mean your designers are expected to write their own physics engine. Or use more than 10% of Lua's capabilities.
You can probably do both (1) and (2), mind. There's no reason you can't give the programmers Lua, and the designers some miniature under-featured DSL which is "compiled" into Lua with a Lua script.
I think the balance you want is something to this effect: you want game logic in script, but game functionality in code.
One big big advantage of script is that you can set up waits easily. For instance:
enemy = GetObjectFromScene ("enemy01");
in 5 seconds { enemy.ThrowGrenadeAt (player); }
Just a contrived example. That kind of logic would be annoying to setup in C++. Script can make it easier to express this kind of logic, but you'd want the actual functionality (the functions it calls) to be in C++.
And script doesn't have to be slow. There are heavily scripted games running at 60fps on consoles, but it requires a good design and finding the right balance between your options 1 and 2 above.
I can't really see the argument that large amounts of scripted code is going to be superior to large amounts of C++. One could make the counter argument. I've seen terrible large projects written in scripting languages that started out with the scripting mentality--getting things done quick and dirty. This unfortunately doesn't scale well. There's really no way to make a code quality argument based solely on the programming language. People can write gobs of maintainable code in any language, compiled or scripted.
Anyway, its really impossible to know the line between your "approach 1" and "approach 2" without knowing where the performance bottlenecks are and what your users are going to most want to "script".
I would suggest an "approach 3" which is to do it all or in part in C++ and expose a clean SDK in C++. This would have the advantage of forcing you to write your code as if it were a user interface someone outside your organization has to use. It would hopefully cause it to be more maintainable AND have the added side effect of implementing your scripting interface for you. All your scripting interface would need to do now is forward to your SDK. Viola!
With this approach you avoid having to draw a line between the realm of what is "scripted" vs what is in C++. You and your users keep a choice to either add functionality in C++ with the SDK or use a scripting language.
As usual, I think the answer is "it depends."
There's NO WAY Halo 3 or Call of Duty 4 could have been based primarily on scripting. Top-rated AAA titles must, by definiton, push the envelope of any platform they touch. This just can't be done with scripting.
Casual games, however, are a different story. Major game eninges like Unity have lots of scripting built in.
There is also a market for mods. A solid game engine with a good scripting environment can be a platform for tweaks, derivations, and in some cases altogether new games. Counter Strike is my personal favorite example. I think you're limited in this case to FPS run-and-gun type games.
So, there is a place for scripting in games but it will probably stay in the small/casual game and modder's space.
One of the best examples of scripting in action is Civilisation IV. It uses Boost Python. As a result, it is horribly slow. A clear counterpoint to the statement that "code is moved into C++ when performance dictates that it's necessary".
The proper way is to design an architecture up fron, and decide which problems are computationally hard and which are complex to specify up front. Graphics, physics, pathfinding, instant feedback on input, text to speech - all clearly computationally hard. "Friendly or hostile stance", "defend or attack", "spend or save" type AI decisions are all complex to specify up front.
The conclusion is that you want to expose capable, but soulless actors to your scripting code. The scripting code describes what the actors should do, but the C++ code takes care of the how.
With regard to the compile-link cycle, it's important to have a proper modular architecture. When you are working on the pathfinding logic, you should never have to compile graphics code. Also, tools like Incredibuild can help speed up compile times. Big game firms probably already have a render farm, which can double up quite well as a compile farm.
Saying that games should be done just with C++ (or claiming that AAA titles are done like that) is just being ignorant. Most of the games nowadays are scripted in a way or another, be it proprietary scripting language (UnrealScript), generic language (Lua, python, C#, Java etc) or data-driven (xml, proprietary binary format etc). Just make some research and you'll find out that most engines employ scripting in one form or another.
I think the question of whether to have 1) powerful and full featured scripting language vs 2) extremely limited scripting language is approaching the problem from the wrong end. The scripting environment (language or data-driven) should be designed so that it best supports the process of creating the game. The expressiveness of the system is crucial here: the designers and scripters should be able to easily solve the problems they have without too much headaches while they shouldn't be exposed to too complex system that they have difficulties understanding and learning. Often programmers (myself included) tend to design systems by making assumptions how it is going to be used and trying to ensure that all features between earth and heaven could be implemented, resulting in complex systems. Being overwhelmed by this complexity, the designers end up using the minimum to get the work done.
For example in our game (Rochard) we designed a fully expandable and scriptable data-driven AI system, but the level designers ended up using just the stock AI patterns because they didn't have time or effort to utilize the AI system to its fullest extent. So in the end I just created a good UI for choosing those stock AI patterns easily.
I'd say there is no silver bullet in this matter.
So I started out supporting approach
number one, but after talking to some
designers I realized that many of them
seem to prefer number two, and its
mostly programmers who prefer one.
This should make obvious sense: if the scripting language is "powerful and full featured", there is an onus on the designers to have to create the systems, since this opportunity is available to them. On the other hand, if the scripting language only exposes small details of the hard-coded game, then the programmers have to create those systems, since designers cannot. I'm not saying each side is lazy, but obviously both have individual skills the project requires them to focus on (since nobody else can do them as effectively), meaning there is always an interest in getting someone else to do a given task if possible.
And following naturally on from this, the proper role will depend on how the human resources in your company are laid out, in conjunction with any performance requirements of your game. Once you have an idea of how many people will need any sort of scripting, you'll know how much of the game will require it, and therefore can decide how how wide or narrow the interface needs to be. This contributes to what the 'domain' of the language would be, as mentioned by onebyone.livejournal.com above.
(For what little it's worth, I'm a professional game developer and also the moderator of the Scripting Languages forum on Gamedev.net.)
The game development community already uses scripting as a very common way of building user interfaces and tuning AI responses. You can find lots of info on sites like Gamasutra. The interesting thing is that standard languages are starting to replace custom interpreters.
Two of the best scripting examples in AAA games that come to mind are World of Warcraft (uses Lua) and EvE Online (uses Python). EvE uses scripting on the server-side too: they have a significant investment in Stackless Python.
Update: Performance will essentially be a non-issue due to multicores. Even low end machines will end up with more cores than the display and model updates need. You might as well spend one of those cores running a scripting solution for the UI.
As has been said before; use scripting for game logic, and C++ for game functionality. An example would be scripting a game mode, but using C++ for rendering.
If we split a game into two parts: The engine and the actual game (design).
A solid top class game engine is most likely written in C/C++ and some people even optimize further with assembler code. You can do a lot of neat really fast stuff for graphics and physics with specific CPU instructions. There is no way to get performance when rendering large landscapes or multiple complex objects from a scripting language only.
When it comes to the game itself where are a lots of aspects that can be done in slower but higher level programming languages. AI and other game logic can be written in script with success. It can speed up development and it opens up for modding and community expansions in a simple way.
I think the poster here is correct to favor method #1. It is a cleaner method and will yield better long term results despite the complaints of designers. In the end the code will determine good game programming from mediocre (bad).