Why JavaScript will be king of Indie Games Development { IN DETAIL }] Thread

Why JavaScript will be King Of Indie Development [Part 2 of 3]

2a) WHAT IT’S DOING

JavaScript and its transporter AJAX are the workhorses of the internet – so much so that HTML5 files can be reduced to two tags: <!DOCTYPE> <SCRIPT>. Offline JSON is the major inter-program shunt for porting languages. The last decade added to all of this with the provision of improved markup in CSS & SVG and dynamic graphics frameworks like JQuery added real spice. On top of this interface MVC’s and Cloud CMS frameworks have come on in leaps and bounds. And in recent years we have seen the rise of JavaScript Servers that shunt gamer information at bullet train speeds. In addition a lot of localized indie Web Developers, have been pushed out of the market by build-your-own-websites, recession and clouds. Many of them seen web 2.0 as the end result for text/image presentation and you all know there are mainly three sites to get tons of video and inspirational content - TED.com is one of them. Their hearts are telling them to head to Gaming and with Unity5 the top-end choice for JavaScript its perfect now and poised for the up-and-coming paradigm shift.

2b) CURRENT WAVES IN JAVASCRIPT GAMING

HTML5 and JavaScript/ECMA development is as much about games as open-sourcing the video player. The Canvas element is dynamic and full-screen capability is there. CSS3 takes the styling and positioning to a 2D gaming level though physics-like effects need to be rendered as images, client-side JavaScript can animate and run one player games. Client-side JavaScript Servers are popping up and they work at bullet-train speeds - meaning less servers need buying and/or leasing. WebGL 1.x seen the arrival of a new Web 3D standard. It is based on the OpenGL language and will be the bridge for OpenGL coders to web-based gaming. JavaScript Web designers are sucked in to keep the servers open as well. The current generation of OpenGL 1.x lacks some bells and whistles but it is just about to jump to the next league.

you are basically betting on webgl / ASM.JS and browser based gaming taking all of the friction out of gaming. I kinda agree. The internet will become the store, not some platform you install on your PC. Interesting to see where it goes

INtense! wrote:

you are basically betting on webgl / ASM.JS and browser based gaming taking all of the friction out of gaming. I kinda agree. The internet will become the store, not some platform you install on your PC. Interesting to see where it goes

Not just that. In my opinion JavaScript has superior abilities due to its extreme flexibility. In my opinion it is a language that does not force upon you certain coding rules and guidelines, it just adapts to whatever you're capable of. Wanna write procedural? JS got you covered. Want simple, one-class inheritance? JS can do that, too.

He isn't just betting on web browser based, JavaScript driven games. JavaScript has a much higher capacity than that. Seeing the node.js project rising should make this more than clear. Given NodeJS, we are now capable to write entire cross-platform programs in JavaScript. Its user base is ever growing, its easily accessible modules are normally oddly sophisticated if you compare them to, say, most extensions for Joomla.

@etherflows

I must heavily criticize your mentioning of Unity3D in this context. During my few days of work with Unity I learned that what they call JavaScript actually is UnityScript, a bad mock of JavaScript sadly removing most of its capabilities. Hence my efforts to embed JavaScript in a managed or native plugin for Unity in the future, and in an engine plugin for Unreal Engine 4 now (as it is much easier given the source code of UE4 and its reflection system).

Foreword

I got carried away responding to INtense!, so consider this additional reading. Everything written down here comes from long years of experience working with the - in my opinion - greatest programming language of the world. I'm literally hyping JavaScript.

Regarding my expertise: I've written countless unpublished web apps in JavaScript, played around with ThreeJS, written unpublished NodeJS applications to automate tasks including building and deployment of my projects, and even implemented the Rhino JavaScript in Minecraft. I could probably tell you nearly anything about JavaScript, unless you're asking for vulnerabilities... Ask away, if you need to.

The strength of JavaScript

One of its extreme strengths lies in anonymous functions which can lead to madness such as the following. I'm sure many web developers here have already seen such code.

require(['jquery', 'bootstrap'], function($){
    $(function(){
        $('#my-special-link').click(function(e){
            e.preventDefault();
            $.ajax({
                url: 'https://www.google.com/',
                type: 'get',
                data: 'q=bla',
                dataType: 'htm',
            }).done(function(response){
                console.log(response);
            }).fail(function(xhr, errmsg, error){
                console.log(errmsg, error);
            });
        });
    });
});

I've followed NodeJS since its early days, back in 0.2.13. It's now at version 4.something. It basically embeds JavaScript seamlessly into your operating system, allowing to write equally crazy code like:

var config = require('./config.json'),
      fs = require('fs'),
      Promise = require('promise'),
      readFilePromise = Promise.denodeify(fs.readFile);

var promises = [];

promises.push(readFilePromise('foo.txt'));
promises.push(readFilePromise('bar.txt'));
promises.push(readFilePromise('baz.txt'));

Promise.all(promises).done(function( res ) {
    res.forEach(function(elem) {
        console.log(elem);
    });
});

The greatest caveat I have for JavaScript is that one must define his or her own clear coding guidelines to clearly structure code. Otherwise it can obviously become a huge mess with all those nested anonymous functions, especially in NodeJS where callbacks to asynchronous functions are standard.

JavaScripts capabilities as a game's main programming language

Now imagine if JavaScript was available to developers OFFLINE, not just browser based when using rendering frameworks such as ThreeJS. You'd probably write seamlessly interacting code like (Unity example not using UnityScript but a fictive implementation of JS):

var player = Game.GetSceneObjectByName("player_character"),
      KEY = require('keys'),
      exposed = require('exposed'),
      vector = new Vector3(0, 0, 10);

player.on('keydown', function(e){
    if( e.which === KEY.UP ) {
        player.transform.translate(vector.mult(Time.deltatime));
    }
    else if( e.which === KEY.DOWN ) {
        player.transform.translate(vector.mult(-Time.deltatime));
    }

    if( player.tags && player.tags.indexOf('vampire') > -1 && exposed(player, 'sunlight') ) {
        if( typeof player.hurt === 'function' ) {
            player.hurt(5 * Time.deltatime, 'vamp_dmgsrc_sunlight');
        }
        else if( player.hp !== undefined ) {
            player.hp -= 5 * Time.deltatime;
            if( player.hp <= 0 ) {
                player.emit('kill', 'vamp_dmgsrc_sunlight');
            }
        }
        else {
            console.log("Don't know what to do, the standard stuff I can handle isn't available. :(");
        }
    }
});

This is just a basic, dumb, difficult-to-maintain example, but it demonstrates where the power of JavaScript and its standards would come in quite handy: event handling, its "typelessness" (i.e. the fact that you don't have to but can care about the types of variables and properties), and its optional nature. Even functions can be treated as plain fields and bound dynamically, which can be an extremely powerful tool. Note that you could easily pass either a string (e.g. 'vamp_dmgsrc_sunlight') or an object (e.g. enemy) to the trigger function. Given proper documentation event handler implementers could easily determine what is meant by calling typeof dmgsrc === 'string' or typeof dmgsrc === 'object', provided that dmgsrc is the argument corresponding to the event argument.

The probably inarguably greatest advantage of JavaScript as your main scripting language is the mere fact it is an interpreted programming language. This means if your game is written mainly in this language, you can easily allow modders to rewrite portions of your game and change, for instance, the storyline without much effort. Using the web development approach to client-side scripting would change up the game entirely. Instead of associating scripts directly with game objects, these objects ought to be available through a singleton manager, all providing an API for manipulation and featuring an event system to allow the most dynamic programming you could want in game development.

Frankly I don't quite understand why using JavaScript still is not an option in Unity3D or Unreal Engine 4. Given that most browsers have their own implementation written in C/C++, it would be easy to build your engine around such a library while still shipping your own solutions (e.g. UE4's BluePrint scripting). Instead it's now up to the Indie developers to write, release and maintain such plugins.

Private vs public properties and methods

Many people say JavaScript doesn't support public and private fields. This isn't true. While there is no native support for this by keywords such as private and public, the scope of the variables and properties defines their accessibility. Consider this code:

var globalFoo = 'foo';

(function(){
    var localFoo = 'bar';
    console.log(globalFoo, localFoo); // "foo" "bar"
})();

console.log(globalFoo, localFoo); // "foo" undefined

function MyClass( ) {
    var lol = 'cat';
    
    this.bar = 'lol';
    
    this.getLol = function( ) {
        return lol;
    };
}

var myInstance = new MyClass();
console.log(myInstance.lol, myInstance.bar, myInstance.getLol());
// undefined "lol" "cat"

Though this comes with a heavy caveat. JavaScript technically does not feature a class system. Note that I am not using a class keyword, but instead I directly instantiate a function. JavaScript uses prototyping which basically defines class methods in an object shared between the classes. This relaxes memory and performance a bit as a single function instance is used across all instances, however if you assign functions inside the constructor, these functions will be created every time you create an instance, thus it will stress the interpreter, memory and CPU more. Thus I should discourage the use of such a setup.

Conclusion

Anyway, the whole point of this is JavaScript's extreme flexibility. You can comply to the standards of other developers, in the example of private variables just prefix your properties with an underscore ("_"), or go the route in my example above. JavaScript does it anyway.

It's funny because as a web developer, in the early days Javascript was such a frustrating language because every browser implemented it in a different manner. But all of the libraries that sit in front of it now has made it such a joy (and so flexible to use). Wish ModDB was built on a JS framework now!

Clarity:

The 3D web had already being been marked-up [VRML/X3D] before WWW rolled out in Ireland (1995). It could be inserted directly into HTML via...

The "FORM" submitter dropped the "VRML" TAG for obvious reasons.

@INtense:

Wish ModDB was built on a JS framework now!

I feel the same way about so much of my work now. e.g. time writing XNA (Xbox/PC) GDK only to have MS pull plug.

@TheZyriusOne

Your ability to see into the heart of JavaScript makes me J-ealou-S.