[quote name='Telastyn' timestamp='1311875656' post='4841732']
If you have a script, you can pause your game, edit the script, flush the cache and try it with the new script. No need to re-start your game and recreate whatever scenario you're testing (as would be required in a compiled language).

Visual C#: edit-and-continue (as long as you aren't using lambdas or iterators in the code you want to edit).
[/quote]

Or targeting a 64 bit app. Or creating any types, or deleting locals, or...

Scripting is good for indie developers. Just imagine a Web Browser with hard-coded Pages. Not so fun.

I've never gotten into scripting. My work simply doesn't need it. Instead I go the Sins of A Solar Empire approach, where all my content is stored in txt files that anyone can edit. My program has a parser that can easily read the text files and load the information.[/quote]

Those txt files aka Formatted Data Files are sorta scripts too. The only difference is the conditional logic for parsing and handling them is hard-coded inside the compiled app. Scripting Engines allow you to embed that conditional logic within the txt file. Some may consider this approach more flexible, especially when it comes down to importing different data formats. Script or no Script, you're a winner if its works for you.

(i use java) ... I will admit that I dont use scripting myself so my opinion on it might be horribly skewed in wich case please correct me.

The definition of what is and what isn't a "scripting" language isn't official. There's really no such thing as a "scripting language", it's just a common term for "higher level" (in games, that means "easier to use than C++").

Go back 10 years, and Java was considered to be a "scripting language" for games.
So, your whole game is written in "scripts", and you're gaining the benefits of using a scripting language! Congratulations!

To reiterate -- depending on perspective, you are already using a scripting language.

1. Faster build times is a feature of any language that isn't C or C++. If you were using C, then choosing to use a different language for the more iterative gameplay parts (i.e. a "scripting" language) might be a good idea.
You've already made this choice.

2. This doesn't make sense -- because "scripting" is just an arbitrary category of programming languages, there's no difference between a "script file" and a "code file". All scripts are code. Whenever you're writing classes, you're writing scripts, and whenever you're writing scripts, you're writing code.

3. This is a straw-man. You don't give programming languages to non-programmers. Simply calling a language a "scripting language" doesn't make it any easier for non-programmers.

4. Modellers writing code? WTF?

I do agree with you. I consider the performance language / scripting language pairing to be counterproductive for smaller games. If you would rather write scripts, you should probably look at unity or similar; for smaller stuff it seems a lot more productive to work in a managed language instead.

Again, "scripting language" is just a short-hand way of saying "more productive language".
If you're in an environment where C++ is the norm, then managed languages like C# are "scripting languages".

Calling things scripting languages ends up being meaningless. The core issue is how productive the language will be for the problem at hand.

[quote name='speciesUnknown' timestamp='1311871572' post='4841699']
I use shared_ptr and weak_ptr quite a lot when I'm doing c++ work, but they don't really fill the gap, and there are a whole set of problems mainly around the issue of various things causing cycles, and incompatibility with non shared_ptr using code.

Honestly, reading something like this I always end up thinking that someone has probably screwed up their object lifetimes/interactions somewhere along the line...

Its actually a lot less work to use a managed language and use object pools than it is to work with shared_ptr and the various alternatives.

To this you may reply "but if you do X Y and Z then you wont have any problems" but the point is, having to do X Y and Z in the first place is a problem.
[/quote]

And yes, something like C# might well make it easier and if that works for you then great however as with all things right tool for the right job; sometimes that tool is a scripting language and C++.

And if 'X, Y, Z' = design it right then doing X,Y and Z makes sense regardless of the language ;)
[/quote]

You're right, I have screwed up object lifetimes in the past, and found that shared_ptr was an aid, but not a panacea. The point of a scripting language is that you can have the best of both worlds - for gameplay code, shared_ptr is a nightmare to work with, because of the complexity of interlinked objects.

As for the XYZ idea, the point of that is that I'm often told that various problems with c++ are not problems if you implement a specific workaround, but I consider the time wasted on the workaround to be a problem.

But none of this undermines the fact that I believe scripting language and c++ pair to be the best solution for a larger game, and a single, managed language to be ideal for a smaller game. It only pushes up the threshold of game size beyond which the former is the ideal choice.

Isn't scripting maybe a little overated?

For small games, it probably is slightly overrated. For mid-to-large projects I'd say is as good as it sounds.

1: If you dont use scripting you have to recompile your whole project if you make a change to you code.

I dont know what IDE these people use but when i make a changes to my code only the classes that has changes in them gets recompiled. After i click compile i get a new JAR (i use java) thats ready to be uploaded to my website 1 second later.

A simple partial recompile can easily take 10 mins here. Recompiling all the scripts take about 15 seconds, including file copy. I'm fairly sure most of the time is spent on loading the executable.

2: To make a change to a game entity you just edit its script. To add a new entity you just create a new script.
To make a change to a game entity i just edit a class. To add a new entity i just create a new class. Whats the difference?

The difference is that a class, by itself, is good for nothing. To do something, classes must be connected to external code to make them work. Because scripting works on a higher level, this might not be necessary, sometimes it is just possible to have a new class be used by just creating an object. The component model makes this very apparent.

3: People that are not skilled in programming can create game logic.

Not for me. But if I look at stuff like Unreal Kismet, I see this is a front-end for script and although I never got on this "just connect the dots" approach, I see this works.

4: Your modders can do lots of cool stuff!

Even if you work alone, there's advantage in insulating code from gameplay. Especially if the gameplay code uses a lot of references to objects which are level-dependant... you really stand little choice, the level is data driven, the logic associated has to be as well.

[size="1"]<rant>
So, a couple of months ago, I got in contact with a couple of dudes who seemed genuinely interested in taking a project to gold. In the past, I've promised to myself I would have just ignore those cases, but those guys were fairly good at producing the design, the artwork and appeared focused. After a month however I they went AWOL. At the end of the second month, it was clear they would never come back. No problem, as no gameplay code found his way in the system... of course wasting two months like that is a problem...
</rant>