Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
15. November 2016


First off, I apologize for the pun, I felt obligated to make it.  In a nutshell, Godot 2.2 won’t be happening, so stop waiting for it.  Don’t worry though, it’s for a good reason.  They just posted a status update on Godot game engine development and they have decided to skip the planned Godot 2.2 release and instead focus on Godot 3.0 development. 

In a nutshell, Godot 3.0 is going to have some pretty major low level changes (including new renderers) that would result in a great deal of the features expected as part of 2.2 to require reworking.  So instead these features will be delayed until after the release of 3.0.  So, what features were included in 2.2?  The marque features were C# support, Visual Scripting and the rudiments of networking support.  Don’t worry however, these features are still coming, simply delayed.

The main motivation for changing the roadmap is to release Godot 3.0 sooner. Within the Godot development team, our priority is always to work on what the community needs most at a given point in time - for the past year and a half, the focus has been on greatly improving the usability of the editor, as well as enhancing the 2D tools. Nowadays, Godot is a great engine for making 2D games, and the interest of the growing community is starting to move on to 3D, with corresponding needs for improvements.

For more than a year, Godot 3.0 has been promised to our users as the version that will bring a new state-of-the-art 3D renderer (albeit compatible with a wide range of graphics drivers, hence our choice for GLES 3.0 instead of Vulkan for the time being), and solve many issues and requests users have formulated regarding the current 3D renderer in Godot 2.1.

By skipping the 2.2 release, we allow ourselves (and mostly Juan, our renderer expert) to avoid a lengthy bug fixing and stabilization period on 2.x features. We are therefore aiming for a release of Godot 3.0 in early 2017, which would not have been possible if we had to focus on 2.2 right now.


Frankly I agree with this approach.  Most of the features of 2.2 are “nice to have”, while the functionality of 3.0 is more in the “need to have” category.  Fortunately there is some good news as well.  We should expect the 3.0 release to happen faster.  Lead developer Juan Linietsky has been hired full time for 6 months to work directly on Godot thanks to a Mozilla grant:

Last but not least, you might know that we were awarded a hefty sum by Mozilla as part of its MOSS Mission Partners program. This award was aimed at helping us improve Godot's HTML5 export by implementing the brand new WebGL 2.0 and WebAssembly technologies. As the former is basically the same API as GLES 3.0, it's best for us to work on both of them at the same time, so that we can ensure that GLES 3.0 / GL 3.3 and WebGL 2.0 will behave similarly.

Therefore, we decided, together with our non-profit home Software Freedom Conservancy to hire Juan Linietsky full-time for 6 months to work on the objectives funded by the MOSS award. This encompasses in particular the new renderer that will be done for 3.0, and extensive work on the HTML5 platform that might be done partly for 3.0 and in full for 3.1. As Juan is the project leader and our more prolific contributor, this will enable Godot to grow even faster than it has over the last couple of years.


Considering how much this guy has managed to accomplish when *not* dedicated to development, just imagine what he can do focused full time?


One last piece of bad but somewhat expected information in this update… Godot 3.0 wont be perfectly backward compatible with Godot 2.x and earlier.  I’ve always been pretty impressed with how well they’ve managed to support backward compatibility till this point.  Some of the underlying changes are unfortunately going to break compatibility.  Thankfully they will be providing tools to mitigate this as much as possible:

The new 3D renderer is the opportunity to do some important refactoring of Godot's internals. We also want to use this opportunity to revamp, homogenize and enhance some parts of the API, to make Godot 3.0 a solid base for the further development of the engine and of Godot games.

What does this mean for users? Moving from Godot 2.x to Godot 3.0 will require porting the existing projects to take into account the API changes and the new way resources will be setup in 3.0.

We will provide tools to help with the conversion as well as extensive documentation, so do not worry. You can continue (or start) using Godot 2.x already, as most of the API and workflow will still stay the same, so 98% of what you are doing in 2.x will still be relevant in 3.0.


If you were currently waiting on C# or Visual scripting support, this news might be a bit of a let down.  Over all though, I think everything announced makes a great deal of sense.

GameDev News

1. November 2016


The Godot Game Engine has seen a slew of recent updates and is heavily under development in anticipation of Godot 3.0.  In the recent 2.1 update the Asset Library functionality was added (click here for details of the Godot 2.1 release), which is the Godot equivalent of the Unity or Unreal Engine asset stores.  Yesterday they announced the beta release of the web front end for browsing assets in the asset library using your web browser.



The announcement also documents the process of submitting your own asset to the library.


Another recent announcement from the Godot team was an update on the renderer changes for Godot 3.0.  The process is split across 3 milestones, and milestone 1 has just been reached, including:

Done for Milestone #1 (October 2016):
  • Make Godot compile against GLES 3.
  • Refactor the Image class to include modern data types.
  • Refactor the texture API to include more modern texture compression formats.
  • Refactor the rendering API to make it easier to understand (and contribute to!).
  • Write a more flexible, GLES 3 GLSL compatible shader language.
  • Write a more efficient Mesh format, which allows faster loading/saving.
  • Optimize scene rendering to use less function calls.
  • Make rendering always happen in Linear colorspace.
  • Investigate Physically Based Rendering (PBR), using GGX and alternatives.
  • Investigate cubemap filtering.
  • Create a new FixedMaterial that reflects PBR capabilities.
  • Implement PBR.
  • Convert gizmos to use the new FixedMaterial.
  • Add Lighting using PBR.
  • Investigate a ShadowAtlas allocation strategy.


Already there are some pretty powerful features in there and there are two more milestones to go.  There is a full description of the other milestones in the blog post as well as complete descriptions (and justifications) for the tasks completed in milestone one.


I have to say, the Godot engine is improving at a shockingly awesome rate these days.  If you are new to Godot, do be sure to jump into the GameFromScratch tutorial series.

GameDev News

23. September 2016


Welcome back to our ongoing Godot tutorial series.  You may notice a pretty major change in the way Godot looks from previous tutorials.  This is because this tutorial jumps forward to Godot 2.1 which has an updated look and feel.  Don’t worry, the process is virtually identical regardless to which version of Godot you were running.  Today we are going to look at implementing 2D lights in your Godot game.  This will involve creating Godot light nodes, as well as occluders to prevent light.  We will also look at light masking, which is useful for implementing fog of war type effects. 


As always there is a video version of this tutorial available here.


First let’s set up a simple scene we can test our lighting on.  I simple create the following hierarchy using the default Godot icon sprite.



Then scale it up like so:



Now let’s add a Light2D as a Child to our Root node:



Notice the exclamation mark?



This is because we need to specify a texture to use as the light source.  I created the following image in (process is shown in the video if you want to see how it was made):



Notice that this image is a grayscale PNG file with an alpha channel.  Where there are no pixels at all, there will be no light shown.  Where it is whitest, the light will be most intense, while the darker it gets the less intense the light.  Save this image or create your own and add it to your project.  Now we set it as the texture source for our light.



Now if you move your Light2D node around the scene, you will see how it interacts with other objects in the scene:



There are a number of properties you can set for the light, such as the Energy (intensity) Color (tint) and Scale (size):



Notice also Mode.  We will come back to that in a minute.  Now sometimes you aren’t going to want all lights affecting all objects in the scene.  Thankfully there is a setting for that.  Notice in the range category there is a setting called Item Mask:



This controls what layer of items this light will interact with (there is also a setting for shadows as well).  Now if you switch over to your Sprite, under canvas item you will notice a Light Mask setting:



So long as the light and CanvasItem use the same masking channel, the light will apply to that node.  If they don’t use the same channel, the light will have no effect.  This can lower processing costs and enables you to exempt parts of your seen from being lit if so desired.


Now sometimes you want to have light actively blocked in your scene.  For example you might have a wall that should cast a shadow.  This is easy to implement in Godot using Occuluders.  This is simply a polygon area where the proverbial light don’t shine.  Let’s set one up around the nose of our Godot sprite.  Add a LightOccluder2D to your Sprite.



Your scene hierarchy should now look like:



With the LightOcculder2D node selected in the Scene the following icon should be available in the 2D view:



Click the pencil.  Now we want to draw our occlusion polygon, like so:



Now notice the way the light interacts with the scene...



Now remember earlier on the Mode value of our Light2D node?



Now we are going to switch it over to “Mask” and show a powerful capability.  This can be used to create localized lights or to implement fog of war effects.  Just like before we need a texture to represent our light source, but this time we want the pixel values reversed, so I created the following image:



In this case the black area will receive no light, while the whitest area will contain the most light.  Here is the end result:



By scaling the light out to the full size of the screen, you can easily attach such a light to the character sprite to easily implement a fog of war type approach.


The Video


9. August 2016


After a few release candidates, Godot Engine just released version 2.1.  If you’ve never heard of the Godot Engine, it’s a popular MIT licensed open sourced 2D/3D game engine, we previously featured it in the Closer Look series in addition to a pretty massive tutorial series, should you wish to learn more.  Godot 2.1 focused heavily on usability issues, the kind of things that make a developers life smoother on a daily basis.Godot



Features of Godot Engine 2.1 include:

    • new asset sharing platform
    • new plugin api
    • dynamic font support
    • fully internationalized editor UI
    • editor visual customization
    • user customizable key bindings
    • live script reloading
    • profiler and frame profilers
    • remote scene inspector
    • HIDPI/Retina display support
    • drag and drop support
    • contextual menus
    • script editor improvements
    • improved asset pipeline
    • improved resource preview and thumbnails
    • new animated sprite features

You can read a great deal more about these new features in the release post.


This feature takes a hands-on look at the new functionality available in Godot 2.1:

GameDev News

7. August 2016


I’ve been a huge fan of the open source Godot Engine for a very long time, in fact I’ve done an in-depth tutorial series available here.  Godot has seen a number of improvements in the upcoming 2.1 release, but the recently added Visual Scripting interface is probably the biggest new addition.  In this post we are going to look at this new functionality.  A couple of warnings to start.  First, as of writing ( 8/7/2016 ), Visual Scripting is only available in the development branch.  So you will have to build Godot engine from scratch from the Github repository.  Second, this functionality is extremely early and not fully developed.  There is currently no debugger or profiler support and expect bugs.  Heck, I’m having trouble even running scripts at this point, but it’s probably user error on my end.  You have been warned!


I also did a video showing hands on with the new Godot Visual Scripting language.  It is available embedded below.


Creating a Visual Script


Creating a script is a simple process, basically identical to creating a GDScript.  Add a new script as usual.



Now in the Create Node Script, pull down language and select VisualScript.  VisualScript’s have a .vs extension in Godot.



Creating Visual Scripts


Visual Scripts are basically a flow chart of nodes, like so:




You start by implementing a function.  All of the usual GDScript functions are here:



This enables you to handle various events within your games lifecycle.  This will create a new node on the graph that acts as an entry point:



You notice in this example there is a parameter “event” here.  With it selected you can see it’s values in Inspector:



You will notice on the right side of the Function node there is an arrow and blue dot.  The arrow is for program flow, while the dot represents output.  Other nodes can have various inputs, which are also color coded.  We can now add other nodes to our graph, from the Available Nodes section.


There is basically a one to one ratio of nodes and functions available in GDScript.  Add a new Node from the InputEvent section for Is Pressed, simply drag and drop from the Available Nodes to the drawing surface.  Now we connect the two nodes together.



You will notice the newly created is_pressed test has another line out to continue the process as well as a bool output (notice the different color coding).  We could not continue our code by branching to a conditional like so:



Of course, this is VERY early, but it does give you an idea of how Visual Scripting will work in Godot.


The Video


AppGameKit Studio

See More Tutorials on!

Month List