When to use scripting engines

[Serethos]

im wondering, when the point is reached that you decide to manage your little game sequences/ events by a scripting engine.

for example a platform game like mario, there can be a sequence where a boss gets introduced or a dialogue is shown, whatever.
these are pretty short and rare parts of such a game, but very bad to realize without real scripting.
a common workaround is to have a simple statemachine which permanently decides if the sequence XY is reached and counts internally, when it has to end and change the state to normal gameplay.

i hate those workarounds, cause events, which occur perhaps only one time are branded in the game code (and are permanently tested, if they shall be executed)

im interested in some experiences, when to use real scripting or if there is a better workaround.

[blahblahblahh]

XP programmers would probably say "as soon as it gets so unwieldy that you need to".

Personally, I've seen far too many cases where the longer you leave it the harder it is to re-factor and introduce the new subsystem, so I say "from the very start of the project".

If you're writing tetris, or your first space-invaders clone, YAGNI (you aint gonna need it) so don't bother.

If you are writing any original game and/or know pretty well what you are doing, scripting is essential. Like having a facility for recording key presses. Or for changing key bindings - it's something you *know* you're going to need, so just put it in from the start!

My 2 cents...

[kevglass]

At the risk of being "the eternal hobbiest":

There are always loads of things you know you're going to need... but they're just not interesting. If you spend your time writing them at the start of the project you're going to lose interest (or it might just be me )

Better to write lots of little silly games, each time writing a bit that you know you're going to need somewhere along the line. As long as you spend the time getting it right that time you end up with a whole set of these things as a given at the start of your project.

Kev

Games published by our own members! Check 'em out!

[Serethos]

huh, im wondering a bit why you need a scripting engine for key bindings ?!
you do not mean a binding like 'r' for reloading you mean complex key scripting like in counter strike (select weapon, buy weapon, make monkey dance) ?!

[Serethos]

@kevglass

yeah, thats a fact, indeed.
but after two years of studying and 'dont have time for touching my own code' ive decided to put some work into my very first java-project, an arkanoid clone (yes, one of those silly little games  )

araknoid is pretty straight forward, like tetris, but if youre a little ambitious you want to have this feature and that thing...

now if you introduce a boss enemy who does some monkey dancing, or all blocks are flying down like in tetris (though this is not planned to be a permanent feature of a block), whatever.
it is pretty annoying to implement these events as hardcoded lines. and if you follow this thought up to many of those little events (one eyecandy for each level e.g.) you end up having a consuming and big state machine.

thats what im afraid of


btw: do you use own engines or any open source thing ?

[oNyx]

It makes sense to use some kind of scripting if you need high turn over rates. Well, generally it's always feasible, but there are times where you really want to test different things 50 times a day (every day... for several weeks). Then you need scripting.

Do the changes, press a button, take a look, repeat. And the nice thing is that you don't have to restart the application

[blahblahblahh]

huh, im wondering a bit why you need a scripting engine for key bindings ?!
you do not mean a binding like 'r' for reloading you mean complex key scripting like in counter strike (select weapon, buy weapon, make monkey dance) ?!

That's a very good use for scripting but I only meant to give "changeable (soft-coded) key bindings" as an example of a *similar* thing you know you're going to need.

Many games know they will never *need* scriptable keys, but many games know they *will* need user-configurable keys. If your game only has one button you're probably OK. If it has more than 4 you probably should, more than 6 definitely should.

alhough user-configurable keys is a bit contentious (not everyone belives you need it) so not the best example (not as important as scripting in many cases!). That's partly because lots of people have never tried playing games on a spanish laptop (lots of non-letter keys are in VERY funny places), for instance .

[blahblahblahh]

The problem I'm referring to is that you wait to convert to scripting, and now you have to *re-write* all your hard-code as scripts AND you need to *re-debug* it.

That's the biggest pain .

And, of course, you wasted a lot of time writing the code originally - it would have been faster to write it as scripts.

[CaptainJester]

now if you introduce a boss enemy who does some monkey dancing, or all blocks are flying down like in tetris (though this is not planned to be a permanent feature of a block), whatever.
it is pretty annoying to implement these events as hardcoded lines. and if you follow this thought up to many of those little events (one eyecandy for each level e.g.) you end up having a consuming and big state machine.

I had a similar problem.  What I did was specify a class name in the level config that would do the "special" work that I needed for a level.  I then used class reflection to load the class to do that work.  I just made sure that all my special cases implemented the same interface.  This allows you to have as many special cases as you want.  While reflection might be slow, you just need to use it between levels, so it should not affect game performance.

[princec]

What is it about scripts that could be done to Java to make Java into a better language to program with?

Perhaps if:

- Exceptions no longer needed to be declared (remove the pointless "throws" clause)
- Casts were implicit where needed (if I assign something to a String variable then the code should assume I want it cast to String)
- Types could be dynamically overridden at runtime (so I could do Alien a = spawnSomeAlien() { void kill() {} }; and it would create an anonymous delegate class that wrapped the returned instance and overrode the methods I wanted)
- It wouldn't half be helpful if there was an asList() method defined for all array types that returned an ArrayList
- I'd ban the use of public/private/protected too seeing as they totally fail to solve any problems in Java

Cas

Games published by our own members! Check 'em out!

[abies]

What is it about scripts that could be done to Java to make Java into a better language to program with?

Certainly switch on non-integer types (class types, strings, maybe float and integer ranges).

Anyway, IMHO two things are really important for scripting language to be used in game - functions/closures (not tied to objects, just pieces of code which can be passed around) and totally loose typing (which is a kind of prerequisite for useful closures). But this is not going to happen in java, I suppose.

[princec]

It strikes me that a few tweaks to Javac (or Jikes maybe?) should do the trick. Most errors that Javac throws up can actually be ignored and synthesised away by the compiler - and I can't really figure out why they didn't make it like this in the first place.

I mean, what is the point in complaining about

String s = map.get(key);

when it is totally obvious that you need to insert a cast to String there? Why couldn't the compiler have just implied this for us?

Cas

[abies]

I mean, what is the point in complaining about

String s = map.get(key);

Java is quite strongly type language - all casts are supposed to be explicit, to warn about possibility of cast error. map.get is obvious, but in case of

String s = randomMethod();

if you will get a class cast exception, it will require a bit of thinking why it could have happened at that line.

Of course, this line of reasoning is not longer valid with auto boxing/unboxing - it does exactly what you want, just for primitive types/wrappers.

Some time ago I have seen a proposal for introducing extra operator exactly for operation you want. At cost of one extra character, you would note that you intent to automatically cast object to whatever type is needed

String s := map.get(key);

(of course, := is just an example).

Unfortunately, such solution leaves other half of the problem
((MyClass)map.get(key)).method();

And here, script languages rule the field
map[key].method();
not to mention map.values().forEach({ it.method() }); and groovy GPath expressions...

[blahblahblahh]

What is it about scripts that could be done to Java to make Java into a better language to program with?

Perhaps if:

None of the above.

Looking over all the beanshell scripts I have, in 90% or more of them the main difference is ... no enforced OOP!

A typical script often starts out one to 5 lines long - INCLUDING everything (in java, that's not enough to have a package, a class, and a constructor - even with 0 code in them).

And the fact that everything is interpreted, so I can change text, ctrl-s (save) and alt-tab back to the game and the changes appear INSTANTLY without having to reload.

So...for me, scripting is mainly used for a sort of "ultra" RAD, i.e. very rapid turnaround of source changes. Even eclipse's incremental compile sucks compared to the speed of two keybd shortcuts to update the source ...