Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

11. April 2017

 

The Godot Engine is inching closer to the major 3.0 update and a recent progress report illustrated several new features that have been added to the engine.  If you are currently unaware of it, Godot is an open source fully featured 2D/3D game engine with a complete editing environment.  You can learn how to use Godot with our comprehensive tutorial series available here

Several new features have just been added, in varying degrees of completion, including:part_directed

  • Web Export an experimental exporter to WebAssembly and WebGL enabling you to publish your Godot game to run in browsers, although only the most current Firefox and Chrome browsers are currently supported
  • GDNative was recently announced as DLScript but was thankfully renamed to the much more expressive GDNative.  This provides a bridge between the Godot engine and native code without requiring any recompilation
  • New Particle System that works entirely on the GPU enabling a huge number of particles, many more than the current implementation.  The new system also allows tighter control, curve based tweaking, mesh based particles and more options for particle emitters, as seen in the image to the right.

Godot 3.0 alpha will be released soon.  If you are interested in playing with the new features, you will instead have to build Godot from the current master branch.  For details on how to build Godot using Visual Studio refer to this tutorial.

 

For more details on Godot 3.0, be sure to check the Godot engine blog post.

GameDev News

11. April 2017

 

Cocos Creator is a full game engine and editor powered by JavaScript created by the team behind the Cocos2d-x project.  If you want to learn more about the Cocos Creator project be sure to check out our hands on video.  Today Cocos Creator learned a new trick in the form of C++ and Lua support for creator alpha zero.  This doesn’t actually add C++ or Lua language support to Cocos Creator editor.  Instead it’s a pair of new features.  First Cocos Creator is now capable of exporting projects in .ccreator file format.  Second they have provided a reader enabling Lua and C++ Cocos2d-x projects to read and use ccreator files.  Essentially this enables Cocos Creator to be an editor for your C++/Lua Cocos games.  Loading the scene in C++ is simple as illustrated by this code:

#include "reader/CreatorReader.h"

void some_function()
{
    creator::CreatorReader* reader = creator::CreatorReader::createWithFilename("creator/CreatorSprites.ccreator");

    // will create the needed spritesheets + design resolution
    reader->setup();

    // get the scene graph
    Scene* scene = reader->getSceneGraph();

    // ...and use it
    Director::getInstance()->replaceScene(scene);
}

 

Details from the Cocos Creator forum:

What's C++ and lua support for creator

It includes two parts:

  • First, it is a Cocos Creator plugin that can export scenes generated by Cocos Creator into .ccreator files.
  • Second, it has a reader that can parse .ccreator files. The reader can be used in cocos2d-x c++/lua project.

Download

There are two ways to get the plugin

GameDev News

6. April 2017

 

Following up on our keyboard handling tutorial, we carry on the HaxeFlixel tutorial series looking at how to handle mouse input.  Unlike keyboard input, polling isnt our only option, we can also have event driven mouse input.  Let’s take a look at how to do both.

Let’s start of with an example polling the mouse.  That is each frame we check for the status of the mouse and respond accordingly.  OK, code time.

import flixel.FlxState;
import flixel.FlxSprite;
import flixel.FlxG;

class PlayState extends FlxState
{
   var sprite:FlxSprite;
   var scaleFactor = 0.1;
   override public function create():Void
   {
      super.create();

      sprite = new FlxSprite();
      sprite.loadGraphic(AssetPaths.enemy__png);
      sprite.x = FlxG.width/2 - sprite.width/2;
      sprite.y = FlxG.height/2 - sprite.height/2;
      add(sprite);


   }

   override public function update(elapsed:Float):Void
   {
      super.update(elapsed);

      if(FlxG.mouse.overlaps(sprite)){
         if(FlxG.mouse.pressed){
            sprite.setPosition(FlxG.mouse.getPosition().x - sprite.width /2   ,
            FlxG.mouse.getPosition().y - sprite.height /2);
         }
      }
      if(FlxG.mouse.justReleasedRight){
         sprite.x = FlxG.width/2 - sprite.width/2;
         sprite.y = FlxG.height/2 - sprite.height/2;
         sprite.scale.set(1,1);
      }

      if(FlxG.mouse.wheel != 0){ 
         sprite.scale.add(FlxG.mouse.wheel * scaleFactor,FlxG.mouse.wheel * scaleFactor);
      }
   }
}

 

The following application is the result of the code above.  Left click and drag with left mouse button to move the sprite, right click to reset its location and use scroll wheel to scale.

You will notice that all our code resides in the update() method, meaning we will check the status of the mouse every frame.  Notice once again that all of the input code is contained in the FlxG class.  Next we use the handy built in overlaps() method which checks if the current position of the mouse overlaps the sprite.  We then check to see if mouse is pressed, by default this will refer to either a left click (or a touch).  Our next test is to see if the right mouse button was pressed then released with the method justReleasedRight(), which will be true once the mouse button is released.  Just like with the keyboard there is a difference between pressed and released in that pressed will be true constantly while the button is down, while released will only be true once per click.  Finally we check the status of the wheel.  FlxG.mouse.wheel represents the amount the wheel moved this frame.

 

Next we look at event driven mouse input.  Instead of checking the status of the mouse over and over like we do with polling, in this example we give HaxeFlixel a series of functions that will be called when input happens. 

import flixel.FlxG;
import flixel.FlxSprite;
import flixel.FlxState;
import flixel.input.mouse.FlxMouseEventManager;

class PlayState extends FlxState
{
   var sprite:FlxSprite;
   override public function create():Void
   {
      super.create();

      sprite = new FlxSprite();
      sprite.loadGraphic(AssetPaths.enemy__png);
      sprite.x = 200;
      sprite.y = 200;
      add(sprite);


      FlxMouseEventManager.add(sprite,
         function(s:FlxSprite){ trace("MouseDown");},
         function(s:FlxSprite){ trace("MouseUp");},
         function(s:FlxSprite){ trace("MouseOver");},
         onMouseOut
         );
   }

   override public function update(elapsed:Float):Void
   {
      super.update(elapsed);
   }

   public function onMouseOut(s:FlxSprite){
      trace("Mouse Out, sprite at: " + s.x + "," + s.y + " Mouse at: " + FlxG.mouse.getPosition());
   }
}

 

In this example we wire a number of event handlers up to our sprite object.  This is done via the FlxMouseEventManager for which we pass in the sprite we want to track mouse input for and a series of 4 functions that will be called when various different actions occur.  Those actions are mouse down (any button), mouse up (any button released), mouse over ( the mouse is within the sprite’s bounds) and mouse out ( the mouse leaves the sprite’s bounds).  In this case I used 3 anonymous functions which simply print out the event that occurred.  For the onMouseOut event I instead implemented a member function, mostly just to show that different options you have.  You’ll notice in onMouseOut we ask for the mouse’s position using FlxG.mouse.getPosition().  In a similar manner you can poll the mouse for a great deal of additional information such as it’s location, button and wheel status and more.

 

The choice between polled input, event driven input or a hybrid of both is completely up to you. 

 

The Video

Programming , , ,

5. April 2017

 

A very early iteration, DLScript for Godot was just released today.  What exactly is DLScript?  The description from the Github project is probably the best definition:

DLScript stands for Dynamic Linking Script. It's a module that enables you to use shared libraries, which are dynamically linked, for scripting. DLScript was originally named "cscript" because it exposes a C API, but people thought it was related to C#, which is sometimes abbreviated as "cs". You can build these libraries with C++ as well as C, D, Rust, or any other language that supports C linkage and creating dynamic libraries.

One of the immediate powers to DLScript is the ability to link other shared libraries or to use critical code without recompiling the engine.

Currently there are C++ bindings that make developing for Godot with C++ easier, but DLScript is not limited to C++.

 

There is a much more detailed blog post, with usage instructions available here:

So what is DLScript?

DLScript is a module for Godot that adds a new "scripting language" to it. I put "scripting language" in quotes because it's not a language.

A "script" in Godot is defined as something that has methods, properties and signals. It also offers a way to use these things (calling methods, get and set properties...). Instead of having a text file representing these things (like a GDScript file for example), DLScript uses shared libraries.

In some ways, shared libraries have things in common with scripts.

  • you can load them
  • you can unload them
  • you can load function symbols
  • you can call functions

A method in a DLScript is just native machine code. You can call third party libraries from that code as well. You can call GDScript functions from a DLScript and vice versa. When C# will be supported optionally, you'll be able to call C# code as well.

 

So essentially DLScript is a new module for Godot that acts as a go between of the Godot Scripting API ( and not the entire C++ API!) and your own code, which is loaded at runtime in library form.

GameDev News

4. April 2017

 

Kotlin is a JVM powered programming language created by JetBrains, the people behind popular developer IDEs such as IntelliJ, WebStorm, CLion and ReSharper.  Kotlin offers 100% interop with existing Java code, while offering better performance and more concise code.  The recently released Kotlin 1.1 enabled JavaScript support giving Kotlin the ability to run in the browser.  Today they went one step further with the announcement of Kotlin/Native.  Kotlin/Native is a compiler that creates a stand alone executable with no need for a Java Virtual Machine at all.  Built over the LLVM technology suite, Kotlin/Native is in early technology preview for Mac OS, Ubuntu Linux, iOS and Raspberry Pi meaning Windows based developers are currently out of luck, with the following being noted:

Due to significant difference in exception handling model on MS Windows and other LLVM targets, current Kotlin/Native may not produce executables working on MS Windows. This situation could be improved in upcoming releases.

Details of Kotlin/Native from the announcement blog:KotlinNative

Kotlin/Native is another step toward making Kotlin usable throughout a modern application. Eventually, it will be possible to use Kotlin to write every component, from the server back-end to the web or mobile clients. Sharing the skill set is one big motivation for this scenario. Another is sharing actual code.

Our vision for inter-platform code reuse is the following: one can write entire modules in Kotlin in a platform-independent way and compile them for any supported platform (currently these are Kotlin/JVM, Kotlin/JS and the upcoming Kotlin/Native). We call these common modules. Parts of a common module may require a platform-specific implementation, which can be developed individually for each platform. Common modules provide a common API for all clients, but other (platform-specific) modules can extend this API to provide some exclusive capabilities on their platform.

Note that we do not intend to make arbitrary Kotlin/JVM programs runnable on Kotlin/Native or Kotlin/JS. It would be equivalent to implementing another JVM, which is both a lot of work and a lot of limitations for the runtime. We are going another way: providing a common language for all platforms while enabling creation of common libraries through seamless interoperability with platform code.

In moving from the JVM to native code, that does lead to the question of how memory is managed.  This is also addressed in the blog post:

Kotlin/Native is designed to potentially enable different memory management solutions for different target platforms. For example, in the future it may make sense to have a tracing GC for server/desktop platforms, while ARC makes a lot more sense on iOS. Some platforms may only need manual memory management, and get an even smaller Kotlin/Native runtime in return.

This Technology Preview features automatic reference counting with a cycle collector on top, but what the final memory management solution(s) will look like is unknown at this point.

Kotlin/Native is open source and available on github under the Apache 2 open source license.

GameDev News

Month List

Popular Comments