Preferred Scripting Language

Hello everyone,

i am still alive and still working on this project. And I wanted to give you all the opportunity to influence the project's future direction.

I have two working prototypes now that use different means for scripting and I am still undecided (although biased) on which approach I should pursue.

One thing should be noted: Scripting in the context of this project is far more than the scripting of the previous game. Pretty much any code that isn't related to the graphics or sounds or data files will be written in the scripting language. For instance the code that controls the flow of combat would also be written in the scripting language.

The first prototype (of which some builds float around this forum) uses JavaScript exclusively and converts the legacy Python scripts to JavaScript as well. JavaScript is easy to pick up and performance isn't a problem either. Anyone can edit the script files with a simple text editor. I see two drawbacks with this approach: The language is limiting for more complex things, and the tool support for JavaScript isn't that great (mostly Web centric tools, testing is quite hard).

I have another prototype on my drive that uses C# for implementing the actual game logic, while the graphics / sound engine are still written in C++. C# has a (in my opinion slightly) higher barrier of entry than JavaScript, but is arguably more powerful. Tool support for C# is excellent thanks to Visual Studio Express (which is free). In this prototype IronPython will be used to execute the "legacy" scripts that are imported from the old game. They won't be converted to a different language.

So my question to you is: Would you rather script the game in C# or JavaScript?

Regards,
Storm

ps: It would be possible to write the entire thing in Python too. But I am not sure I want that

 

I don't have a scripting language choice, but wanted to give you the thumbs up for continuing to work on the project! :clap:

 

As I know jack sh*t about scripting languages, I'd say go with the one that's easiest to work with to complete your project and any future additions/corrections/fixes/etc.

 

I guess they don't need to be converted either way. They could be run using some form of "legacy wrapper" in both cases, although it's more work if I go with JavaScript.

Why I ask: I want to make sure that contributing to the project is easy. If the barrier to contribute is low, it might be done faster. And I don't necessarily mean contributions to the graphics engine. Rather things like D&D combat rules, abilities and spells, unless they're done in the old python scripts.

Regards,
Storm

 

I'd be happy to contribute to the best of my ability. I'll probably need some guidance tho.

Only spells are scripted in Python, and partially at that - so we have our work cut out for us
Whether C# or JS is preferable is beyond me - I don't have the experience to weigh the pros and cons. But I do have two things to say:
1. Rapid prototyping is very important to me. I really hate restarting ToEE everytime I change something.
2. D&D has some complex interactions between various modifiers/states (spell effects, feats, racial attributes...). If the limitations of JS turn out to restrict the implementation of that, then that's a big con.

Also, really glad to see that you still keep the flame going.

P.S.
I didn't know C# could be used as a scripting language - how does that work? Does it have to be compiled or does the game compile at runtime or something like that? Is it as powerful as precompiled code?

 

I fail to see how it makes much of a difference, either way. JS, Python, C#? I'd pick whatever can be implemented in the engine with the least hassle. Although if the choices are C# or JS I'd prefer C# from a programmers standpoint. However, maybe JS is easier to pick up for scripters/module makers?

 

Wouldn't C# make the gameplay run faster in general?

 

I strongly advice against changing the script interpreter language - you'd have to re-implement all of the py scripts, introducing new bugs and for what? New mods will have to chose to program to your engine or to the original, old python libraries used will have to be discarded and equivalents found (or god forbid, programmed).

All to change from python (that the modders know and is easy) to something else (that they don't know, and may or may not be easy).

Besides python is forwards compatible in the interpreter in major versions.

Python 2.7.2 still works with bloodlines code after some adjustments (i did a dll replacement).


So... strongly advice against.

As for speed - the only way to increase the speed of a program reliably is to profile. In games, scripts are not normally the bottleneck (except in monstrosities like morrowind modding). Changing the scripting language will almost certainly not give you a generalized boost in speed unless the scripts are total shit - and then that won't help much, will it?

 

Hmm, sounds like C# + IronPython is the best choice then.

I guess I wouldn't mind using C#. I've dabbled with it while messing with the World Builder.

The other modders are pretty much Gaear and Ted (and maybe Ranth?) - Ted will manage I think, and Gaear won't do more than copy-paste anyway

 

Wow, thanks for the replies!

Sadly vBulletin decided to only notify me once for the first reply or I would've replied sooner.

@Agetian:
In case of C#, I would write the "main" program in C#, while the graphics engine would reside in a C++ DLL (C# calls C++ using P/Invoke). The scripts could in theory still be JavaScript, but in this case it would make more sense to just load more C# code from either DLLs or source files to allow for easy scripting. The main program could be run either from MS.NET or Mono.
In case of JavaScript, the main program would be C++ and all scripts would be loaded from JavaScript files using Qt's JavaScript engine (the same as used in Safari/WebKit).

@VentilatorOfDoom:
I am also unsure if JavaScript would be easier to pick up by modders. I guess you'd have to set up an IDE for C#, but you would also gain the benefit of being able to *debug* your scripts directly in the game.

@TheLadiesOgre:
Modern JavaScript engines are quite fast, but yes, C# would still be faster.

@SCO:
Actually the more you move code from the core into the scripts, the more the scripting language matters. I only want to support the vanilla scripts through a legacy wrapper, since the old ToEE API is broken and not open for extensions. And the amount of code in the old vanilla scripts pales to the code required to re-implement all core systems in said scripting language. I wouldn't want to do that in Python.

@Sitra Achara
I guess some of the advantages of using C# are:
- If I document the core classes properly, you'd have a good API reference for scripting. This is slightly harder to do for JavaScript scripting.
- You'd have a fully-featured IDE (Visual C# 2010 Express) to write scripts in (while this is also a disadvantage, since you have to install it first), which also allows you to step-by-step debug your scripts in the game with breakpoints and all.
- It's slightly faster
- It has full access to the .NET class library by default (while i'd probably limit this to enhance security)

I guess I'll try to come up with some form of diagram for the planned architecture sometime soon. Since I have more or less working prototypes for both systems, this shouldn't take long.

 

You mentioned using IronPython to execute legacy scripts; is there a reason why people couldn't use it to script the simpler things (a la present day modding/scripting)?

If not, modders who'll stick to adding content and simple scripting can then stick to python. Modders who would deal with the core rules and such are likely to be capable of handling programming in C#, IMO.

 

It may be possible for quite a large part of the current scripts, but certainly not for all. It's easier to tune the asset conversion for the vanilla version of the game (i.e., the sectors and all that stuff will be auto-converted to an easier to use format), because the Co8 mod for instance uses a lot of undocumented quirks in the ToEE engine to make some mods possible. None of these workarounds will be necessary in a new engine, and they would have to be implemented specifically in the wrapper around the legacy scripts. I'll definetly look into this however.

Conclusion: I think I'll go ahead with C# + IronPython then.

Thanks for all of your input!

Regards,
Storm