Scrap that Scripting System!

[gwheeler 0]

As a longtime BIS fan and a programmer, I am coming out the shadows to post a few thoughts:

The whole concept of ArmA is huge. There's so much that has to be accounted for, reproduced, implemented... I think it is asking too much that the BIS dev team be responsible for providing a completely accurate warfighting game out of the box, especially when so many end users are looking for so many different things out of the experience. There are a far greater number of people outside of BIS who know what a 4-bladed AH-1 should sound like, or who know what standard radio calls and language or map symbols are used by the US Marines, or FDF, or SAS. If you give them a solid foundation on which to build, they can take care of all that stuff.

My main concern with the game is that it has a flexible, open, and (this is crucial) WELL-DOCUMENTED architecture for allowing user interaction and modification. The fact that so many people have slogged through poor documentation, in order to use crude tools, to create new content and game experiences for ArmA, is a testament to the passion and dedication of this community. The "Evolution" mission is one of the best examples (just that I've seen, I'm sure there are lots more) illustrating this passion. That level of dedication is not an inexhaustible resource, however, and it will eventually die off if it is not nurtured.

I'll be the first to admit, scripting in OFP was what got me interested in programming again. Now that I've been a professional web developer for a few years, I've been exposed to a wide variety of languages, platforms, architectures, and design patterns. I've been guilty of re-inventing the wheel plenty of times in my own right. It's a part of the programmer's journey. Quite often you don't start out intending to do so and it just happens. The AFP/ArmA scripting language had its origins in a simple one-off expression interpreter for the mission editor. It wasn't designed to be a full-fledged programming language. but it's being pressed into service as such.

I don't mean to be harsh, but let's face it: This thing they have created is like the bastard love child of LOGO and Visual Basic for Applications, with a little Reverse Polish Notation thrown in for good measure.

There are lots of excellent, powerful, and flexible interpreted languages out there that are perfect for embedding into a game engine in order to define and manipulate the game logic layer. Python and Lua have proven very popular and capable in this arena, and I daresay even ECMAScript/JavaScript would be better suited to the distributed, object-oriented simulation that is ArmA. In fact, JavaScript's prototype-based OO and on-the-fly object manipulation combined with anonymous functions would allow for some very flexible scripting and game behavior.

The fact that people are able to build things like GUI-based fire support systems and missions like Evolution using the current technology is pretty amazing. If these people had access to a real OO language, with a more straightforward syntax and solidly-documented API, imagine the kinds of stuff we'd be seeing and doing with this game.

That's pretty much the crux of my personal rant. I realize my suggestion to scrap the current scripting system is probably not very feasible, for both short and long term financial reasons. In the short term, they are invested heavily in the current architecture. In the long term, giving players a better set of tools and documentation could potentially result in BIS losing money because the community isn't just going to rush out and buy the newest game if its content and gameplay can be better implemented by the community itself. That scenario might not hold true in a lot of genres, but I think the ArmA crowd tends to be more mature, more hardcore and more passionate about crafting a certain game experience.

If you've gotten this far, you're a trooper! Thanks for listing to me ramble, and by all means weigh in with your thoughts on how we can best enhance the modding experience while keeping BIS out of the poorhouse.

[.kju 3245]

It is possible to use a second language on top of the BI scripting

language and write a software to convert language X to game

language.

It has been done by one guy in OFP (unreleased though).

With sqf/function use it should work even better.

Not sure if the result would be desirable though.

The core problem is that the engine needs to understand the

functionality you want it to do.

So only switching to a different language for the end user is just

the very start of it I think.

Also it might be easier for people to learn sqf than c++/python/lua. Hard to tell.

Yet it is not only about experienced programmers.

More direct access to the engine itself could be a more suitable

way, so that people can write their own functionality.

As you understand this is by far not an easy topic to decide as well.

[Serclaes 0]

You dont even need to get so far in the "engine".

I believe for a command there are 3 holding columns to make it a useful command:

1. execute (dude engineOn true)

2. undo execution (dude engineOn false)

3. get the state (isEngineOn dude)

Some main functionality has not been integrated (or disintegrated). Try once to make a convoy, which is following waypoins, stop and then moving again. On the fly by triggers. forceSpeed could have been useful for that but it doesnt work since 1.08. But forceSpeed is missing something: the check. Is the vehicles speed forced? You can't tell. Once every command has this 3 parts it can be used correctly.

[sbsmac 0]

I opened this topic thinking it was just going to be another uninformed 'why don't they use C++/java/XML' plea but this is pretty interesting so thank you gwheeler for voicing many of the things that I have been thinking over the last couple of years. :-)

During my career I've written a couple of interpreted environments and also integrated an 'expect/tcl' engine into some in-house code so have some experience in this.

Many readers of this topic will probably confuse syntax, grammar, language-primitives and API functionality and assume that they are all the same thing. However, I would go out on a limb and suggest that changing the scripting language may not be that large a job and would not completely destroy the 'character' of the environment.

Syntax/Grammar: ie, where do braces and semi-colons go. Do you use reverse-polish to specify parameters etc ? I agree with gwheeler that this is currently one of the most unpleasant aspects of the script language and one that could be improved by replacing it with something else.

Language primitives: ie, existence of functions, iterated loops, non-premptive scheduler for multiple tasks. Virtually any other environment being discussed would offer these as well as extensive other advantages (such as inheritance, polymorphism etc). The current scripting environment does some type-forcing IIRC so this might require some consideration but again, most standard interpreted environments provide very flexible typing.

API: ie, 'forceSpeed' etc. These calls can typically be made primitive functions in a 3rd party scripting environment. That means they just trap straight into the underlying 'C/C++' code in the engine. So all the functionality that people are used to remains (including existing naming); it's just that the syntax changes slightly and you get to write

setWeapon(player, "G36a") ;

or

player.setWeapon("G36a") ;

instead of

player setWeapon "G36a"

So, speaking hypothetically, what would be required to make a change ? (It should be obvious I don't have any inside knowledge of the ArmA codebase and am only basing speculation on other systems I have worked on.)

First, choose your preferred replacement. Licensing/IP issues might be a factor. You also need something that is designed to be embedded and provides some control over memory usage, scheduling, error-handling etc. I suspect you also have wrinkles in a game that you may not have in other environments (eg, you want to seriously constrain access to the outside environment such as files).

Next, you need to integrate the scripting engine into the existing codebase. This can be quite straightforward. IIRC, it took less than a week to integrate the TCL engine into the application I mentioned earlier. Problems here are more likely to be related to how far the existing script engine has got its hooks into the rest of the codebase.

Finally you need to start fixing up all the existing API functions. This is fairly tedious but not very technically challenging. If you have a good formal description of the API via header files, XML or some other regular format it can be quicker to write a tool to automate this process than to step through each one by hand.

But I suspect that the impediment is the legacy problem of all those existing scripts and content-creators who would be reluctant to move to a new, improved environment. That may be less of a problem for ArmA the game but VBS, based on ArmA, must have a huge legacy script base by now as well as a large customer base that would be reluctant to switch.

I think it's clear that BIS don't regard their business model has being one in which they provide a 'platform' for content-creation. They sell games, and most purchasers are interested in the 'out of the box' experience so this is where they quite reasonably will focus effort. Even with the existing scripting environment you can see this in the sparse documentation and the random availability of API functions which seem to be added as needed when a particular campaign mission requires it.

I do wonder if there is a viable alternative business model whereby Arma is provided as more of a platform and BIS collect and publish 3rd party content after performing QA. Of course, that would be a very different approach and you can hardly blame them for wanting to take the risk of changing what worked very well for OFP ! (Are there _any_ games companies that operate a 'platform' model ? Perhaps the Sims or some flight-simulators might be closest but even they tend to have a strong core standalone game.)

*Edit* Just found a couple of links which expand on some of the topics above using Lua:

API-fixup

general overview

[MulleDK19 21]

2 things on my wish-list for ArmA 3.

1. Lua for scripting

1. DMM for physics

[no use for a name 0]

I think they really just need a brand new engine; one that can support physics and is better optimized. Just re-writing old code and tweaking a 10+ year old engine will just keep adding to the problems IMO

But I'm no programmer so...