Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon Join the GFS Discord Server!
4. May 2019

BabylonJS, an open source browser based game engine, just released a major update in the form of the 4.0 release.  In addition to a website makeover and new forums, the 3D game engine gained several improvements including a new Inspector, improved PBR rendering capabilities, physics support via the Ammo.js plugin and much more.  If you are interested in learning BabylonJS, be sure to check out our existing tutorial series available here.

Top level features from the release notes:

Be sure to check the complete release notes for more details, as there are dozens more improvements as well as several breaking changes for Babylon v3.x developers to be aware of.

BabylonJS is open source and available on GitHub under the Apache open source license.  It ships with an excellent interactive playground that makes learning and playing with BabylonJS a breeze.  There is also a complete cloud based level editor available here.  Check out the video below to learn more about this release and to see that playground, inspector and editor in action.

Video HERE

GameDev News

6. June 2017

There are several game engines out there that present a code free option such as Stencyl and Construct.  Today we are looking at an open source alternative, GDevelop.  It is a cross platform, open source 2D game engine with a visual programming interface that requires no previous experience.  However there is also the ability to extend the engine using the C++ programming language if desired.  If you are new to the Closer Look series, it is a combination of game engine review and getting started tutorial helping you decide if a game engine is right for you.

As always, there is a video version of this tutorial available here and embedded below.

Without further ado, let’s jump into GDevelop.

Meet GDevelop

As mentioned above, GDevelop is an open source 2D game engine.  It is released under the MIT license for the core engine, while the editor is available under the GPL v3 open source license.  The code is available on Github.

Of course you don’t ever have to touch the source code to work with GDevelop.  You can download binaries for Windows, Mac, Linux as well as Browsers, iOS and Android in the form of GDevApp.  I will not be covering GDevApp today however.  GDevelop is able to compile native applications, HTML5 pages as well as Android applications, which is currently an experimental feature.

The vast majority of your time is going to be spent in the GDevelop editor, shown below.


The center of the screen is currently showing the Scene editor.  There is where you can compose scenes.  It is a tabbed view that can contain multiple open scenes as well as Events, the programming model of GDevelop, which we will discuss more shortly.

On the right hand side is the Objects Editor, which contain the building blocks of your game.  On the left hand side is the Project Manager containing the assets and scenes that make up your game.

Let’s walk through creating a sprite in a game.  In the Objects editor, right click objects and select Add an object.


This will show us a list of possible objects:


For every object except the Sprite you need to enable it before you can use it (thus why they are grayed out).  It’s as simple as double clicking a grayed out object to enable it however, like so:


In this case however we are going to use the Sprite object, which is already enabled.  Simply double click Sprite.  Double clicking the newly created object in the Object editor will open up the sprite editor screen:


At the top right corner of the editor window you will see the Images bank’s editor, click the plus icon and add the images you will use for your sprite.  Next drag the selected images down to the images section, like so:


You can rename and configure the animation (if any) under the Animations panel.


Now you can create an instance of your Sprite object by simply dragging it into the scene.


As we saw earlier, there are several built in objects in addition to the Sprite object, including Admob integration, a Text object, a tiled sprite (spritesheet), etc.   Next lets move on to adding some logic to our newly created object.

Scripting in GDevelop

Logic in GDevelop are implemented using Events.  Let’s look at an example of moving the sprite around when the mouse moves.  Click on the Events tab.


In the Events ribbon, click Add an Event:


In this case we have no conditions, we want this to happen every single frame.  Hover over No actions, then select Add an Action.


This is where the building block aspect of GDevelop programming comes into play.  Select All Objects->Position->Position of an object.


Now we can set the parameters for positioning our object.  First select the object to modify, then set each parameter.  In this case we set the X and Y values to those of the mouse cursor, like so:


Upon completion, you will see we now have an event defined:


In this particular case we have no condition, so our event will fire every pass through the event loop.  We could however have set a condition which causes our event to fire or not.  Here for example is a condition that will start playing some music once the scene is loaded.


Beyond conditions, there are other control structures you can add to events:


Link enables you to break link to another event sheet, enabling you to modularize your code.  It is also possible to define variables, both globally, to the scene and at the object level.  For example, right click the Project and select Modify Global Variables.


This now enables us to define new variables:


This can also be done at the object level, right click an object and select Other Properties.  Then in the resulting panel select Click to Edit...


While we are here, notice the Behaviors option?  This enables us to add new functionality to game objects.  Click the Add... button:


You will notice once again, by default all behaviors are disabled.  Double click a behavior to add it in.  Let’s go ahead and add Top-down movement as an example.  You can now edit properties of the new behavior in the same dialog:


This will instantly add arrow key navigation abilities to your object.  When you play your game, arrow keys will cause your object to move around screen.  Speaking of playing your game, hit the Preview button in the Scene ribbon to launch your game in your browser.


You can control application level settings of your project by right clicking your project and selecting Edit the property of the game.


This will bring up the next dialog.


Finally, if your project has Native extensions enabled, under the File menu you have the option to build a native version of your application.


Then simply click the Compile button.


Documentation and Community

GDevelop is reasonably well documented, with a Getting Started tutorial, several other tutorials and a decent number of starter templates to choose from.


There is also a manual available online.  If you are intending to extend GDevelop using C++ however, the documentation is almost non-existent.  However being an open source project, all of the code is available.  All of the behaviors and objects we used in this example are available in source form on Github in the extensions folder:


GDevelop has a dedicated forum available here.  It is reasonably active with a decent sized community.  Forums are available in both English and French.


If open source, free and a visual programming interface are important to you, GDevelop is definitely an engine to consider.  The documentation is adequate, the engine is mostly feature complete, although annoyingly some features such as Tiled support are only available for native targets.  The entire thing is designed around extensibility and if you are willing to dive into C++, the sky’s the limit on what you can do.  My biggest complaint is a lack of polish on the UI layer, experiencing a few crashes, some UI glitches that went away on a reload and some buttons that simply do nothing.  Most annoyingly, the engine is basically unusable on a high DPI display.

It is however an easy engine to jump into and use if you are willing to deal with some UI warts.  An MIT license around the core engine is always an excellent feature.

The Video


25. June 2012


In my prior post introducing the bones of our YUI based level editor, I showed the following way of loading in a template from the server:

initializer:function(){ var that=this, request ='/scripts/views/templates/person.Template',{ on:{ complete:function(id,response){ var template = Y.Handlebars.compile(response.responseText); that.get('container').setHTML(template(that.get('model').getAttrs(['name','age','height']))); } } }); }


This works, but it is less than ideal.  There are alternatives, but each has a downside.  You can compile the template into a JavaScript string, but then, what is the point of creating a template in the first place?  The nice thing about a template is, it is basically just HTML with a small bit of specialized markup in it.  You can send that template to a designer, who can then make modifications to your UI without knowing anything but basic HTML.  Of course, nothing is preventing you from going through the compilation step with the finished result, but this will be a massive time sink on your productivity. 


Probably the best answer, is to compile the templates on the server.  I didn’t go this route because frankly, it made for a really lousy tutorial.  It would basically take the same amount of code for JUST loading dynamic templates, as it would take for all the rest of the project combined!  This IMHO added a needless level of complexity to the tutorial and would only confuse people.  However, loading from the server is *IS* a better way to do it, and I was considering making an additional post for people interested in doing it that way.


Nicely, I don’t have to, someone else has done it for me! Smile


In this thread (about this thread… a real Conception moment here)  on the YUI forums, user Satyam has taken the ball and run with it!  So if you are interested in how you would implement templating on the server side, be sure to check it out.  The nice part about implementing it server side is, you still get your markup nicely separated from the rest of your code, however, you eliminate the asynchronous call to fetch the template from the server.  Thanks Satyam.


This, is the modifications he made to server.js to support loading of templates server side, while this is the modification he made to the view.  It is certainly more complex, but it is also a much cleaner implementation.


22. June 2012


In this tutorial we are now going to implement a web app end to end using YUI and hosted in Node.  It isn’t actually going to do anything much, but it will illustrate everything you need to create a client and server in JavaScript using YUI App and Node.  Over time we will add more bells and whistles, but there is actually everything you need here to create a full functioning web application.


After looking in to it a little closer, YUI is incredibly well documented, but actually implementing YUI App Framework in a real world environment there are gaps of information missing.  Generally all you are going to find is samples with a gigantic HTML files where all of the script is located in a single file, which obviously isn’t good form nor very maintainable.  Unfortunately, when you actually set about splitting your YUI App into separate files and templates, you are completely on your own!  In fact, this tutorial may in fact be the first one on the subject on the internet, I certainly couldn’t find one. 


That said, there are still some great resources I referred to over and over well figuring this stuff out.  First and foremost, was the App Framework link I posted earlier.  It effectively illustrates using models and views, just not how to organize them across files in a complex project.  The GitHub contributor app was another great sample, but it again, was effectively one giant HTML file.  Finally there is the application’s source code up on GitHub.  It is a full YUI App/NodeJS sample and is certainly worth reading, but as an example for people learning it is frankly a bit too clever.  Plus it renders templates out using Node, something I wanted to avoid.


Alright, lets do a quick overview of how program flow works, don’t worry, it’s actually a lot less complicated than it looks. It is initially over-engineered for what it ends up accomplishing.  However, in the end you basically have the bones of everything you need to create a larger more complex application and a code structure that will scale with your complexity.



This ( in the image to the left ) is the file hierarchy that we are about to create.  In our root directory are two files, server.js which is our primary NodeJS application, while index.html is the heart of our web application, and where the YUI object is created.


Additionally, in a folder named scripts we create a pair of directories models and views.  Models are essentially your applications data, while Views are used to display your data.  Finally within the views folder we have another folder templates which is where our handlebar templates reside.  If you have done any PHP or ASP coding, templates are probably familiar to you already.  Essentially they are used to dynamically insert data into HTML, it will make more sense shortly.


We are going to implement one model, person.js, which stores simple information about a Person, and one view person.View.js which is responsible for displaying the Person’s information in the browser, and does so using the person.Template.


Now lets actually take a look at how it all works, in the order it is executed.


First we need our Node based server, that is going to serve the HTML to the browser ( and do much much more in the future ).  Create a new file named server.js

var express = require('express'), server = express.createServer(); server.use('/scripts', express.static(__dirname + '/scripts')); server.get('/', function (req, res) { res.sendfile('index.html'); }); server.get('*', function (req, res) { res.redirect('/#' + req.url, 302); }); server.listen(process.env.PORT || 3000);


Essentially we are creating an express powered server.  The server.use() call enables our server to serve static ( non-dynamic ) files that are located in the /scripts folder and below.  This is where we serve all of our javascript and template files from, if we didn’t add this call, we would either need to manually map each file or you will get a 404 when you attempt to access one of these files on server.  Next set our server up to handle two particular requests.  If you request the root of the website ( / ), we return our index.html file, otherwise we redirect back all other requests back to the root with the url appended after a hash tag.  For more details, read this, although truth is we wont really make much use of it.  Finally we start our server to listen on port 3000 ( or process.env.PORT if hosted ). Amazingly enough, these 9 lines of code provide a full functioning if somewhat basic web server.  At this point, you can open a browser and browse to http://localhost:3000, well, that is, once you start your server.


Starting the server is as simple as running node server.js from your command line.  This assumes you have installed NodeJS and added it’s directory to your PATH environment variable, something I highly recommend you do.  Now that we have our working server, lets go about creating our root webpage index.html.

<!DOCTYPE html> <html> <head> <title>GameFromScratch example YUI Framework/NodeJS application</title> </head> <body> <script src=""></script> <script src="/scripts/models/person.js"></script> <script src="/scripts/views/person.View.js"></script> <script> YUI().use('app','personModel','personView', function (Y) { var app = new Y.App({ views: { personView: {type: 'PersonView'} } }); app.route('/', function () { var person = new Y.Person(); this.showView('personView',{model:person}); }); app.render().dispatch(); }); </script> </body> </html>


The most important line here is the yui seed call, where we pulling in the yui-min.js, at this point we have access to the YUI libraries.  Next we link in our model and view, we will see shortly.  Ideally you would move these to a separate config file at some point in the future as you add more and more scripts.  These three lines cause all of our javascripts to be included in the project.


The YUI().use call is the unique way YUI works, you pass in what parts of YUI library you want to access, and it creates an object with *JUST* that stuff included, in the for of the Y object.  In this case, we want the YUI App class ( and only it! ) from the YUI framework, as well as our two classes personModel and personView, which we will see in a bit more detail shortly.  If you use additional YUI functionality, you need to add them in the use() call.


We create our app and configure it to have a single view named personView of type PersonView.  Then we set up our first ( and only route ), for dealing with the URL /.  As you add more functionality you will add more routes.  In the event a user requests the web root, we create a person model.  Next we show the personView and pass it the person model we just created.  This is how you connect data and views together using the YUI app framework.  We then render our app and call dispatch(), which causes our app url to be routed ( which ultimately causes our person model and view to be created. If you aren’t used to Javascript and are used to programming languages that run top down, this might seem a bit alien to you at first.  Don’t worry, you get used to it eventually… mostly).


Now lets take a look at our model person.js

YUI.add('personModel',function(Y){ Y.Person = Y.Base.create('person', Y.Model, [],{ getName:function(){ return this.get('name'); } },{ ATTRS:{ name: { value: 'Mike' }, height: { value: 6 }, age: { value:35 } } } ); }, '0.0.1', { requires: ['model']});


Remember in index.html in the YUI.use() call where we specified personModel and personView, this is how we made those classes accessible.  By calling YUI.add() we add our class into the YUI namespace, so you can use YUI.use() to included them when needed, like we did in index.html.


Next we create our new class, by deriving from Y.Model using Y.Base.create(),  you can find more details here.  We declare a single function getName(), then a series of three attributes, name, height and age.  We set our version level to ‘0.0.1’ chosen completely at random.  When inside a YUI.add() call, we specify our YUI libraries as a array named requires instead of in the YUI.use call.  Otherwise, it works the same as a .use() call, creating a customized Y object consisting of just the classes you need.


Now lets take a look at the view, person.View.js


YUI.add('personView',function(Y){ Y.PersonView = Y.Base.create('personView', Y.View, [], { initializer:function(){ var that=this, request ='/scripts/views/templates/person.Template',{ on:{ complete:function(id,response){ var template = Y.Handlebars.compile(response.responseText); that.get('container').setHTML(template(that.get('model').getAttrs(['name','age','height']))); } } }); }, render:function(){ return this; } }); }, '0.0.1', { requires: ['view','io-base','personModel','handlebars']});


Like person.js, we use YUI.add() to add personView to YUI for availability elsewhere.  Again we used Y.Base.create(), this time to extend a Y.View.  The rest that follows is all pretty horrifically hacky, but sadly I couldn’t find a better way to do things that way I want. The first horrible hack is that:this, which is simply taking a copy of PersonView’s this pointer, as later during the callback, this will actually represent something completely different.  The next hack was dealing with including Handlebar templates, something no sites that I could findon the web illustrate, because they are using a single HTML file (which makes the task of including a template trivial).


The problem is, I wanted to load in a Handlebars template( we will see it in a moment ) in the client  and there are a few existing options, none of which I wanted to deal with.  One option is to create your template programmatically using JavaScript, which seemed even more hacky ( and IMHO, beats the entire point of templating in the first place! ).  You can also precompile your templates, which I will probably do later, but during development this just seemed like an annoyance. The site includes them on the server side using Node, something I wanted to avoid ( it’s a more complex process over all, and doesn’t lend itself well to a tutorial ).  So in the end, I loaded them using allows you to make asynchronous networking requests, which we use to read in our template file person.Template. provides a series of callbacks, of which we implement the complete function, read the results as our template, “compile” it using Y.Handlebars, we then “run” the template using template(), passing it the data it will populate itself with.  In our case, our name, age and height attributes from our personModel.  template() after executing contains our fully populated html, which we set to our views container using the setHTML() method.


Finally, lets take a look at person.Template, our simple Handlebars template:

<div align=right> <img src="" alt="GameFromScratch HTML5 RPG logo" /> </div> <p><hr /></p> <div> <h2>About {{name}}:</h2> <ul> <li>{{name}} is {{height}} feet tall and {{age}} years of age.</li> </ul> </div>


As you can see, Handlebar templates are pretty much just straight HTML files, with small variations to support templating.  As you can see, the values {{name}}, {{height}} and {{age}} are the values that are populated with data.  They will look at the data passed in during the template() call and attempt to find matching values.  This is a very basic example of what Handlebars can do, you can find more details here.


Now, if you haven’t done so, run your server using the command node server.js, if you have set node in your PATH.


Then, open a web browser and navigate to http://localhost:3000, and if all went well you should see:





Granted, not very exciting application, but what you are seeing here is a fully working client/server application with a model, view and templating .  There is one thing that I should point out at this point… in the traditional sense, this isn’t really an MVC application, there is no C(ontroller), or to a certain extent, you could look at the template as the view, and the view as the controller!  But don’t do that, it’s really quite confusing! Smile  Just know, we have accomplished the same goals, our data layer is reusable and testable, our view is disconnected from the logic and data.  Don’t worry, the benefits of all of this work will become clear as we progress, and certainly, once we start adding more complexity.


In the near future, we will turn it into a bit more of an application.



You can download the project source code here.


22. June 2012


Social games company Wooga have just open sourced their HTML5 game Pocket Island.  Youwooga-with-hosts can read the full Pocket Islands / Magic Land ( which used to be a Facebook App ) story right here.


If we are honest, after reading that I think they are putting too much blame at the feet of HTML and not enough at the feet of Facebook and themselves.  Additionally, in the few minutes I played, I saw a remarkably polished, pretty, *boring* game.  That said, I find that with most social games, so perhaps I am not the proper critic…




Anyways, the end result is a good one for the rest of us.  The source is now up on Github. I don’t know about you, but I always jump at seeing commercial source code when the opportunity presents itself.


The tool chain required does seem a bit… complicated though.  brew, ruby, gem, rake, markdown, gcc, node, lessc, jslint, spritoia and pngcrush.  That said, ive never done an ounce of Ruby programming, so perhaps this is par for the course in ruby development.


Good on Wooga for sharing.  Perhaps nicest of all, the art assets have all been included as well ( under the Creative Commons non-Commercial license ).


AppGameKit Studio

See More Tutorials on!

Month List