Is'nt scripting maybe a little overated?

I might understand why bigger studios would want to do all game logic in scripts but what justification is there for indie programmers? I feel that is just adds unnecessary overhead. Im going to list the reasons i usualy see here on the forum and provide my own reason why i think its invalid.

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.

You are right, as long as everyone that might make changes to the game has the whole development environment.

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?[/quote]
Same as the previous one.

3: People that are not skilled in programming can create game logic.
Most indie developers program alone. And if you team up with someone wouldnt you rather team up with someone that knows how to program?[/quote]
If you don't want collaboration from people that are not skilled programmers, this reason doesn't apply to you.

4: Your moddelers can do lots of cool stuff!
I dont want my moddelers to do lots of cool stuff. I want them to make models.[/quote]
Modders, not "moddelers".

In general, scripting allows modification of certain things in the game without having the whole development environment, and this adds a flexibility that some people want. If you don't want it, you don't need scripting.

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. So far, the additional work I've had to do in c# to get around the garbage collector has been far less than the work required in c++ to embed a scripting language and get around the lack of a garbage collector.

So far, the additional work I've had to do in c# to get around the garbage collector has been far less than the work required in c++ to embed a scripting language and get around the lack of a garbage collector.

This is getting quickly off topic but, why do you think C++ needs a garbage collector? You are probably doing it wrong. Standard containers deal with the memory they use and clean up after themselves nicely. When you do need to allocate something yourself (e.g., in a factory function), wrap the pointer in a shared_ptr and you probably won't have problems. There are many things I don't like about C++, but this is not one of them. I haven't had a memory leak in many years.

Over rated? certainly not.

Over used? maybe.

On the 'create entities/components' thing; it wouldn't just be a case 'create a new class', you'd have to create it, register it, expose it and allow for it to interact in some manner. Most of this work would have to be done by hand, much of it every time you create a new entity/component to be used. If however your entities/components can be expressed by script then it's a simple matter of creating a script and having a system in place to load those scripts and run a register function to expose it. You'd write the initial load/register functionality once and you are done for all future iterations.

On 'script quality'; if your scripting system allows you to write scripts in such a way as to cause problems then I would argue you've exposed things wrong. Either on the wrong level or just incorrectly for the usage pattern. The designers here write Lua scripts for controlling levels, most of them aren't programmers yet they produce good scripting because of the way things are exposed. If you team up with someone to make level content who isn't a programmer this becomes important, but even as a programmer the abstraction given by scripting systems makes life easier as you don't have to worry as much about the same things as you would in say C++. In Lua if I want to store an object reference, a string, a number and a function in the same table I can, if I want to do that in C++ I'd have to start messing with variant types and all manner of fun conversions for things to work.

Also, if you 'hard code or script' the logic might stay the same but the expression changes.

For example if you are moving a character from point A to B in your hard coded version you are going to end up more than likely polling the location in the game logic directly. However with the correctly exposed scripting you can wrap that functionality away so it resolves down to a simple script which might say;


MoveEntity(foo, location)
WaitUntilEntityAtLocation(foo, location)
// rest of script


It becomes a lot more expressive basically.

Add in things like co-routines which allow you simply yield and resume 'threads', the inbuilt support for events and sleeping execution of co-routines until events happen in some languages and things become simply more expressive.

Alternatively, reacting to events is another area where scripts are useful. Rather than hard coding the information into the code you can expose it in a script. This would allow two objects which are unrelated for most things to share the same behaviour without having to tie them into inhertancy trees for no good reason. The inverse is also true; lets say you had a 'door' entity; some doors make sound when opened, some require a key, some might be latched on pressure pads which you need to stand on in order.

Now, you could make a door entity and then make a 'lockable' sub-class, maybe a 'silent' sub-class, but what happens when you need a lockable AND silent object? what about the pressure pads? If instead you could assign scripts to instances you could get around this problem by having a single 'door' class whch does what a door does and then allowing scripting to customise the behaviour.

Level logic is much the same thing; you have a level in the game where the user has to pull 5 levers in 1min, this then stops monsters spawning an opens a door. With the correct scripting interface this is trivial to do, with the hard coded method you end up having to find ways to link this form of logic together and then deal with having to expand it ("hey, maybe I want two groups of 5 levers, both of which turn off a certain group of monsters, and you have 1min to turn off the first 5 but only 43 seconds for the next 5...").

Now, not everyone needs or wants this, which is fine, it's not like anyone is holding a gun to your head saying 'DO SCRIPTING!!!!' but to say it is over rated isn't true, it really depends on what you want.

And yes, some people will use it for the 'wrong' reasons becuase they have heard that 'scripting is cool!!!!!¬!"211`11' without thinking about WHY they want to do scripting. But then this is true of all areas of software development and all tools open to use.

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.



If I want my campain to have an extra level, I just add a new text file to the game that defines the new level. Same for a new race, new ship, new special ability.



I really like this approach as it doesn't require my developers to learn a coding languege. They can just look at the text files and know very quickly what needs to be edited. Also I don't have the overhead of running an interpreter. Though it isn't as flexable as a full scripting languege.



Personaly, I am not an artist. I am a coder. I write code, not art. Thus I belive that the art and code should be seperate, as they do differnt things. This goes for the content files as well as for audio and visual.

Scripting, be it by .txt or by .py allows me to seperate the art and the code. I don't even want to work on the development side, I'd be happy if I just stuck to the game engine. I have developers who can do they artsy stuff. And I DON'T want them bugging me every five minutes to add a silly little new feature (that could be easily added with scripting) when I'm right in the middle of trying to get my OpenGL engine to optimize mipmapping (or some other complex task).


Just my two cents.

[quote name='speciesUnknown' timestamp='1311864166' post='4841612']
So far, the additional work I've had to do in c# to get around the garbage collector has been far less than the work required in c++ to embed a scripting language and get around the lack of a garbage collector.

This is getting quickly off topic but, why do you think C++ needs a garbage collector? You are probably doing it wrong. Standard containers deal with the memory they use and clean up after themselves nicely. When you do need to allocate something yourself (e.g., in a factory function), wrap the pointer in a shared_ptr and you probably won't have problems. There are many things I don't like about C++, but this is not one of them. I haven't had a memory leak in many years.
[/quote]

Those are some of the things I'm referring to when I say "get around the lack of a garbage collector". I don't think that c++ needs a garbage collector, because I think that it operates in a niche where a nondeterministic GC is undesirable, and a deterministic one would be horrible to use. 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. 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.


But, back to the original point. I think that as games approach a certain level of complexity a c++ / scripting language split is unnecessary, but past that, its probably a very good idea, especially when larger teams of people are working on the game. For smaller stuff, I still recommend a managed language with some object-pooling shenanigans in high performance areas.

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.

Even with partial compilation, C++ blows. Until recently (and moreso in big houses) the majority of big games are done in C++. Further, you're ignoring the debugging aspect. 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).

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?
[/quote]

Scripting languages tend to be more focused to your problem domain, thus nicer to work with. Again, if you're a big company stuck using C++, this is a bigger deal.

3: People that are not skilled in programming can create game logic.
Most indie developers program alone. And if you team up with someone wouldnt you rather team up with someone that knows how to program? Even if i used scripts in my games I would stil rather have an experienced programmer create those scripts since theyl be able to produce better scripts than a non programmer. Whether you hardcode stuff or script it the logic stays the same. The santyx might be less verbose but thats it. The only real reason IMO to use scripting for your indie project i see here is if you create a game that has a heavy focus on user content.
[/quote]

Finding help is hard. Finding good help is damned hard. Getting stuff done requires compromises.


In general, scripting is probably over-rated. Personal projects using sane languages can likely make due without. But it's one of those things where developers in general err on the side of overuse because under-use is far worse.

If you're writing Angry Birds 4 by yourself in your garage, yeah, scripting is probably wasteful overhead.

But if you're working on anything large, it's basically a no-brainer that you want to be scripting as much as possible.

Funnily enough Angry Birds itself uses Lua a well known scripting language. This isn't the 1980s where "scripting" is some black magic voodoo sauce, you can download Python or Lua and plug and play in a day. This gives you access to fully mature robust scripting engines with built in GC, multi-paradigme programming, dynamic language. The biggest issue with scripting languages is creating the native bindings from and to scripts. Luckily some smart people have been working on that problem and you have a wide selection of support libraries for bindings.

From my experience, I've come to the conclusion that even the smallest game can benefit from a scripting layer (once you build one, you can reuse it for every project there after). Scripts are sufficiently robust and fast that almost all the logic can be done within them, but more so it comes down to speed of iteration. A good script framework with proper bindings to the native code will allow you to iterate much faster than a pure C++ framework. That's been my experience anyways.


[EDIT:

After re-reading the OP, i see that your using Java, yeah Java and C# have that advantage over C++, which will shorten the iteration time. However dynamic languages like Ruby, Lua, Python are IMO easier to program in than C# or C++. Ultimately a scripting framework is just another tool in a programmers tool box, use it appropriately.

]

Good Luck!

-ddn

On the 'create entities/components' thing; it wouldn't just be a case 'create a new class', you'd have to create it, register it, expose it and allow for it to interact in some manner. Most of this work would have to be done by hand, much of it every time you create a new entity/component to be used. If however your entities/components can be expressed by script then it's a simple matter of creating a script and having a system in place to load those scripts and run a register function to expose it. You'd write the initial load/register functionality once and you are done for all future iterations.

C#: Put a custom attribute on your class or implement an interface. A write-once class uses reflection to find and register everything automatically.

In general, scripting allows modification of certain things in the game without having the whole development environment...

Notepad vs. Installing C# Express and XNA isn't that big of a burden, in my opinion. Compared to the typical tools you need for professional games with MASSIVE content pipeline tools, installing Visual Studio is cake.

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).

Scripting languages tend to be more focused to your problem domain, thus nicer to work with.

This I agree with! You're allowed to focus the scripting language on the problem(s) you want solved.

It's generally not easy enough (or possible) to customize a general purpose language to the same extent as writing a scripting language. However, I think that using a general purpose scripting language such as Lua (without customizing it) has absolutely no benefit.

[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...

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 ;)

One expression says it all, and that magic expression is "flexibility".
You probably don't want to do ALL game logic in forms of scripts, like some basic behavior will be hard coded ( like NPCs attacking hostile NPCs and players ), but things that you can't generalize enough you will want as some form of scripts, whether it's an actual script in a scripting language or a row in a database in case of AI agents for example.

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='Nypyren' timestamp='1311885063' post='4841826']
[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...
[/quote]

Well, yes, there are several other limitations. Chances are if you're doing anything too complicated, you'll have to reset your entire game anyway (reload a level, etc) just so you can trust that you're testing your code with a valid state.

[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"]
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...

Techniques that promote faster development time -- it makes sense to rate them highly.
Programming high-level game logic in C++ is cumbersome. The language works better for crafting fast, fine-tuned engines.

"Scripting" makes it more practical to play with details and experimentally find that "just right" gameplay.