Hey guys, we are using JavaScript for the scripting system in Overgrowth. Unfortunately, every time we bring it up, we get a lot of flak about the language. Here are a few common misconceptions and my response to each of them.

Myth 1: JavaScript is just a clowny version of Java
JavaScript is actually totally independent of Java. The only thing it shares is slightly similar syntax. The reason why it has Java in its name is due to marketing reasons. According to Wikipedia, "The language's name is the result of a co-marketing deal between Netscape and Sun, in exchange for Netscape bundling Sun's Java runtime with their then-dominant browser." JavaScript is a brand new language that shares much more with functional languages like Lisp or even Scheme than with Java.

Myth 2: JavaScript is loosely defined and unpredictable
JavaScript is very specifically defined. Google's V8 Engine adheres to ECMA-262, 3rd Edition which has no room for misinterpretation. V8 and other JavaScript engines have literally thousands of test cases to verify that they stick *exactly* to the specification. When people say that JavaScript has a lot of inconsistency, they are probably confusing JavaScript with DOM APIs* which are notoriously fickle between browsers -- namely older versions of Internet Explorer.

Myth 3: JavaScript is very slow
JavaScript is actually quite fast. It is very optimized and keeps getting more and more so -- look into Google's V8 (which we are using), TraceMonkey, Squirrelfish Extreme, etc. A ton of companies have HUGE vested interest in optimizing JavaScript and JavaScript performance increases all the time. Browsers live and die by their JS execution performance so there is a lot of original research in this area.

Granted, it is not as fast as a compiled language like C, but we don't need it to be. Our scripting engine is not the bottleneck in Overgrowth, which basically means that even if the V8 JavaScript Engine got a 200x performance boost overnight, your Overgrowth FPS would not be increased.

Myth 4: JavaScript is a crappy language and only suited for small browser tricks
JavaScript is actually an awesome dynamic language that can definitely stand tall. JavaScript features prototypal inheritance which is hard for a lot of people trained in classical inheritance to wrap their heads around. This often leads to claims that JavaScript is not object oriented, doesn't support complex programs, etc.

Well, actually JavaScript does support classical inheritance as well, and with a few coding patterns, people trained in languages like C++ or Java should be ok.

JavaScript is a dynamic language and this lends itself to a lot of cool behavior. Here is a demonstration of how you can take advantage of higher order functions from my friend, Chris Pennello, CTO of Redux. This is an implementation of Python's functools.partial:

function partial() {

  var f = arguments[0];

  var a = Array.prototype.slice.call(arguments,1);

  return function() {

    return f.apply(this,

      a.concat(Array.prototype.slice.call(arguments)));

  };

}

This will take a function as its first parameter (a function is simply an object in JavaScript) and return a new function that calls the original function with the remaining arguments.

This is just the tip of the iceberg. This site has all sorts of functional programming niceties that Python programmers are familiar with: map, reduce, zip, select, etc.

Post your questions or comments about JavaScript below and I'd be happy to answer them.

Here is what is new in Overgrowth in this weekly alpha. If you are confused what a weekly alpha is, or even what Overgrowth is, please read our fancy FAQ. Basically, we are developing a massive video game from the ground up -- we are able to do this completely independently by accepting preorders for the game before it's done!

We have a pretty exciting alpha this week. Sorry I didn't get a chance to blog about WebKitten last week, I will try to let you guys know what it is this week. :)

Here's a few highlights from the source repository:
- Initial ragdoll physics
- Initial pathfinding AI
- Shove sound effects
- Post processing effects (post 1, post 2)
- Better uphill movement
- Added text display to scripting
- Overhauled transformation system (map editor)
- New undo/redo system in progress (map editor)
- More modular editor hierarchy in progress (map editor)
- Bug fixes

Jo-shadow is in charge of organizing the community maps and has done a great job in his thread in the Secret Preorder Forum.

Matto1990 has teamed up with Jo-shadow and has made an Adobe Air downloader app that automatically installs and manages all of the mods (view thread). This is really hot and we be posting about this soon.

Thanks as always for all the support! See you guys in IRC and the forums.

I ran into an interesting bug when I was messing with an early version of David's shadows. I was a little surprised to see my full name projected onto the ground:

My name inscribed in the terrain

I often hear that you should always initialize your memory before using it, but I had never seen such a vivid example of what happens when you don't! Mac OS X draws the screen using OpenGL, so if you use uninitialized VRAM as a texture, you can accidentally load discarded images from earlier computer use.

Here are a few more screenshots:

So, try not to display raw allocated memory to the user. :) You never know what might be in there.

Keeping track of all objects, groups, hotspots, scripts, characters, and more in a big Overgrowth level can quickly become a headache. We started noticing this with Hale's massive Foothold map, and it's becoming more apparent now that I'm adding hotspots and other new entities to the editors.

So, we've been playing around with a number of abstracted interfaces to organize things. Awhile back I wrote about our object browser. The object browser helps users find and load content into a level. But, once the content is in the level, we might benefit from further organizational interfaces. Which leads us to the group browser:

The group browser displays a hierarchical list of groups and objects in a level. Clicking a name selects the corresponding entity in the editor, double-clicking a name allows the user to change the name, and clicking a group's triangle expands that group's list of elements.

Through these simple interactions, the group browser already has some power. It provides quick navigation to specific, named content, it presents an overview of all objects in a level and shows how they are organized, and it allows for sub-group selection (note: scrolling in and out over a group also accomplishes this). Eventually we may give the group browser much more power. For example, we might add a search bar, a "zoom to group" button, a "hide group" button, and assignable colors and annotations.

But, browsers like this can also be a bit clunky, and they're not strictly necessary. I'm a big fan of streamlined, immersive UIs that minimize the intrusion of floating windows and buttons. We don't want to clutter things up with a marginally useful browser. So, do you guys think the group browser will be useful, once it is in a more finished state? How can we make it better? What other sorts of organizational interfaces would you like to see?

I had a lot of fun the other day experimenting with post-processing effects, so I made a video to show how they look in action, and to explain how some of them work. While they are fun to play with, we will probably focus on them last -- we want to make sure that Overgrowth looks great even without post-processing! However, if you pre-order, you will be able to try all these shaders in the next alpha. You can also change the shaders, and they will update in real-time.

Here is the video, click here for HD!