Game scripts

[RandomLetters]

I know that all "professional" games offload things like levels and AI into exterior text files, as opposed to hard coding them.

Does anyone know a good introduction or tutorial on how to do this?

Is it worth it for student made games to replace hard coded content with scripts?

[SNIPERDUDE]

If you choose to have exterior files for such things as levels and AI tactics, it really comes down to how you code your game engine. Made well enough, it adds a certain flexibility and power to it. How it is implemented is also up to how you make your engine (what variables you wish to have loaded from files). A good place to start would be trying out file input and output tutorials. Master that and go from there.

[DemonWasp]

To answer your questions in reverse order: no, it generally isn't worth it for student-made games. Hell, even professional games don't always feature scripted (as opposed to hard-coded) content -- often, but not always. I can't know for sure, but I assume that most of Quake 3 is implemented directly in the engine, in C / C++. Quake 3 probably has weapons stats in a file, but the effect that's shown when they fire is built into the game (that is, a shotgun blast effect exists in the game engine, in C[++]; a data file specifies that the "shotgun" weapon fires a shotgun blast effect that does X damage with Y spread, and it reloads every Z seconds...)

I know for a fact that Baldur's Gate had no programmable scripts for 95% of the gameplay; the only scripts were for character AIs, and even then they were extremely basic. Instead, Baldur's gate has a variety of parameterized effects that could be used by spells by specifying the effect-ID and its parameters.


In Java, there are two main ways of scripting behaviour. First, you can use one of the dozens of "scripting" languages that run on the JVM. Some of the better-known ones are BeanShell, Jython, JRuby, and Rhino. These are used to take a String and, at runtime, either interpret or compile the code (Java, Python, Ruby, Javascript respectively) for execution. They can examine Java classes, either directly or indirectly (depending on how they're implemented). Generally, these are faster to code, but much slower to execute.


The second way is to use dynamic class-loading to read in .class files at run-time; the class files themselves can be generated from Java, Scala, or a number of other languages that output as .class. This offers a few advantages, including using Java's existing security mechanism and giving the full execution speed of Java (or Scala, or whatever). I've done a bit of work on this kind of thing; if you want, I can post the code for a security-enabled Java classloader. I haven't done any work with unloading / replacing classes, but that's also technically possible.

[Tony]

There seems to be a variety of items mentioned as examples by the OP, and they each probably merit their own answer.

Level layout, even in student games, is almost always better off when described in data, rather than code. And this works really well, up to a point where the tiles/objects/whatever need to be unique and/or carry some logic.

That logic/code could continue to be pushed back into the game engine... you'll end up with tiles like:
- regular door
- door that opens with key
- door that opens with key and flag1
- door that opens with ...

it could get out of hand pretty fast. This is where scripting comes in. Although in some sense that's just logistics of where the same piece of code lives.

[mirhagk]

Often games simply use XML rather than a scripting langauge. You can relatively easily make a program to load an XML file as a class, so you can describe weapons in XML files rather than hardcoding it all. This is often really nice, as you can alter the XML files without requiring a recompile, although unless done right, it can be a security flaw (if these files were editable by then end user, it'd be trivial to make a pistol launch rockets lol).

However I came up with an idea, probably has been used, where you use data files, which can be loaded from a file, but then core gameplay files can be "compiled" into a source code file, and therefore be hidden and unalterable (well as much as you could hide them lol)

[DemonWasp]

mirhagk: That's pretty much what I was talking about above, save that I didn't specify XML. You can, of course, use any data-serialization format, of which there are dozens that work well with Java. YAML is my favourite for readability, but if you want speed and a degree of data security, use Kryo.

Typically, checking that everything behaves correctly is done by a separate server in multiplayer. If it's just singleplayer though, who cares if someone wants to make a rocket-pistol?

[RandomLetters]

Thanks for all the information everyone.

I think instead of scripting anything, I'll just leave them in separate classes. At least this way, It (hopefully) should be easy to convert them to an external file in the future.

Java is an interpreted language isnt it? So really, it won't be hard for someone to change the code if they really wanted to anyways.

[mirhagk]

Which is why so many minecraft mods exist lol.

[Tony]

RandomLetters @ Tue May 31, 2011 7:20 pm wrote:

Java is an interpreted language isnt it?

In a way that bytecode is interpreted by a JVM. In theory it's about as easy as changing the code of a compiled C binary, if you only cared about a single OS/cpu platform, though in practice I imagine that Java decompiles much better.

[2goto1]

Pretty much every modern Java runtime has a JIT (just in time) compiler built in that converts bytecode to native machine level code.

[DemonWasp]

Java can be decompiled somewhat more readily than programs compiled in C or C++, certainly. However, it's generally not interpreted at runtime; instead it runs in what you could call a "hybrid mode", where most of the code is compiled at runtime, and only small sections are interpreted. This is done because it's a LOT faster.

Minecraft mods are probably enabled more by this than by the ability to decompile Java: http://www.minecraftwiki.net/wiki/Development_Resources

[mirhagk]

Also C# is the same right? Like it's a interpreted language with a JIT compiler?

EDIT: Also to the original poster, the AI scripts that game use are generally where the AI's can do certain things, like in Oblivion they have different lives, so the files merely describe where they go and when, the AI isn't actually coded in scripts. (Like in the scripts it doesn't have a pathfinding algorithm or anything)

[2goto1]

C# is a compiled language that is first compiled into MSIL (Microsoft's version of Java bytecode). MSIL is always compiled to the native machine level code before it runs. This helps to ensure maximum performance. So it's more compiled than interpreted.

ASP.NET flies are a part of Microsoft's web site development technology, they have a .aspx extension. They are human text readable files that typically contain HTML, and ASP.NET server controls (i.e. input form controls, etc.), and even c# code. When an aspx file is first accessed, it's compiled into MSIL, then into native machine level code. There's a small performance hit in doing this on first access. So technically aspx files are compiled, not interpreted, it's just that you as the developer may not always have control of when they get compiled, your website users may determine that (whoever first accesses your aspx page). You can pre-compile websites in order to avoid this performance hit.

The Microsoft .NET platform does have some interpretive and dynamic language features, but for the most part everything tends to get compiled into native machine level code for performance reasons. You can write a C# program that dynamically loads and interprets IronPython scripts, for example: http://blogs.msdn.com/b/charlie/archive/2009/10/25/hosting-ironpython-in-a-c-4-0-program.aspx