Built-in Scripting

[Pathetique]

I was told to read the "vValue And DCT" discussion before posting, but I got half-way down the first page and decided that reading the rest of the intellectual sparring just wasn't possible with my attention span running out on the idea as a whole.

So, here's what I'm proposing.

We don't create anything too complicated. We create something using a very easy syntax to create scripted gameplay. It would be called TronML, or TML for short, be loosely based on PHP/other languages, and would look something like this:

Code: Select all

FUNCTIONS {
	caseR() {
		CASE $R {
			1 {$fort_Coord = 0,-150 };
			2 {$fort_Coord = 0,150 };
			3 {$fort_Coord = -150,0 };
			4 {$fort_Coord = 150,0 };
		};
	};
	
	spawnZone($name) {
		$R = 1;
		$X = 1;
		WHILE $R <= 4 {
			caseR();
			WHILE $X <= 4 {
				SPAWN_ZONE n $name fortress $name $fort_Coord 50 0;
				$X = $X + 1;
			};
 		$R = $R + 1;
		};
	};
	
	moveZone($name) {
		$X = 1;
		WHILE $X <= NUM_HUMANS {
			MOVE_ZONE $name TO 0,0 OVER 10;
			$X = $X + 1;
		};
	};
};
// GAME PLAY:

	ON GAME_TIME 0 {
		spawnZone($player);
	};
	
	ON GAME_TIME 3 {
		moveZone($player);
	};

This is a basic description of the Moving Zones map for Flower Power Sumo Assault.

Functions are useable here, and perhaps someone can suggest a better way of making it so the game doesn't automatically run them when it goes to run the config file.

MOVE_ZONE has a few differences from SET_ZONE_POSITION. The usage for it is MOVE_ZONE name TO coord OVER time. In place of OVER you could use AT and define a speed with which the zone would move.

Its pretty self-explanatory after that.

Thoughts?

[epsy]

If someone directed you to vValue, it's probably because how it just .. went wrong. A massive amount of stuff nobody knows the purpose of(or at least not me).

We're not going to build up our own scripting language, we're slow enough already.

At last, take a peek at the trunk-modules branch

[Z-Man]

And if someone pointed you to DCT, it probably was luke To the best of my knowledge, he's the only one knowing what it's supposed to be beyond the 'it's a tree full of config stuff' level.

[Luke-Jr]

Yeah, the main point of vValue+DCT was basically a scripting language. But as epsy reminds us, we don't have the resources for our own scripting language.

[andi75]

If you're looking for built-in scripting, I can recommend Lua. Even Blizzard figured out that it's cool

Seriously: It's easy to integrate, lightweight, and very much human readable, i.e. nice for stuff like config files.

[Z-Man]

While that's true for C and there's no doubt Lua is a good language on its own, proper interaction between Lua and C++ is a little more difficult. We've been there in a couple of older threads already.

[andi75]

Heh, I just read the 'tValue/Lua/Io (was: tValue or Lua?)' thread and it scared the hell out of me (also, I gave up after 4 pages). I guess my first impression that you "just needed scripting for a few config files and maybe a few 'variables that are allowed to do special things' if they are changed" are utterly wrong

As for interfacing with C++, yes, passing more sophisticated data types around than a plain string or int or double can be a pain, and probably should be handled through serialization.

What you want as a scripting language really depends on what you want to do with it. Just remember that 'Interfaces nicely with C++' is about as fuzzy a requirement as you can get. How exactly do you want it to interface with C++?

[Z-Man]

Heh, I just read the 'tValue/Lua/Io (was: tValue or Lua?)' thread and it scared the hell out of me (also, I gave up after 4 pages). I guess my first impression that you "just needed scripting for a few config files and maybe a few 'variables that are allowed to do special things' if they are changed" are utterly wrong

Yeah The config stuff would just be a side effect. The main goal of scripting integration for us would be to allow more flexible serverside game rules. Probably not on the physics level, but one level up. What happens if a cycle collides with a wall? How do zones interact with cycles? What is the round/match/game structure? Also, scripts need to be downloadable to the client for better extrapolation of non-standard physics. Say you want permanently invulnerable cycles that don't blink; the plain game doesn't support that, so you either have to disable the blinking or disable stopping at walls in the extrapolation via a script. The challenge there is to make all this secure; we don't want servers where you join and get your hard drive deleted.

What you want as a scripting language really depends on what you want to do with it. Just remember that 'Interfaces nicely with C++' is about as fuzzy a requirement as you can get. How exactly do you want it to interface with C++?

Ideally, the mapping should be one on one. C++

Code: Select all

class X
{
public:
    int f( std::string in );
};

Should be usable in script like that (assuming a C++ like syntax, replace = with := and remove semicolons as appropriate):

Code: Select all

x = X(); // construct new X object
result = x.f( "hello" ); // call C++ member function

And, most importantly, you need to be able to create subclasses of C++ classes in script and override virtual functions in the script so they are callable from C++.

And yeah, we looked at boost::python and its equivalent for Lua (can't remember the name) and of course SWIG.

[andi75]

I see. Personally, I wouldn't let a scripting language get even near my C++ structures. If you want to go all out, your best bet with Lua is SWIG though.

However, I'd provide an API that the Lua code can use and that's it. Expose the entire game world through that API, run the game logic completely in Lua, and just have the renderer in C++. If there's any functionality in your game logic that is performance intensive, write an optimized version in C++ and move it into the API (the client will have to live with the interpreted version though if it's contained in a downloadable code fragment).

[Z-Man]

I see. Personally, I wouldn't let a scripting language get even near my C++ structures. If you want to go all out, your best bet with Lua is SWIG though.

Problem there is that for Lua, SWIG does not support the 'override virtual functions in script' stuff. Which is really essential, lots of C++ code works on the basis that you derive from a class and override virtuals to change behavior aspects. Only for Ruby, Python, Java and C#, I think.

However, I'd provide an API that the Lua code can use and that's it. Expose the entire game world through that API, run the game logic completely in Lua, and just have the renderer in C++. If there's any functionality in your game logic that is performance intensive, write an optimized version in C++ and move it into the API (the client will have to live with the interpreted version though if it's contained in a downloadable code fragment).

[/quote][/quote]That's probably not feasible. There are cuts where one could make the game logic vs. rest division, the amount of C++ game code we'd need to port over to Lua or whatever we pick is gigantic. And we'd need to do at least a large portion of it before the game even runs again. So it's a large chunk of work with unknown benefit on the far end of it, something that just doesn't work if you have unpredictable chunks of free time to devote to it. The lean and mean interface approach works if you do it right from the start of a project, but not as an afterthought. A complete rewrite would be easier. All IMHO, of course.