Scripting Interface to Engine, easy to replace?

#1 Keep in mind that I have no clue what ESD means. So this might not apply.

Why would you want to replace it? Size? I dont think the code takes up THAT much room. And I think the size of script files is comparable to text files, and if you are using the Tribes II engine, the memory and space taken by text files should not be a problem.

Also, why reivent the wheel? The scripting system in tribes isnt too bad, in fact, it will be next to impossible to make it significantly better without allot of work on your part. Why not save the time, adpat, and move onto bigger and better things?

The script system IS the game. Look at some of the scripts for Tribes II. They deal with almost everything related to the game other than graphics and very low level stuff.

So I suppose you could take out the scirpt sequence, because only the demo stuff should really be reliant on it. But it could be pretty hard, and it is really unecessary. I say think about it again and just try to find a way around it.

#2 Oh yeah, one more thing.

How do I start my own threads? It must be obvious, but I cant figure it out... :(

#3 A larger concern in my mind would be how easy it would be to make a game unmodifiable. Yes, mods are the bread and butter of most online games these days, but the first three titles my team has planned are offline and single-player only. We don't want them modded or mapped for, accept for maybe expansions that we ourselves release.

Also, the scripts the V12 and Tribes2 uses are compiled at first run. The compiled scripts can be distibuted instead of the uncompiled scripts and they end up being a bit smaller still the the script text files (or so i've noticed on average).

#4 It's really quite simple, there are more powerful and elegant solutions to scripting available. Additionally there is the question of end-user modification. Anyone that doesn't want end users releasing "mods" to their game will probably want to lose, or in some way alter the accessability of the scripting system.

In this Market there are going to be several requirements for success. Size of Download, Quality of Game are two of the biggies. But if you are going with an episodic model in order to keep size down and increase revenues, why would a large majority buy additional episodes when they can just wait for free community made mods?

If you sell a core game for $20, and "mission packs" for $10 that have roughly the same overall amount of content as the core game, you reduce the size of mission packs to make them more attractive. You then have a good chance of selling the core plus three mission packs (Hey, for $50 you get the equivalent of a full game). The consumer is happy, because if the game sucks, they're only "out" a small amount of money, if it's great they have more expansions they can buy and play, and there's no reason to stop at three mission packs.

That is *one* reason I've considered ripping out the scripting system.

The other is it's just as easy for me to integrate something more powerful (such as python for example) directly with the engine. During development python is just as small (same text files), sufficiently fast, and allows for fast prototyping.

There was another reason, but I'm a bit short on caffiene this morning, so I'll eave it at that for now.

#5 Regardless of what sort of system you used, none would be more powerful than the other. Why? Because each would be entirely dependant on what you had recoded the engine to allow it to do. So the end result is that it will be far less time consuming to make a game unmodifiable, yet still expandable, without yanking and replacing the current scripting system. Just remove support for the mod command line, insert a simple script checking system and only distribute compiled scripts with your game (very easy, but I've been kind-of hoping for an even easier way. The less work I have to do on the engine itself, the more work I can put in on getting a game made).

If you're bent on ripping it out and replacing it, go for it! But you'll probably have allot of work ahead of you. After all, entire games can be made completely through scripting, so the script engine is probably very tightly integrated with the rest of the engine's code. IMHO it just seems like a waste of time that could be better spent.

Honestly, it sounds to me more like you're trying to replace the current scripting system with one that uses a language you're already familiar with (although I may be wrong there). If you know enough C\C++ to think about tackling replacing the scripting system, then it will more than likly take you less time to learn V12 scripting than it would to replace it.

Not soapboxing or flaming here. Just trying to figure out a solid "why".

#6 Well, I'm assuming, and I probably shouldn't, that the scripting system has features and fuctions designed (albeit generically) toward Tribes 2-like games.

We're not making a Tribes-2 like game, except in that it would be mostly 1st person and mostly 3D. In fact if the rendering/world systems are modular enough that the rest of the code could be scrapped (we won't need WON or whatever, no chat rooms, no community, email, webpage, etc "junk" as one of the guys calls it) that will reduce the size that much more.

Size is probably the #1 factor. Art assets take up alot of space, but until we've got the game close to beta, we won't know what to trim there. When V12 lands, we *will* be able to immediatly decide what to trim from that code, at least after a good going over. Before we even get the code, the scripting system looks to me like something that can be easily "lost" without any detriment to our project goals.

Any scripting we do will only be placeholder code until the functionality is there, and it gets replaced by C++ (I guess you could argue go straight to C++, but I can prototype logic & AI faster with python). It will be faster for me to embed python and then convert to C++ than to learn V12script (or whatever name it gets) and convert to C++.

Well, at least that's my thoughts, based on alot of assumptions I admit, but until I have the source in my hands I don't really have alot of other information to build on besides the heresay in these forums. Perhaps V12script is easier to learn/use than I think it will be, maybe it will be easy to convert to C++ code. Maybe, time will tell.

#7 I have considered this option as well. Admittedly, it's quite likely to be a formidable challenge. I could live with Tribes 2 script, but it would be nice to have a standard language such as Python for the scripting section. At first glance, it seems that given the progress of C++/Python libraries like Boost.Python and SWIG that it should be a matter of simply replacing a wrapper about the same functions that the present scripting system calls. My guess, though, is that it's not that simple and that the current scripting system already has a great deal of tuning and advantages that shouldn't be ignored.

Wait and see, really.

#8 Perhaps instead of speculating what the scripting language is, you guys might want to take a look at it?

I did quite a lot of T2 scripting, as well as some for tribes 1. The scripting engine has nothing to do with Tribes like games, it is a very flexible C++ like language. I have not used or seen Python, but I am willing to bet that ripping T2Script out and replacing it with Python would negate any possible savings you might get from using Python instead.

Why would you want to move all your logic into C++? The whole point of having a scripting engine is that you can tweak and recompile on the fly, which saves you a massive amount of time. As long as you keep speed-critical functionality in C++, the performance hit is minimal. I think I saw somewhere that one of the T2 programmers said that profiling showed less than 2% of their time was spent in script, though I could be misremembering. :-)

Josh

#9 or you can just use makefiles and the speed of recompiling is even

#10 When you release a game, the script file sizes, compressed, are of minimal impact to the overall size as compared to the art assets. Don't even bother worrying about the tradeoff.

As for not letting your app be modified, why put any thought and effort toward that? Especially if it's only single player, what benefit do you gain? in multiplayer, there are issues with cheating and such, but even those aren't an issue in most cases if the server code manages the system well.

I'll let the GG guys jump in at some point to discuss whether you can PAK/ZIP the content up to be less accessible, or whether you can distribute without source scripts just precompiled stuff. I believe both should be possible, but not sure.

d

#11 I think it would be a waste of time. My team is making a medieval RPG. It has nothing to do with tribes. You can do ANYTHING with the v12 engine. You could make space sims (easily, probably the easiest thing you could do), hunting games, racing games, hell, even some weird 3d chess game. The possibilities are endless. The scripting language will let you do anything (You can do anything at Zombo Com).

If you're worried about someone getting access to the scripts you can just list them and write a quick function that makes sure the only files being executed are files that you allow. Get rid of the console, and make run everything that goes to the exec command through a filter to make sure a third party file isn't being loaded.

You could also check the file size.

As stated before, the files are compiled into .dso's, they would be hard to decompile, but if your still worried you could zip them.

T2 (and I presume the v12 engine) supports .vl2 files which are just .zip's. I don't think they have password protection, but it shouldn't be too hard to add. You could even change the compression techniques.

In summary, there are a lot of different ways to protect your game. I know I am. Not so much because of modders, but because of cheaters.

Oh, and David, both are possible. You can only distribute the compiled scripts if you want, and zip them too, like I said above.

#12 If I have read correctly, the script engine is what actually "makes" the game. All gameplay mechanics are done with scripts. This is the same as many games such as Quake 3. If you were to rip out the scripting from the rest of the V12 engine, you would be taking all of the code that actually allows you to create a game.
Could a GG employee come and clarify all of this?

#13 The scripting engine in the V12 is the "glue" that holds the game together... individual classes/objects are defined in the C++ engine and game code (like Terrain, Interior, TSShape, GuiButton, Projectile), but the scripting language handles all the logic for how those objects interact.

For example, in an action game you might have the Item class (defined in C++) which has methods for drawing, movement and transmission over the network - but when a player object hits an item object it makes a script callback like:

Con::executef(this, "onCollision", Con::getIntVariable(itemObjectId));

which executes the following in script:

function Player::onCollision(%this, %item)
{
if(%item.type == ChaingunAmmo)
{
%this.chaingunAmmo += 100;
%item.delete();
}
}

Script files are compiled into .dso object files, which for a single-player game can be distributed alone - so noone can modify your game or see your script source code.