PA Scripting types/3D modeling types

As you may have noticed, I posted a thread in the general forum stating I'm beginning a new project, it would help me a lot if Uber could disclose what language the scripting will be in, as well as what type of 3D modeling they will use (So I could learn how to script for PA, thus greatly accelerating the development of my autoscripter, that is, unless Uber already has an autoscripter).

Your safest bet is probably something like Javascript for the unit scripting (they've already talked about having json blobs for planetary descriptions) and anything that can output to Autodesk's FBX format. Lots of 3d programs do this already.

Scripting language I have no idea, there are so many options we'd need Uber to confirm what they intend to implement. Previous games like SupCom have apparently used LUA, so that may be on the shortlist, however it could also end up being Javascript, C#, Python, or a totally custom PA scripting language based on any / none of the above.

Having said that, all programming languages have the same basics (loops, variables, tests etc.) so familiarity with one helps facilitate understanding of any, up to a point. If you already know / are learning a language, then it will automatically be some help getting to grips with whatever gets implemented in PA

For 3D modelling things tend to be a bit more standardised, and most packages can save in a variety of formats, so if you already have one you can use for the TA part of your project, it'll likely be fine for PA as well.

I'd recommend using whatever you've already got for the TA project, as a lot of resource will likely be directly transferable to a PA project. Once we get details from Uber you just need to look at porting the usable parts wholesale, and only rewriting bits that won't port directly. Another option would be to integrate the PA specific code into the TA project (a one size fits all program that can do both platforms) however those usually end up more work than implementing 2 seperate programs with a lot of copy/paste. I would not recommend integration if this is a first project, shoot for 2 seperate projects and consider integration after you get both working seperately. That way you don't get PA issues delaying TA functionality or vice versa.

Personally I'm waiting for Uber to confirm what they'll be implementing (or have implemented) as I'm a lazy bugger and don't want to install something (i.e. a 3D package) that turns out not to be optimal. I'm also familiar with enough programming and scripting languages to believe that I should be able to eventually get to grips with whatever scripting language gets implemented. Unless it's LISP or COBOL, in which case I will cry :cry:

*Lua

Nobody says MOON, so don't call it LUA.

I obviously made an incorrect assumption in the origin of the name (assuming it to be an acronym / backronym like most other languages)

In my defense, if common language is allowed to corrupt "Light Amplification by the Stimulated Emission of Radiation (LASER)" into lowercase, and (incorrectly) use it as pluralisable noun, I don't think MOON should be considered too much of a faux pas

Massively Orbital Object (Night-time)?

I'm going to vote for Perl. But I suspect that I am going to be alone on that one.

Python, Ruby, or Tcl would be fine really. Even C# would work.

Why hasn't anyone mentioned Whitespace yet?

It's most likely going to be JavaScript. They've already confirmed that Webkit with V8 (JavaScript) is going to be behind the UI, so why have two scripting runtimes in the same game? I'm OK with that, JavaScript is everywhere nowadays.

That said, I wouldn't say no to Python, Lua, Mono/C#, or Java. Even Ruby would be cool, but I think it might have performance problems for a game like this.

PRO TIP to anybody who might not know: Java and JavaScript are not the same thing. Java is a compiled, statically typed language that is fairly cross-platform. (Android and Minecraft are based on Java, for reference). JavaScript is an interpreted, dynamically typed scripting language that's primarily used for making web pages dynamic, but lately it's being used for a lot more.

Actually Javascript is a pretty solid choice I think. Its very easy to learn and use, fairly powerful, runs out of a library pretty much everywhere, and tons of people (myself included) already know it. In fact its one of the most noob friendly languages that I know of.

My hope is they go back to good old fashioned C/C++ plugins for mods, like all the Quake/Half-Life games used, it may be more of a hassle to write but the performance improvements can be significant, when dealing with potentially tens of thousands of units that might have modable behavior it only takes a few inefficient lines of code to bring a PC to it's knees, when you add an interpreted language into the mix as well you might as well forget about having tens of thousands of units at a decent frame rate.

However I think the choice of scripting language (if any) will probably be largely dependent on what it'll be used for, AI could probably get away with an interpreted language, but anything that is used on a per unit level is likely to need native code.

You can always compile an interpreted language and the cache the result for future executions. You just have to be careful about variables getting carried over from previous executions. I have seen perl interpreters that do this to increase performance to very nearly C++ levels. I don't see any reason why you couldn't do this with Javascript.

However your point about poorly written code is quite correct.

Yeah true enough, I must admit to being quite impressed with the JIT compiler for Java on Android, once it sorts out what to compile and compiles it, it is reasonably quick, though in my experience the Java language it's self still slows things down a fair bit more than what you can get with C++ so it unfortunately doesn't help as much as I'd like. But if you are opting for a pre-compiled language anyway why not just use the best and fastest one: C++?

Also don't pay too much attention to the comparisons for speed between scripting languages and C++, most of the time they doing something that the scripting language is good at and the C++ comparison has been written without optimizing it to run as fast as possible using all the tools available (like SSE instructions), so for a game where you have more complex code, vast arrays of data to be processed and where the C++ code tends to be heavily optimized the performance differences are much greater. Just having full control over memory management can yield performance increases that many scripting languages cannot match, cache misses can be hard to avoid with large data sets if you don't have control over what memory is where and how it is used in what order.

To say one programming language is the fastest and best is pretty silly. Your programming language is only as fast as what your compiler translates it to (depending on the ISA). Ask Google why they went with Python and not C++ or ask CouchDB and RabbitMQ why they went with Erlang and not C++... Ultimately it depends on what you are doing and what is best going to suit your needs.

C/C++ compiles to native code, and the C/C++ code it's self more closely matches the CPU instructions than higher level languages which means it isn't as bloated with superfluous instructions that other compiled languages can produce so you really can't get much faster than that. Assembly, which is pretty much just human readable native code, can occasionally produce faster code than C/C++ because you can use it to ensure the minimum number of instructions needed to produce the required result, but you can just drop assembly code into your C/C++ code to speed up anything that might benefit from it anyway.

When dealing with compiled languages you are going to really struggle to find anything that is as good at leveraging the hardware as C/C++ is, that's why it's so widespread, and although Google use a lot of python the fact is that python (as with most higher level languages) just isn't good enough to use for everything and they have to use C/C++ for some things whether they like it or not, because C/C++ is the best (fastest, and most powerful) language. Unlike the higher level languages C/C++ can be used for everything there are no technical reasons why the language could not be used to accomplish a goal that another language could.

However you are right, it does depend on the use as to what the best language for a particular project is, although C/C++ can be used for everything there are often other languages that might be more suited to the job. C/C++ is not the easiest language to use or learn and because of that development with it is often slower, so for hobbyists making simple programs, projects where development time is more important than the efficiency of the program, or just lazy programmers who just want their program to run without needing to think about how it's structured then something like Java tends to be a lot better for their needs but for games in particular C/C++ is still king. If you just compare the languages for what they can produce it's very hard (if not impossible) to beat C/C++, so the only reasons not to use C/C++ are for issues not directly related to the language it's self, such as development time or personal preference/expertise of the developers.

When I learnt to code, C was considered a high-level language

From a scripting standpoint, Uber are going to want something that is straightforward to implement (easy to plugin to their existing engine) and is efficient enough. Given the nature of the project, ease of implementation is very likely going to trump efficiency as the most important aspect

Haha yeah, it still is which is why I tried to use higher level instead of just high level

As I said in the other thread, despite my hopes for all C/C++, I suspect they probably will use a scripting language for at least part of the modding for that exact reason, but I'd be very surprised if there was a scripting language efficient enough to use at the unit level given how many units Uber are hoping to support, of course there might not be any need for unit level code to be modable anyway, and I think certain scripting languages should be efficient enough for just about anything else in PA (that I can think of).

Yeah, I cannot for the life of me decide what I would actually do in the same situation; if it is implemented on a per unit basis, I'd probably consider a custom language/interpreter with a bare minimum of functionality, abandoning versatility in favour of simplicity (and therefore speed).

Having said that, technically even if you have no customisation available, each unit is going to need to check against a preset AI behaviour pattern anyway. There's already an AI overhead per unit, so as long as you don't extend it too much, unit scripting could still be acheivable without constraining the unit limit to a few hundred on current hardware.

It's getting the balance right that's going to be the hard part :|

Presented for your consideration:
https://github.com/felixge/faster-than-c
It's a very different scenario, but I found it interesting. It definitely suggests that code quality is by far more important than the language used.

That Title Bait got me too. But that was a really good read.

10 seconds of reading and I found this:

Still an interesting read though, optimization is always good to read up on, there are all sorts of little tips and tricks you can pick up to make certain solutions faster .

The point I was trying to make is that the "speed" of a programming language (which doesn't really make sense...but referring to execution time for the sake of argument), is completely dependent on the output of your compiler. You made the assumption that C++ is compiled into machine code...which is generally the case, but your compiler can turn it into anything... There are C++ compilers that can take C++ code and turn it into an interpreted language. If your compiler is bad, your execution time will suffer.

Some compiler/language combinations are going to perform better/worse on different instruction set architectures. C++ has been around a while and I would agree that for x86 and x64, it's going to be hard to beat (in regards to execution time) the output of the most optimal C++ compiler.

The notion of "the fastest" programming language makes no sense. You would have to argue "given this compiler and this programming language, the output generated has the fastest execution time on this instruction set architecture".

As for a comparison between assembly and C++... that comparison doesn't really make sense either since C++ can be compiled directly into assembly and assembly being just a representation of the underlying machine code. As for a dude manually writing assembly code, he is going to be at a disadvantage because a compiler has a ton of optimizations it can utilize that the programmer might not be aware of.

As for speed of development time... C++ is definitely not in the front.