• Register
Post news RSS Preliminary Hotspot support - HD Video

We have added hotspot and Javascript support to our brand new engine (we are building a game completely from the ground up), letting mods get much more complicated. Check out this HD video explaining the feature.

Posted by on

One of the technologies we've been focusing on recently is game scripting. As part of this effort, I've been working on hotspots. Hotspots allow us to assign a physical location to scripts. We will be using them to initiate dialogues, trigger special effects, incite AI reactions, and much more. And, of course, they will be fully moddable. Here's how they work:

We have Google's V8 javacript engine running in the background. This allows us to execute javascript scripts whenever we want. We keep these scripts running in a persistent context, so functions and variables defined in one script can be referred to in others. Previously, users could write and run scripts only in the console. Now, hotspots can also execute scripts. In the following video, I create two hotspots, one to initiate a "woozy" camera effect and a second to end it (the actual scripts are loaded in a file chooser offscreen). John once again owned the voiceover.

These scripts have the full power of javascript at hand. But they must also interface with the engine itself. To do this, we explicitly expose certain engine functions to the javascript interpreter. For example, when the interpreter comes across "Camera.setFOV(90)" it knows to call back into the C++ engine, executing "Camera::Instance()->setFOV(90)" in engine.

Hotspots aren't the only entities that can call scripts. At the start of each level, a "level script\" is executed. The level script serves to setup parameters, and it's a convenient place to define functions for later use. Here's the code for the level script in the video:

level script from video

With this level script in place, the first hotspot was just linked to a script that calls woozy.start() and the second was linked to woozy.stop().

Right now, the scripts can access various camera, graphics, and network controls. Soon we will expose much more (e.g. object creation, movement and transformation controls, rabbot spawning, etc). Hopefully it will be flexible enough that people can make all sorts of random mini-games.

Do you guys have any suggestions for how hotspots and scripting should be handled?

Track us on ModDB (see our cool page)
and also join:
- Facebook
- Steam
- Twitter
- YouTube

Varsity - - 1,044 comments

Did you really just post a screenshot of some text? :-P

But seriously, JavaScript support is a great idea. Why learn Lua or something proprietary when you can use a language that transfers to other places?

Reply Good karma Bad karma+1 vote
MuffinSoldaat - - 45 comments

I presume that's a small snippit of a code.. guess we'll all have to adjust and learn some Javascript, well, atleast I do

Reply Good karma Bad karma+1 vote
Dragonlord - - 1,934 comments

Simple reason: LUA is well defined and optimized. JS is a total mess and every implementation works slightly different. Furthermore it's not well optimized. Using Python would have been much better since it's highly optimized and well defined. Furthermore it supports lambda constructs and other "magic" that would be nice in games ( like automatic type mangling ). JS doesn't support such things. Furthermore it's slow but for small scripts this would not be that much of a problem yet though it's not an advisable choice altogether ;)

Reply Good karma Bad karma+1 vote
jeffr Author
jeffr - - 383 comments

Totally disagree. Those are a lot of myths that are easily debunked (maybe I should write a ModDB article?)

a) Javascript is specifically defined. ECMAScript 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. You're thinking about Netscape versus IE, or something.

b) Javascript is extremely fast. It is very optimized and keeps getting more and more so -- look into Google's V8 (which we are using), Tracemonkey, Squirrelfish / Nitro, 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 huge amounts of original research in this area.

c) Javascript is a dynamic language which supports all sorts of rich introspection and other "magic". I have to admit I don't really understand what you mean by automatic type mangling, despite being fluent in Python, but I am sure Javascript can do whatever you mean.

Reply Good karma+2 votes
Varsity - - 1,044 comments

V8 is a single implementation that's (supposedly) very much faster than standard JS interpreters.

Edit: beaten by Jeff.

Reply Good karma Bad karma+1 vote
chris_sloany - - 2,830 comments


Reply Good karma Bad karma+1 vote
Desumilk - - 80 comments

You guys are really dedicated to your stuff. A news update every week. It's amazing.

By the time you end up with the perfect game engine, will you still have the will to create Overgrowth, the actual game? :D

Reply Good karma Bad karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.