Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
16. April 2016


Goo Create is a WebGL based game engine with a full editing environment. They just released an update that enables live editing, which enables you to change the values and code of your game while the game is running, enabling a fast development, testing and debugging cycle.  You can see Live editing in action in this video:

There are several other new features in this update including a new JSON data type enabling you to drop in and use JSON files in your project.  Rigid Body physic objects can now have their position or rotation frozen along any axis, useful for constraining objects in a 2D game.  You can now duplicate the states of existing objects in the behavior editor.  There is now a preview of the selected camera, making camera placement easier, they also added fixedUpdate and lateUpdate callbacks to script objects enabling finer control over the lifecycle of your scripts.

There were also several fixes and improvements:

Other improvements & engine updates

  • Exported ZIP files are now more conveniently named, for example
  • Webpage export now includes the engine JS files.
  • The engine now uses commonjs modules instead of AMD. This way you can use it “natively” in Node.js for your multiplayer games, or use it with modern web development tools like webpack. Just npm install goojs!
  • Tween was removed from the engine. If you still want to use Tween, use this library or update your script to use the new Easing class instead.
  • If you were injecting APIs on the entity instances from components, and the method already was taken, now you get an error instead of a warning.
  • The transform components now update lazily. The new way of using them is via entity.transformComponent.setTranslation(),.getTranslation(), .getWorldTranslation(), etc. See the ScriptingTransforms tutorial or the TransformComponent docs.
  • We removed doppler factor support because it’s being dropped from the WebAudio API.
  • Added a fixed update loop, mainly for physics but also for other things that need frame rate independece.
  • ctx.playTime is now updated before running update()

You can read more about this release in this blog post.

GameDev News ,

15. April 2016


The title pretty much says it all. While it is an unfortunate announcement, it’s not an all together shocking one.  For those who have never heard of it, RoboVM is a technology that allowed you to run Java applications on iOS devices.  Of perhaps most importance to game developers, it was the technology that enabled LibGDX applications to work on devices like the iPad, iPhone and Apple TV.

So how did this happen?  Well, it’s a bit of a story...

Back in May of 2013 LibGDX moved from (ironically enough) Xamarin to RoboVM to support iOS.  At this time RoboVM was open source and simply worked better than Xamarin at the task.  Everything was going well until October of 2015 when RoboVM was suddenly purchased by Xamarin.  Leading up to this point, the open source project was quietly shutdown and the future of RoboVM was suddenly in doubt.  Xamarin responded with free licenses for LibGDX developers, removing a great deal of the fear about the future.  At this point I had this, now somewhat eerie, exchange with Nat Friedman, CEO of Xamarin:


The devil truly is in the details, eh?  In all honesty, Nat is a stand up guy and I don’t imagine he even knew what was coming next.  On the topic of coming next in February of 2016 Microsoft announced the acquisition of Xamarin.  For most developers this was ultimately good news, as just a few months later they made Xamarin free and open source.  The missing piece in this whole equation is what happens to RoboVM?  Xamarin’s goal was to own the process of porting to mobile devices, but Microsoft’s are more about pushing the adoption of their .NET developer stack.  Let’s just say Microsoft isn’t Java’s biggest cheerleader at this point.  So then, what happens to RoboVM when the dust settles?


That brings us to this day, and this announcement from the RoboVM team:

Over the past few weeks, we’ve been working with the teams at Xamarin and Microsoft to assess the technology and business conditions of RoboVM to determine the path forward for the products. After looking at the complete landscape for mobile development with Java, the decision has been made to wind down development of RoboVM.

We have compiled an FAQ to help guide customers through the impact of this announcement. Please contact us at for questions not covered by this FAQ.

What happens to my app developed with RoboVM?

This has no impact on the apps that our customers are currently shipping. If your app is currently working, it should continue to work unless Apple introduces a breaking change in iOS – just like any other iOS app. Android projects and apps that you have created in RoboVM Studio can be opened and compiled in Android Studio or IntelliJ IDEA, and any cross-platform RoboPods you are using on Android and iOS should continue to work in those projects, subject to breaking changes.

What should I do with the app I’m developing with RoboVM?

Depending on where you are in the development of your apps, there are several options available to move forward, including tools that will help you port to Xamarin, and alternative Java SDKs which target iOS. In particular, libGDX has just announced their support for Intel’s Multi-OS Engine, which means there is an alternative for the majority of RoboVM’s active developers. Beyond this, Microsoft and Xamarin are very interested in enabling your success in mobile and we’d like to help you move forward. If you’d like to discuss your app development plans, please email us at

Can I continue using my license?

Yes. You will be able to continue to activate your current RoboVM paid or complimentary subscription until April 30th 2017. This should give you ample time to transition your existing apps to alternatives.

I purchased a license, can I get a refund?

Yes. We’re offering a full refund for all existing customers as of today. Please contact us at to request a refund.


Translation, Microsoft took a look at RoboVM, decided it didn’t fit with their plans and put a bullet in it.  Ouch.  In this new world where Microsoft is trying to look more open source friendly and get away from their past of embrace, extend, extinguish, it’s sad to see they didn’t just re-open the source code and let the world continue merrily as it was.  Perhaps if there is enough outrage they may do exactly that, as right now the optics on this move don’t look too good for Microsoft.  I do however have to applaud them for giving complete refunds to every customer that requests one.


So, where does that leave LibGDX developers in the meanwhile?  While the post above linked to the answer to that.  Mario Zechner, founder of the LibGDX project, has made a rather extensive blog post on the subject.  I suggest you go read the entire thing for insights into the various options available, but I will reproduce key bits below:

RoboVM is dead, what now?

Quite a few libGDX folks have free RoboVM license keys to deploy their libGDX app on iOS. These license keys will continue to work until the 17th of April 2017. However, there will be no further updates to RoboVM, be it new features or bug fixes. The same is true for all the RoboPods the community came to rely on. Moreover, new sign-ups for free RoboVM Indie licenses will also no longer be fulfilled.

In short, if you have a game using RoboVM already, you can continue using RoboVM until the license expiration date. If you start a new game, RoboVM is not an option. In either case, you should move to an alternative as soon as possible.

What are the alternatives?

There are many alternatives to RoboVM, however, none comes quite close to what RoboVM offered. Let’s examine all the available options. We’ll look at them from various viewpoints: tooling support (IDEs, Maven, Gradle), bindings support, binary size, performance and Bitcode compatibility.

Before we dive in, let me elaborate on the Bitcode compatibility, as it is probably the most important feature. Apple recently introduced a requirement that prohibits submission of apps in raw machine code form for watchOS and tvOS. Instead, Apple wants you to submit your apps as Bitcode. Bitcode is a (not quite) machine independent intermediate language from which Apple generates actual machine code on app submission. Any solution that has no clear path to Bitcode is hence at a big disadvantage.

The Options (See Post for Features and Flaws of Each):

  • Mobile OpenJDK 9
  • Codename One
  • J2ObjC
  • Avian
  • Xamarin + IKVM
  • Intel Multi-OS Engine


What is the future of libGDX on iOS?

Tomski has already written a new libGDX backend for Multi-OS engine. Here’s the roadmap for libGDX:

  1. Clean-up the Multi-OS backend, integrate it with the libGDX Setup UI, and update the documentation. We are at a 95% status with this, i hope to have the code drop sometime this weekend
  2. Release a new libGDX version next week, that will make Multi-OS engine the default iOS backend for newly created libGDX projects
  3. Begin creating bindings for popular 3rd party iOS libraries. This is where we hope the community can jump in
  4. Keep the RoboVM backend around until the licenses expire (April 17 2017). We’ll try our best to fix any bugs in the backend, however we won’t be able to fix bugs in RoboVM itself

The roadmap of your existing apps should look something like this:

  1. Keep publishing updates using RoboVM 1.14.0 and the corresponding backend
  2. Immediately start adding a Multi-OS engine based version of your app for iOS
  3. Test it and report bugs on our issue tracker
  4. Switch over to Multi-OS Engine as soon as possible


So, that’s where we stand today.  The sky isn’t falling, the world isn’t ending, but we are certainly going to see some bumps in the road shortly.  No doubt some of you are going to be upset, but be smart about how you direct your anger.  Mario and the RoboVM team aren’t the villains here, in fact they just had their baby taken away from them, imagine for a moment how that feels?

It always sucks to see a good technology discarded for business reasons.  I think the happy ending for everyone would be if Microsoft open sourced the RoboVM project instead of killing it completely.  In the grand scheme of things it may not take off, the skills required to develop and maintain this kind of project aren’t common place.  It would however give the technology a chance to live and not be the casualty of a business decision.  More to the point, it would allow developers a great deal more time, options and a smoother ride in transitioning to a new solution.

At the end of the day this wasn’t a decision made by Xamarin, RoboVM or LibGDX.  The decision is 100% on Microsoft.  If you want to properly focus your response, that is your target.  Again, Microsoft is a company that is trying to improve their image with developers on non-MS platforms and in the open source community.  This action... certainly doesn’t help!

GameDev News

14. April 2016


Cocos Creator is an all in one open source JavaScript game engine and editor built over the Cocos2d-x game libraries.  They just released version 1.0.1, primarily a bug fix release as you can see from the details below.  If you are interested in learning more about Cocos Creator I did a fairly in-depth hands on with a previous version.


Changes and fixes from this release include:

  1. [Animation] Allow position.x and position.y properties can be added separately in an animation
  2. [Animation] Fixed a bug that ‘add clip’ may cause error when selecting child node of animation root.
  3. [Editor] Main window’s title now shows project name and scene path
  4. [Editor] Added a dialog letting user choose display language when running editor for the first time
  5. [Component] Fixed AudioSource volume setting has no effect issue.
  6. [Build] Fixed error of duplicated classes when publish to Web
  7. [Render] Fixed scene render not update in time when a node’s parent change
  8. [Render] Fixed spine graphics showing wrong blend factor on Web
  9. [Render] Fixed preview in Wechat may display black screen issue.


Cocos Creator is available for download on both Windows and Mac at this location.

GameDev News

14. April 2016


PlayCanvas is a popular and capable 3D WebGL based game engine I previously covered in this Closer Look entry.  Today they announced the addition of runtime light mapping.  Lightmapping is one of those tricks game engines use to make lighting in a game look great with low performance cost.  However they also generally involve several tools and a lightmap baking process.  Today PlayCanvas announced runtime support for lightmapping:

How does it work?

For the uninitiated, lightmaps are extra textures that contain pre-computed lighting information that are applied to models at runtime. This means that instead of expensive per-pixel lighting, you can pre-compute static lighting that is incredibly cheap to render on the GPU.

We’ve also specially designed our lightmapping solution for the needs of the web. In the Sponza scene above, there are 5 lights which generate 65 lightmaps applied to the 240,000 triangle mesh that makes up the scene. In total, this generates over 60MB of HDR lightmap textures. Even with an excellent compression ratio, it would be very time consuming to download this texture data. So we’ve designed the PlayCanvas lightmapper to be unique among both native and WebGL engines. The PlayCanvas Engine generates all lightmaps on application start. In a few hundred milliseconds, we generate all the textures required for static lighting so your scene runs super-smoothly across all devices.

What’s good about it?


Just see for yourself. Switch between the lightmapped and dynamic lighting modes in the Sponza demo above. On a MacBook Pro or a recent mobile device like a Nexus 5 or iPhone 6, the lightmapped scene runs at 60fps. Using the real-time dynamic lighting we have to sample 5 filtered shadow maps (one for each light) which seriously affects performance.

With this new feature, we’re enabling WebGL developers to create beautifully lit 3D scenes that run in all browsers from low end mobile to high end desktop. Not only will your application run smoothly on mobile, it will also load incredibly fast.


The lightmapping tools are built directly into the Editor. To get started, you just need to flick a couple of check boxes on your light and model components and hit the Bake button. Find out more by reading the new documentation.

Features, Features, Features

Of course, there are also all the bells and whistles that make the lightmapper a dream to use. We generate HDR lightmaps so everything looks great. You can mix and match your static and dynamic lighting to give you the best of both worlds. We even auto-magically UV-unwrap your models if you haven’t already generated lightmap UVs.


You can read more about it, and witness a demo of lightmaps in action, right here.

GameDev News ,

14. April 2016


Today (yesterday technically) saw the release of Gideros 2016.4.  Gideros is a now open source, Lua powered mobile game engine with a full editing environment.  This new release is rather large but one new feature stands out above the rest, HTML5 support.   You can now export your game for the web and see full 60fps full screen performance.  No code changes are required, simply export your game in HTML, double click the generated HTML file and you are off to the races.


There were several other changes and fixes in this release, including:

New keyboard event: EVENT.KEY_CHAR is now triggered on some platforms (QT, HTML5, WinRT) to allow grabbing textual representation of text typed on a physical keyboard.

  • Completely rethought the export system: introduce direct APK export (for Android) and app icon generation from a single visual (on some exports, work in progress)
  • Viewport object (inherits from Sprite): displaying same sprite hierarchy in multiple places, eg for split-screen games.
  • Cryptography: MD5 hash and AES128 encryption primitives
  • Lightweight Win32 Windows desktop export now promoted to beta. Now exports two executables one with a debugging console and one without. Largely feature complete but still lacks UrlLoader.


  • Path2D texture support
  • gdrdaemon: Handle player discovery


  • Path2D bounds computation
  • Gideros Studio: Handle player loss (as opposed to discovery)
  • LiquidFun issues
  • Windows Store apps: fixed scaling issue on low resolution Windows 10 devices

You can read the full release here while Gideros itself is available here.

GameDev News ,

Month List

Popular Comments