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.

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!!!!!¬!"`21`1`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.

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