But in addition to that, are there any advices you have for rapid prototyping when developing a game (particularly when the primary language is C, C++, or any other non-dynamic language)? Any advices on clean/beautiful ways to integrate scripting languages (it's one thing to integrate a scripting language; it's another thing to do it well). Because I'd love to hear them.

How can I save state after making changes?[/quote]
Depends on what your game state is. As an example, if you were using Lua [to script] you could follow in Fable 3's footsteps and leverage Pluto (http://lua-users.org/wiki/PlutoLibrary) to, essentially, save your entire Lua "universe" to a flat file and be able to reload it on boot. There was an entire article written [by Fable's devs] on the subject but I cannot seem to find it amongst my bookmarks currently; I apologize.

The only thing I've really come up with is making every object serializable, and then saving the game as a whole in a file (kind of like saving a game like you normally would, but more verbose so things like menus and stuff can be reloaded if you're working on the menus, for example). Is that overkill?[/quote]
No, that's the basic gist of what most "high level" language serialization libraries support; it's basic, works reasonably well for minimal effort, and is generally performant for small/medium loads. Just be careful and plan how you want to handle versioning.

Secondly, divide-and-conquer is an excellent strategy in situations like this. Per your example, why not save the "menu" (e.g. GUI) state in a separate file and ram the objects in another? This will be the case anyway if you use a dedicated GUI library (that likely comes with it's own designer + custom formats).

one reason I haven't gotten around to doing so yet is because I love my Visual Studio C++ debugger, and mixing C++ with a scripting language just doesn't sound fun to debug; but I'm going to get over that, don't worry)[/quote]
Most of the popular languages have their own debuggers (and their own debug/error callbacks and symbols) you can use. It's true that debugging both can be somewhat aggravating, but the time (and convenience) you save from using a scripting language tends to be worth it. I was under the impression that Lua had a VS debugger plugin, but I don't know if that's still the case.

But in addition to that, are there any advices you have for rapid prototyping when developing a game (particularly when the primary language is C, C++, or any other non-dynamic language)? Any advices on clean/beautiful ways to integrate scripting languages (it's one thing to integrate a scripting language; it's another thing to do it well). Because I'd love to hear them.[/quote]
As is mentioned in the link Teutonicus posted but I'd like to reiterate: network consoles are a beautiful, beautiful thing [when done right]. Since (obviously) the relationship between your game and your console is of the server/client persuasion, your console never needs to be "shut down" and can function as a mini-IDE if you need it to (save snippets, inject scripts, etc).

However, the biggest boon by far - and what I would say is one of the keys to prototyping (and is even mentioned by Hodge in his post, albeit indirectly) - is that you don't have to write [the console] in C++. C++ is nice a language for some things, but for a lot of others (e.g. GUIs) it's just a tremendous pain. With the advent of .Net and the JVM, scripting languages are now first-class citizens in their ability to seamlessly integrate with their "hosts" (C# and Java, respectively) and their associated libraries - use them.

As for "beautiful integration" between C++ and scripting languages ... most people's idea of that consists of using C++ as little as strictly necessary. If you're looking to boost your productivity for prototyping, porting (or "binding") your personal libraries to your language of choice can be immensely helpful (typically as a DLL extension). Just be aware that a lot of the binding libraries (such as Luabind and Boost::Python) work very well but you'll never get the kind of first-class experience you'll find elsewhere (there's no drop-in and "oh hey my language magically understands C++"). I don't say that to deter you, but it's just a fact that you need more time (than, say, in C# or Java) to see returns on your scripting investment. If you're looking for a "quick fix" to your scripting needs odds are you'll be very disappointed.

That said, if you're willing to put in the effort scripting can be very rewarding.

TLDR: Moar scripting, less C++. Also, no handwritten XML - your time is valuable, don't waste it closing tags.