Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
31. August 2015


Today Unreal announced the release of version 4.9 of the popular Unreal Engine.


Unreal always have fairly massive release notes, so here is the short hand version:

  • Enhanced Support for Mobile Devices
  • Dynamic Character Shadows for Mobile
  • Dynamic Point Lights for Mobile
  • Decals on Mobile
  • Major VR Updates
  • New VR Motion Controller Support
  • Experimental Direct X 12 Support
  • Full Scene Particle Collision with Mesh Distance Fields
  • Hierachical LOD Fast Preview and Clustering
  • Arch VIS Character Controls
  • Widget Depth ordering
  • Area Shadows (For Stationary Lights)
  • Ambient Occlusion Material Mask
  • Mesh Distance Field Materials
  • Improved Distance Field Ambient Occlusion
  • Content Browser Advanced Search
  • Collection Improvements
  • Plugin Creation Wizard
  • Enhanced Curve Editor
  • Multiple Return Nodes in Blueprints
  • Construct Custom Objects in Blueprints
  • Blueprint Class Defaults
  • Blueprint Communication
  • Optimized Math Expression
  • Blueprint Asset IDS
  • Montage Element Timing Interface
  • Non-Linear Animations Blending
  • Bone Driven Animation Controllers
  • Animation Transition Rules
  • Animation Curve Evaluation Change
  • Animation Asset Metadata Support
  • Sound Quality Levels
  • Custom Audio Attenuation Curves
  • Actor Tick Intervals
  • Actor Encroachment Detection
  • Post Process Blending
  • Runtime Asset Cache
  • Volume Decals (Experimental Only)
  • UE4 Documentation Tags, Version and Skill Level
  • Updated UE4 Documentation
  • Async Real-Time Audio Decompression
  • Shared Resources for Feature Packs and Templates
  • Improved HTML5 (Easy Setup, Amazon S3 Support, Networking)


This only represents the highlighted features too, be sure to check the full release notes for more details.


28. August 2015


Hello All,


Just a quick note on what’s coming up at  First up, the end of summer is fast approaching and I think it’s time for a road trip vacation.  Last year I took a similar trip and it rained every single day, so this year I’ve learned from my mistake and I am bringing along a laptop and will be doing a little work while lounging by the pool ( or more likely locked inside watching the rain ).  This isn’t exactly a hardship, as I enjoy what I do after all.


Since it is a vacation however, I am going to be taking a somewhat different approach to what I am working on.  First off, there will be no videos produced, since I wont be bringing the proper equipment with me.  Second, traditional series will be on hold until I get back, so don’t expect any updates to existing tutorial series for at least a week, although I should get an in progress “Closer Look at” post out before I depart or shortly thereafter.


Instead I am intending to do exploratory work on a pet project I’ve been kicking around in the back of my head…  There is one topic that is incredibly underserved when it comes to books and tutorials.  One that is incredibly popular, but due to it’s massive nature, most people don’t really get into it for one reason or another.  Computer Roleplaying Games.


I have considered doing an RPG tutorial ( CRPG I suppose) for ages.  It was games like Ultima, Bards Tale, Might and Magic, Wizardry, Autoduel, Wasteland, etc… that truly got me hooked on gaming.  It’s the genre of game I personally am also the most interested in developing.  There are a couple problems about doing a tutorial series about RPGs.


First off, I will have to learn a ton to actually cover the subject.  I have never created an RPG before, so this is obviously going to be one of those “learning as I go” projects.  This isn’t really a huge concern to me to be honest.  It’s not actually a hugely complicated project, just a ton of tiny intricate moving pieces that need to be organized.


Second, they are massive.  There are so many subjects to cover and to be frank, a lot of what makes a roleplaying game work is actually the tooling behind it.  World editors, scripting systems, world state, databases, this kind of stuff.  You quickly find yourself creating your own game engine, scripting language, adhoc database, etc…  and quite frankly, the value of doing this is minimal, and the value of doing it in tutorial form even less.  Not many of you are going to want to use my poorly rolled engine ( I’m a fervent believe in the Make Games not Engines ethos… although I think making tools is a brilliant use of time ).


On the other hand, if I use an existing engine, my demographic is going to be small as well.  Right now I think the most popular engine in terms of potential readers is probably Unity.  So the series that might appeal to the most users is “Creating an RPG in Unity”.  This has many problems.  First is easily explained with a handy Venn diagram.



The Dark Blue portion is the most engaged audience, this represents the portion of the community that use Unity and are interested in RPGs and read GameFromScratch.  As you can also tell, it’s the smallest portion, although this is generally the way these diagrams work.  There are the two slightly lighter blue areas, and those represent people that have 2/3rd interest in the project.


Simply put, by picking a game engine, it narrows down the potential audience substantially.  On the other hand, as I said earlier, not using an engine is a very bad choice.  Also to be completely honest, without a serious amount of modification ( which would require a source license ), Unity doesn’t actually seem like a great choice for an RPG, at least for small teams.  Of course some exceptional games have been made using Unity, such as Wastelands 2, Pillars of Eternity and Shadowrun Returns, but they all had huge teams and most likely had source licenses.


It’s this limited audience that has always kept me away from the idea; and a lack of time has kept me from simply working on my own game.  This is one of the challenges of running, I need to work on either a broad variety of topics, or on topics of interest to a large enough segment of the community.  This keeps me from spending a ton of time developing my own game.  This isn’t really a big deal, I actually enjoy teaching more than I enjoy development these days.


I hit upon an idea however that I think might be useful to the greatest number of people.  To appeal to enough readers to justify the time spent, to be effective enough you could actually use the results, to be productive enough that you could actually finish a game and be interesting enough that I would actually enjoy working on it.  That’s a lot of enoughs eh?


To start out making an RPG engine of sorts, you would need a number of moving parts to start from.

  • a game engine/collection of libraries to handle the technical bits.  Rendering, input, that kind of stuff
  • a scene graph, world storage format.  Basically the data structure in memory and on disk that your game will reside in.  This could be part of the engine you chose, but for an RPG, you will probably want more control or possibly to decouple it from the engine for a variety of reasons.
  • a world editor.  This one is big.  HUGE in fact.  My thought at first was to create if from scratch, but that could literally take a single developer years.  More on this point later, as again, it’s a big one.
  • RPG logic.  There’s all kinds of things that are somewhat unique to RPG games, from massive state driven game levels, time management, to simple random generators, dialog trees, class abilities, game entities, etc.  Basically the common logic that goes into an RPG that makes an RPG and RPG, regardless to if its 2D/2.5D or 3D, sci/fi or high fantasy.
  • misc tools…  conversation / internationalization tools, sprite effect tools, world item asset creation/database, etc.  Some of these could be part of the engine, some could be part of the editor, some could be stand alone and all may depend on the RPG logic layer.  File this section under miscellaneous/everything I forgot.

There are many different choices, but all of have their strengths and weaknesses.


An immediate thought would be LibGDX.  From the game engine side of things, it certainly ticks almost all of the boxes.  There are three big downsides to this choice however.  First, I run into the Unity factor again… if I go with LibGDX, I lose all readers interest that don’t want to use LibGDX or Java.   Second, there is a lack of out of the box scripting support.  I wish there was Lua ( or jLua, or whatever the Java equivalent is ) support out of the box.  I think it would be easy enough to add in support for a scripting language for the LJGWL target, but once you start getting into Android and then the RoboVM trickery then we are talking a layer of black magic I currently do not possess.  It may not actually prove to be that difficult, but this is a portion of LibGDX that I’ve always just let others wrap their brains around.  Finally, and one of the big ones…  no level tool, at least not yet.  There is Overlap2D, but it’s just not there for me yet.  Plus frankly, trying to extend it with the ECS and MVC design its chosen… this would be nightmarish.


Those end up being the big two sticking points for me, the availability of a scripting language, but one that has to be optional… and a solid base to build a level editor upon.


In terms of level editor, one of the most immediately obvious answers is TileD.  I like Tiled… I actually looked at the source a number of times considering doing exactly this very thing… and I decided it would be WAYYYYYY too much work.  Tiled’s code is nice and clean Qt C++, that’s not really the issue… the issue is the pure amount of work you would have to do to extend it.  I believe they are refactoring towards extensibility, but this is a WIP.


Of course Unreal and Unity can be turned into level editors, but this will start feeling like a hack right away, and without Unity source you are quickly going to be stuck in the Unity design model, which for an RPG, would lead to an organizational mess almost right away.  With Unreal you get the source, but realistically you aren’t going to want to extend the editor, at least not with a fairly large developer team.  Plus that API is changing A LOT, so expect huge breaks every time there is a new release.  Pretty much ever major game shipped on one of these engines pretty much locks to a version and sticks with it…


You could also extend a content creation platform too… this is actually a pretty popular choice.  You could extend an app like Blender, Maya or Max to use as your authoring environment, but this again is a highly specialized development and of interest to a very small segment of the community.  Also it can very easily get hackish fast.


Of course, I wouldn’t have shared this massive wall of text unless I thought I had an idea now would I?  Well, it’s that idea I am going to flesh out during my vacation, decide if it’s viable, both from a tech perspective and a time perspective.


So… what are my thoughts?


Godot.  Or perhaps, sorta Godot.


Godot ships with a Unity-like 2d/3d editor, and a game engine capable of providing the technical bits in a cross platform manner.


More importantly, Godot editor is mature, 2D/3D friendly, scriptable and most importantly, modular and extensible.  In fact, the entire GDScript language is implemented as an extension module for Godot.  Therefore it should be possible to create RPG tooling ( creature editors, pathing, item inventory, conversation tools ) that can plug into Godot, but not require users to build the editor from scratch.  Basically it would enable me to create an RPG world editor using Godot, that enabled people that arent even interested in using Godot game engine, without having to fork Godot itself.  Of course you could use Godot the editor and Godot the engine to create your game.  However you could potentially use Godot the editor and say… LibGDX, or Phaser or SFML, Ogre, jMonkeyEngine, Paradox, Mono, whatever…. to implement your engine.


Obviously that just covers the editor/engine portion of the scenario… this leaves two very big missing pieces.


RPGLib.  Right now I am thinking it would be smart to provide generic RPG-esque functionality as a C++ library.  This would be usable then by the vast majority of programmers, regardless to the language they want to work in.  ideally I will use 3rd party libraries as much as possible to offload as much work as I can.  Think of this layer like the run-time that provides generic RPG-esque services to the underlying game ( the Godot editor would be a consumer of services provided by this layer ).  This layer wouldn’t care what engine you are running in, if your game is 2D, 2.5D or 3D.  It would be use to provide things like persistence, algorithms like pathfinding, a database of sorts, etc.  In theory you should be able to slot it in to a variety of games and build upon it. 


WorldFormat.  This one is tricky and is going to require a fair bit of brain juice…  basically I want to decouple the world format from the game engine.  In fact I want to decouple the world format from the game, but I dont think this is even close to possible.  Basically a world is a database, graph or tree of entities in memory.  The other side of this coin is, it also needs to be saveable to and loadable from disk.  Think about how the Tiled editor has the TMX format and all of the various game engines capable of loading it?  This would be like that, but with a great deal more database like behavior.  This would enable you to write a loader/importer for your favourite game engine of choice, and make use of Godot as your world editor of choice, but load it in whatever game engine you desired.  Of course this loader would be responsible for populating your game engines scene graph…


Think roughly this…



Now one major downside is my C++ is meh at best and extremely rusty.  Then again, only way to brush off the rust is practice, no?


The end goal is to keep each layer dependent only on the layer below it, and have zero dependencies back to the Godot editor layer.  This means a user could take and make use of just the services layer.  Or the Game Format + Services layer.  Or simply the output from the level editor and ignore the rest.  Or they could use the provided loader, the Godot editor, the RPG services, etc… and have a turnkey solution to build an RPG upon.



…anyways, that’s the thought bouncing around my head right now.  On my vacation I plan to tackle two key points.  First, I want to see if the Godot editor is in fact as easy to extend as I think it is.  Second I am going to start defining as best as I can what functionality goes into what layer.  One final thing to keep in mind out of all of this… I am not intending to reinvent the wheel.  An RPG for example requires animated sprites or models, playing sound effects and music, etc…  these are NOT the responsibility of any of this, that’s left for the game engine or game implementer to handle.  The closest this comes who thing comes to any of those services is perhaps providing resources via the Game Engine Specific loader.


Of course, I’d be interesting in know if you guess out there would be interested in a series like this?  It would take a very long time, as I will be continuing to generate the kind of content you would expect from GameFromScratch.  It would however be a fairly good sink of my time, so I want to gauge the level of interest before a dump a ton of time into this.  Also, do you see any glaring flaws in my early concept so far… and recommendations or changes you would make?


Or frankly, does this all look like the ramblings of a mad man desperately in need of a vacation? Smile

Programming News General Design

26. August 2015


… in beta form, that is.  It was announced a while back that Unity was working on a Linux version of their editor.  It appears it has finally arrived, according to this blog post, replicated below:


Hello again, lovely people!
Last month, I wrote a blog post detailing our plans for Unity on Linux.  Well, I’m back again to tell you the big day has come; today we’re releasing an experimental build of Unity for Linux!
An Experimental Build

Today’s build is what we call an experimental build; future support is not yet guaranteed.  Your adoption and feedback will help us determine if this is something we can sustain alongside our Mac and Windows builds.

Today’s build is based off Unity 5.1.0f3 and comes with the ability to export to the following runtimes:

  • Linux, Mac, Windows Standalone
  • WebGL
  • WebPlayer
  • Android
  • Tizen
  • SamsungTV
System Requirements
  • 64-bit Ubuntu 12.04 or newer (just like our player, the editor will run on most ‘modern’ 64-bit Linux distributions, but official support is only provided for 64-bit Ubuntu 12.04 or newer)
  • Modern Nvidia, AMD, or Intel graphics card with vendor-supported graphics drivers
Feedback and Issues

We’ve created a new section of the forums for you to provide feedback and report issues.  That’s the primary place where we’ll be communicating with our users who are using the Linux build, so be sure to check it out.  Crashes of the editor will pop up the bug reporter, which we encourage you to use in that case (because we’ll get the stacktrace).

That’s all for now. You can find the downloads here:

Read more about the release notes and known issues in our forum post.

Much love from Unity


I know there are a lot of Linux devs out there that have been calling for a Linux version for quite some time. I am curious to see how popular it will actually be though. In the end, many of the people that embrace Linux as opposed to MacOS, are also the type that embrace open source. Why then would this demographic gravitate to Unity, when open source friendly options like Godot exist? I don't personally have any Linux installs at the moment, so I wont be testing this new release.


21. August 2015

Today marks the official release of jMonkeyEngine 3.1 alpha. Generally I wouldn't make a news post over a minor alpha release but a) jme has been pretty quite lately b) I'm currently looking at this engine right now c) it's a pretty massive release.

In addition to underlying changes like a move to github, transition from ant to gradle build systems and implementation of a commenting system that isnt from the 90s, there are some pretty huge new features, such as iOS support, FBX importing, VR support, render optimizations and much more.


The full release notes follow:


At long last, we have our first alpha release for the jMonkeyEngine 3.1 SDK.

Go get it on GitHub and start breaking things.

Not only does this release mark the introduction of some absolutely game-changing features (or shall we say, abbreviations: iOS, FBX, VR!); it also marks a significant step forward in jME’s underlying infrastructure. In the following weeks, we will explain each and every one of these changes in depth.

All the same bits, structured differently

  • First, we switched from using Google Code (SVN) to GitHub (Git) for
    our source code repository.
  • And then, as if that wasn’t enough, we went from using ANT
    for our build system to using Gradle.
  • We also migrated our forum to the ever more awesome Discourse, which was followed by a series of website updates, with more to come.

These structural changes will allow us to do our work more effectively, and with the combined power of GitHub and Discourse, we’re already seeing a big uptake in contributions and overall user participation.

Unified Renderer Architecture

Previously, there would be a Renderer implementation for each platform that jME3 supported, but all of these platforms supported OpenGL, so in the end, this led to a lot of code duplication. Each time we wanted to add a new renderer feature, all existing renderer implementations had to be modified in the same way.

The new unified renderer architecture means there’s only 1 Renderer implementation, “GLRenderer”, which then calls into GL interfaces implemented by each back-end – this is much easier to maintain. It means easier modification of renderer internals, including performance improvements, as well as the ability to add really advanced features to the renderer that wasn’t possible before. As a consequence, the OpenGL 1 renderer is now out, nobody will ever miss it and (probably) nobody used it for anything. There were some other changes around the rendering pipeline, reduce useless work and improve performance.

OpenGL 3 Core Profile Support

This is a significant improvement especially on Mac OS X and Linux where using the Core Profile actually allows more features to be used than otherwise. Do note that many jME3 shaders don’t support GLSL 1.5 which is required on some platforms when using OpenGL Core Profile – this is being worked on …

Geometry / Tesselation Shader Support

Added support for specifying geometry and tessellation shaders in the material definition. Note that this requires hardware capable of running such shaders. This feature is not used in the engine itself for any capability.

Scene Graph Optimizations

Previously, the engine would need to recurse into the scene graph 3 times every frame, even if nothing was changed! This has been improved so only the branches of the scene graph that require updating or rendering are actually walked into. This equals big performance boost for mostly static and large scenes. The only kind of scenes that don’t benefit from this are scenes where all objects and lights are constantly moving and the entire scene is visible in the camera the whole time. Those kinds of scenes are very rare!

In addition, hardware skinning is now enabled by default, which means a big speed boost when there are many animated models on screen.

Lighting Boost

Remy “nehon” already made a post about this which you can read here. With both single pass lighting and light culling you can now expect big performance improvements in large scenes with many lights. – When rendering shadows for lights, only casters that are inside the light’s area of influence are rendered.

FBX Importer (Beta!)

There’s a beta quality FBX importer currently in development. Unfortunately skeletal animation is not supported yet, but once it is finished, it should replace the semi-functional OgreXML support and hopefully be on par with the .blend importer.

Geometry Instancing

If you want to render a certain (complex) model many times in different places. E.g. a forest or asteroid field, you can use InstancedNode (requires OpenGL3 and higher support!)

Rewritten Audio Streaming

If you were using audio streams before, you might have noticed that they have quite a lot of limitations. They cannot be looped, reset, or stopped without the audio stream becoming useless. The new changes mean you can now stop, loop, or reset audio streams with ease. Also, updates about audio finishing playing now occur every frame instead of every 50 milliseconds (e.g. if you were relying on it for any events & such)

Further, there’s a new capability to determine current playback position of an audio source. Can be used to synchronize events or video to an audio stream.

Networking Improvements

HostedServices: Essentially like AppStates, but independent of jME3 Application infrastructure.

Gamma-correct lighting and high dynamic range rendering

Gamma-correct lighting – basically means lighting looks better or more realistic, or both. Oh, and if you’re planning on using this, you better make sure its always on because your scene will look different depending on if its on or off. While at it, you can also use the new tonemap filter for HDR rendering. The tonemap algorithm is based on a filmic curve from Uncharted 2.

Profiling Frame Times

With the app profiler state, you can see how long each part of a frame takes, e.g. rendering or updates, thus allowing you to detect stuttering parts in the game and optimize them.

iOS Improvements

  • Now iOS support is mostly stable (but still behind Android support). More testing is needed.
  • Texture loading issue fixed.
  • Audio support now enabled.

Android Bugfixes & Improvements

  • Texture decoding is now handled by C++ code so loading time is now much shorter. This also means the terrain alphamap issue is fixed. Previously you had to flip the alpha channel to use terrain on Android, this is no longer required.
  • OGG/Vorbis audio decoding is now handled by C++ code. This allows using the native OpenAL Soft audio library to handle audio instead of the Android built-in MediaPlayer, hence 3D audio, doppler effects, and reverb is now supported.
  • Support for Android Fragments (on Android 4.0+)
  • Added support for joysticks. For example, you can connect your Xbox 360 controller to your Android tablet and it will show up as an actual joystick in jME.

Blender Importer

  • Improved support for models animated with IK (inverse kinematics)
  • Support for loading linked .blend files

SDK Editor Improvements


  • Enhanced shader node editor with many issues fixed.
  • 3D Scale / Rotate Tool.
  • New “DarkMonkey” theme which matches the forum theme (you have to enable it manually under the Look and Feel settings)

Bullet Physics

  • Added capability to change number of solver iterations – aka “physics accuracy”.
  • Added support native sweep test (previously was unimplemented)
  • Fixes to native ray test (previously was broken / crashing)
  • Allow 3D vector linear and angular factor instead of just a scalar factor

Misc Engine

  • Print out current build branch / tag / revision / hash in log

Misc Bugfixes

  • Fix inconsistent mouse coordinate origin on AWT panels
  • Fix translucent bucket on AWT panels
  • Fix using texture arrays with GPU compressed textures
  • Fix building engine on JDK8 and latest Android NDK
  • Fix point sprites on Android
  • Fix post-processing / FBO on Android
  • Fix running jME3 in the Android emulator
  • Fix shadow effect Z fade feature
  • Fix compilation issues on Java 1.8
  • Fix broken Material.preload() method
  • Fix water filter not working on GPUs without OpenGL 3 support
  • Fix crashing filter multisample support on OpenGL 3.2 contexts
  • Fix bounding volume not updated when geometry inside BatchNode is modified
  • Fix incorrect flipping of 2×2 DXT5 images
  • Fix audio source reverb being enabled by default
  • Fix batching with vertex colored meshes
  • And a trillion other bug fixes I forgot to mention, so you better start using jME 3.1 today!



9. August 2015



EDIT:  The tutorial series announced below is now live and available here.


Hello All, just a quick update on an upcoming tutorial series here on   I have recently been looking at the Paradox game engine, cumulating in a Closer Look at Paradox3D.


I rather enjoyed my time with the engine, but I will say outright that the documentation is in pretty rough shape.  There are two ways to look at this.  For new users its a rough go and makes Paradox inaccessible.  For a tutorial writer however, it’s an opportunity, as the worse the documentation the more you need good tutorials! Winking smile


There is one major challenge here… the documentation is spotty for a reason.  The API is under active development and they are making breaking changes as they go.  This certainly presents a challenge.  Part of it is simply the nature of the beast, but I am going to address it in a couple ways.


First I am going to keep each tutorial quite small, so if it breaks it only breaks a small portion of the over all tutorial.  I am going to be doing both text and video tutorials.  It might be possible to update text tutorials as things break, but obviously this isn’t possible with the videos.  Second, I am going to mark the version I use for each tutorial.  I will keep with the most current release as I update the series, so you can quickly see what version the tutorial works with if things have in fact broken.  Quite often the comments section can capture and work around breaking API changes.  Finally I am going to keep the explanation in each tutorial to a minimum.  This will help keep tutorials small and will also help with the fact in many cases I am guessing at the best way to implement something.


I intend to cover as much as possible over the course of the series.  I am going to take a recipe type approach.  This is how you draw a sprite sheet, this is how you add animation to a model, this is how you play an audio file, etc.  Please let me know what you want to see covered.  Expect the first new tutorial early this week.


GFS On YouTube

See More Tutorials on!

Month List