Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

15. November 2016

 

Welcome to the getting started tutorial in the ongoing BabylonJS Tutorial Series.  Today we are going to look at creating our first simple Babylon application setup and running.  As always there is a HD video version of this tutorial available here or embedded down below. 

 

To get started with BabylonJS, we need a web page containing a <CANVAS> tag to host our application.

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Title</title>

    <style>
        #canvas {
            width:100%;
            height:100%;
        }
    </style>
</head>
<body>
<canvas id="canvas"></canvas>
</body>
</html>

 

Nothing special here.  We simply create a canvas tag named canvas, style it so it takes up the entire page and that’s about it.  Now we need to link to the BabylonJs library.  You’ve got a few options here, you can download it locally or host it from a content delivery network (CDN).  I’ll take this approach, as it’s generally the fastest option for end users.  You can even create a stripped down version with only the required features here.

 

The options for using BabylonJS include:

 

Babylon.max.js is the most human readable of the versions, making it the easiest to debug but the slowest to load.  During development, this is the version I am going to use.  Simply link to this library somewhere within the <HEAD> tag of our HTML.

<script src="http://cdn.babylonjs.com/2-4/babylon.max.js"></script>

 

We have our host webpage setup and Babylon linked, time to finally get down to some code.  Below our canvas, add the following code:

    <script>
        window.addEventListener('DOMContentLoaded', function(){
            var canvas = document.getElementById('canvas');

            var engine = new BABYLON.Engine(canvas, true);
            var createScene = function(){
                var scene = new BABYLON.Scene(engine);
                
                scene.clearColor = new BABYLON.Color3.White();
                var camera = new BABYLON.FreeCamera('camera1', new BABYLON.
                Vector3(0, 0,-10), scene);
                camera.setTarget(BABYLON.Vector3.Zero());

                var box = BABYLON.Mesh.CreateBox("Box",4.0,scene);
                
                return scene;
            }

            var scene = createScene();
            engine.runRenderLoop(function(){
                scene.render();
            });

        });
    </script>

 

When we run this code we should see:

image

 

Humble beginnings certainly, but our first running app is complete.  So what are we seeing here?  It’s an unlit cube viewed by a camera looking at the origin from –10 units down the z-axis.  Let’s take a quicker look at the code that got us here.  First we create a function that we call on DOMContentLoaded event fired, so basically when our page is loaded, this function is called.  Let’s walk through the function.

var canvas = document.getElementById('canvas');
var engine = new BABYLON.Engine(canvas, true);

This code gets a reference to the canvas tag we created in our HTML file.  We then use this canvas to create an instance of our Babylon game engine.

var createScene = function(){
    var scene = new BABYLON.Scene(engine);
    scene.clearColor = new BABYLON.Color3.White();
    var camera = new BABYLON.FreeCamera('camera1', new BABYLON.Vector3(0, 0,-10),
    scene);
    camera.setTarget(BABYLON.Vector3.Zero());
    var box = BABYLON.Mesh.CreateBox("Box",4.0,scene);
    return scene;
}

Here we are creating a function that will setup our scene.  First we create a new Scene using our newly created engine.  We then set the clear color to white.  The clear color is the color that each frame is cleared with between calls, essentially setting the background color to white.  Next we create a FreeCamera named “camera1”, located at –10 along the Z axis in our scene.  Next we set the target to the origin (0,0,0).  We will go into more detail on cameras shortly, so let’s skip over this for now. Then we create a cube at the origin named “Box” that is 4x4x4 in dimensions.  Notice in both when we create the Camera and Box we pass the scene in.  This causes these entities to be created in that particular scene.  Finally we return our newly created scene from our function.

var scene = createScene();
engine.runRenderLoop(function(){
    scene.render();
});

 

Next we create our scene by calling our just defined createScene() function.  We then start our game loop calling engine.runRenderLoop().  The game loop can be thought of as the heart of our game.  This is a loop that will be called over and over as fast as possible.  If for example your game is drawing at 60FPS, this function is called 60 times in a second.  For now all we do is call scene’s render() method, which causes the contents of that scene to be drawn.

 

Here now is the code in it’s entirety.  ( A WebStorm project is available in the GFS Patreon Dropbox directory Tutorial Series –> Babylon for backers )

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
    <script src="http://cdn.babylonjs.com/2-4/babylon.max.js"></script>

    <style>
        #canvas {
            width: 100%;
            height: 100%;
        }
    </style>
</head>
<body>
    <canvas id="canvas"></canvas>
    <script>
        window.addEventListener('DOMContentLoaded', function () {
            var canvas = document.getElementById('canvas');
            var engine = new BABYLON.Engine(canvas, true);
            var createScene = function () {
                var scene = new BABYLON.Scene(engine);
                scene.clearColor = new BABYLON.Color3.White();
                var camera = new BABYLON.FreeCamera('camera1', new BABYLON.
                Vector3(0, 0, -10), scene);
                camera.setTarget(BABYLON.Vector3.Zero());
                var box = BABYLON.Mesh.CreateBox("Box", 4.0, scene);
                return scene;
            }
    
            var scene = createScene();
            engine.runRenderLoop(function () {
                scene.render();
            });
        });
    </script>
</body>
</html>

 

That’s it for now.  In the next part we will explore cameras in more detail.

 

The Video

GameDev News , , ,

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

15. November 2016

 

Epic have just released a new version of the Unreal game engine, 4.14.   Visual Studio 15 support, a new forward shading renderer, Sequencer improvements and more fill out this release’s key features.

 

From the release notes:

WHAT’S NEW

Unreal Engine 4.14 introduces a new forward shading renderer optimized for VR, enabling crisp multi-sampled anti-aliasing in your games. The new Contact Shadows feature renders beautifullyUE414 detailed shadows for intricate objects. We've also introduced a new automatic LOD generation feature for static meshes that does not require a third-party library.

We’ve streamlined the animation tools to help you be more productive, and added many new features to Sequencer (UE4’s non-linear cinematic tool), as well as improvements to vehicles, clothing and animation Blueprints.

For mobile developers, Vulkan support is ready to use on compatible Android devices! And, we've added various new mobile rendering features such as reading from scene color and depth, and the ability to draw 3D objects on top of your UI.

On the Windows platform, C++ programmers can now use Visual Studio "15" for development. Visual Studio 2015 is still supported.

 

As always you can download the newest version using the Game Launcher.  You can read a great deal more about the new features here.

GameDev News

15. November 2016

 

Microsoft leaked a bit of announcement ahead of their upcoming connect(); developer conference.  Visual Studio is coming to Mac OS!  While getting a bit long in the tooth, Visual Studio is perhaps the best IDE available today – it’s certainly leagues better than Xcode.  Then again, writing your code using Morse code is better than Xcode.  As someone who does a fair bit of cross platform development, I was pretty stoked by this development.

 

*Was*

 

Sadly the announcement is nowhere near as good as it at first sounds.  Turns out it isn’t Visual Studio they are bringing to MacOS.  Instead they have simply rebranded Xamarin Studio (which they acquired earlier this year) as Visual Studio for Mac.  Boo. 

 

Although Microsoft took down the premature release, it is available via Google cache:

Below the surface, Visual Studio for Mac also has a lot in common with its siblings in the Visual Studio family. Its IntelliSense and refactoring use the Roslyn Compiler Platform; its project system and build engine use MSBuild; and its source editor supports TextMate bundles. It uses the same debugger engines for Xamarin and .NET Core apps, and the same designers for Xamarin.iOS and Xamarin.Android.

Compatibility is a key focus of Visual Studio for Mac. Although it’s a new product and doesn’t support all of the Visual Studio project types, for those it does have in common it uses the same MSBuild solution and project format. If you have team members on macOS and Windows, or switch between the two OSes yourself, you can seamlessly share your projects across platforms. There’s no need for any conversion or migration.

 

Sadly this means no C++ support.  I think the worst part of this release is it basically guarantees that the “real” Visual Studio is never coming to OS X.  Perhaps more worrying... perhaps the future of Visual Studio on Windows is this rebranded Xamarin Studio.  Given that they just released Visual Studio 15 preview 5 this seems unlikely.

GameDev News

11. November 2016

 

The Defold Engine folks just announced a developer contest with 6 grand prizes of up to 3 team members can win a trip to next years Game Developer Contest, including travel, accommodations and of course GDC passes.  Submission deadline is January 22, 2017 and you can make as many submissions as you want.  Of course you have to develop your game using the Defold game engine.  If you are new to theDefold Defold engine, don’t worry, we’ve got you covered!  We have a complete tutorial series available here on that will get you up to speed.

 

Some key details from the Defold Contest FAQ:

How many teams will win?

Six teams with three people each—meaning we will send eighteen people to GDC in total!

What type of game should I do?

Why not a Monkey Island reboot set in the Grand Theft Auto universe? Or a MechWarrior pastiche based on Sonic the Hedgehog? Or a Tetris with a Zelda style conversation mechanic in 8-bit? What we’re trying to say is, make whatever you want! Defold is a versatile engine suited for all types of 2D games, and we would love to see this reflected in the entries. We are not looking for stuff of a specific type—just awesome stuff.

Does it have to be a full game?

No, definitely not—technically, it doesn’t even have to be a game. What we are looking for is a reasonably polished playable which should be fun and/or interesting for most users for at least two minutes. Or in other words: we prefer seeing something very small that is awesome rather than a full game that is mediocre.

Does the game have to be made in Defold?

Yep.

Can I submit more than one entry?

Yes, of course! There is no limit to how many entries you can submit.

Will my team get its own booth?

No, you will share it with the other winning teams. It’s gonna be an amazing indie game showcase booth for yourself as well as the other winners of the competition. Kind of similar to what we did at White Nights in Moscow a while back—a concept that turned out to be a great way to really promote the games and the people behind them.

Do I have to be in the booth?

Yes—we’d hate the booth to be empty, so we require 16 hours presence at the booth from your team, distributed as you wish between your team members during the three conference days. Think of it as 16 hours where you get the unique opportunity to showcase yourself and your game to the 27,000 people visiting GDC!

Am I expected to promote Defold?

No, we would rather you talk about yourself and your game. That’s why you’re there; not to promote Defold.

We are only two people in our team—what happens to the remaining ticket?

We’d hate for the tickets to go to waste, so bring a friend (or recruit a third team member) who you think would be interested!

Will I lose the rights to my game if I submit it to the competition?

No, you will continue to own all the rights to your game. However, we do reserve the right to use e.g. screenshots in our marketing regarding Defold.

Do I have to commercially release my Defold game afterwards?

No, definitely not. But as in the question above, we might use the game in our marketing.

 

You can learn more about the competition here.

GameDev News

Month List

Popular Comments