Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
9. November 2015

 

If you read my recent laptop buyers guide for game developers you may have noticed that the “winner” was the P34 V4 by Gigabyte.  In this case I put my money where my mouth is and purchased one.  After spending the last couple days using it I figured I would create a bit of a review.

Here are the specs for the machine I purchased:

  • Intel Core i7-5700HQ Broadwell CPU
  • 16GB DDR3 RAM
  • 128GB SSD, 1TB 5400RPM SATA HD
  • NVidia GeForce 970M with 3GB DDR5
  • 2560x1440 Display
  • Windows 10 Basic
  • $1950CDN Purchase price
  • 3.5lbs and 14” chassis

 

Please be aware that a number of different versions of this machine exist, the biggest differences being the amount of system RAM and the resolution of the display.  If purchasing off Amazon, this version is a  much better value.  The RAM and drives is easily accessible if you need to make an upgrade after the fact so don’t be overly concerned about RAM or HDD sizes.

 

If you are in Canada like me, and suffering from our recently pathetic dollar valuation, I highly recommend you check with Computers Canada, where I managed to purchase it for less than Amazon but in Canadian currency!  I wont go into a great deal of detail on why I purchased this particular computer as the buyers guide and price tag should make that part clear.

 

Gallery

 

Packaging

20151106_173832

 

Contents and Power Supply

20151106_174201

 

Side View

20151106_174039

 

Relative To Razer Blade 14

20151107_095340

 

Relative to MacBook Air

20151107_094851

20151107_094836

 

Build Quality

 

I have never purchased a Gigabyte system before so my biggest concern was build quality.  My other systems are Razer and Apple, both known for a high level of fit and finish, while I pictured Gigabyte as a more … pedestrian builder.  Fortunately I was wrong here, the Gigabyte has absolutely no faults, in fact the build quality may be slightly better than the Razer ( which had a sub-par trackpad buttons ). 

The main chassis is made of aluminum and there are no obvious gaps.  The back of the screen is made of a high quality plastic, which while not looking as good as the Razer or Macbook, contributes to keeping the weight down.  Speaking of weight, this machine is amazingly light at 3.5lbs.

The keyboard and trackpad are both quite nice, although the auto sensing backlit on the keyboard seems wonky and often doesn’t come on even in complete darkness.  This fortunately can be manually set using Fn + Spacebar so it’s not a huge deal and probably is a software problem in the end.  The hinges seem solid, a point of concern with prior Gigabyte laptops.

In the end I rate the build quality as very good, a pleasant surprise.

 

Fans and Thermals

 

As I don’t review machines very often I do not have the proper equipment for measure thermal or volume emissions.  I can however state my experiences.  Under no load, the machine is completely silent and cool to the touch.  When Optimus switches from integrated to dedicated GPU the fans come on immediately.  Playing a AAA game causes the fans to crank up.  They are certainly audible but not excessive.  In the end the machine is a great deal quiter under load than my Razer Blade.

Under moderate load the temperatures arent too bade.  Once playing games for loading a heavy CAD scene and it gets hot quickly.  All of the heat is centered at the back below the screen hinge and gets uncomfortable to the touch.  The machine itself does not get warm, it is being effectively cooled and you never feel the heat on the top of the machine, but you certainly don’t want the machine to be on your lap.  I would guess that a cooling bad is not a requirement with this machine.

 

Bundled Software

 

The last time I purchased an Asus machine, it was quicker to re-install the OS than to try and deal with all the bloat pre-packaged.  The same was about the Lenova desktop I recently purchased.  This machine however… nothing.  Gigabyte installs just about ZERO extraneous software which was nice to see.   Adobe Acrobat is installed along with the manual.  A utility for creating a USB backup is included as is their control panel for quickly toggling features like the trackpad or Windows key off or on.  Otherwise the only other piece of software installed is an optional update manager.

Gigabyte Smart Manager

image

 

Smart Update

image

Smart update makes keeping your drivers up to date an absolute breeze and supports the ability to install beta drivers which is cool.  However it downloads EXTREMELY slow and has a non-minimizable modal window during the download process.

 

All told it’s nice to see a non-bloated install with the bundled software being genuinely useful.  More manufacturers can learn from Gigabyte!  I would like to see download speeds and the idiotic modal window removed from the Update manager however.

 

Performance, Battery Life and Real World Experience

 

I am not going to bother with benchmarks in this review as I have no other benchmarks to compare it to.  Given the fast GPU, copious RAM and the fact it’s got the second best mobile video card available right now, it performs about as well as you would expect.  I threw a few games at it, Batman Origins, Heroes of Might and Magic 7 and Tomb Raider and was able to hit the v-sync limited 60fps at max settings on all three games.  Even running at native resolution I was able to manage playable framerates (40+) at max settings.  I did experience some oddity in Blender, but I think that’s more Blender to blame than the laptop.  I created a 3mil polygon scene and was able to sculpt with absolutely no hint of lag.  However switching to edit mode brought Blender to it’s knees.

 

Next we should talk about the screen.  Right now I am typing this at a café with sun glaring in my eyes with the screen at 60% brightness and I have absolute zero difficulty with glare.

20151109_145121

At full brightness the screen is a thing of beauty.  It is also the laptops second biggest failing.  Windows 10 has come a long way with high DPI screens but when they fail they fail hard.  Many applications are nearly unusable or extremely ugly when scaled to the higher resolution.  Worse is UIs that can’t be scaled leaving the results pretty much impossible to read.  Fortunately the 2560x1440 resolutions isn’t as extreme as 4K displays but it is still quite difficult to use many applications designed for a 1080p world.  The results look pretty good down sampled to 1080p thankfully.  If it was available I would have probably gone with a 1080p screen to save the hassle, but of course this is a matte of opinion.  Remember though, there is a 1080p option available.

 

Next we come to battery life and this is the Achilles heel of most “gaming” laptops, with machines that struggle to break 2 hours battery life under light load.  Thankfully this is not the case with the Gigabyte machine, in fact it is matching the Razer Blade 14 it is replacing, which is pretty amazing.  It was hard to tell exact battery life during the first couple days as Windows is downloading patches, indexing files and generally just being a bit of a pig.  Now that things seem to be settled I’m getting a pretty good gauge on battery.  Today for example I have been running on battery the last 3 hours with the wifi on, the screen at 60% brightness on balanced battery level with a little bit of 3D work thrown in the mix but mostly writing, surfing and watching a bit of YouTube, and the battery is at 31% with an indicated 1hr 25min remaining.  So 4 1/2 hours battery life under typical load.  I imagine I could stretch the battery out to about 6 hours by dimming the screen, while gaming would be lucky to hit 2 hours.  All told this is an amazing amount of battery life.

 

One minor (to me) problem with the Gigabyte P34w v4 laptop is it just sucks in the fingerprints.  I thought the Razer was bad, but this thing looked filthy within 5 minutes of taking it out of the box.  If you are a neat freak, this is certainly something to be aware of.  Fingerprints and this design… they aren’t friends.

 

Conclusion

 

In all honesty I am absolutely amazed by this laptop.  Great build quality, amazing specs, a 2 year warranty at the low end of the price range all in the 3.5lb 14” package.  It is certainly not a purchase I regret and one that I can easily recommend to anyone that favors portability and power in their laptop requirements.

It’s not completely perfect, but damned close.  The ultra high DPI screen can be EXTREMELY annoying at times, but that is by no means unique to the Gigabyte and unlike many other laptops, it at least has the guts to power that display.  Otherwise the two biggest negatives are the heat under load making it impossible to use as a literal laptop, but given the form factor and power available, this isn’t really surprising.  The other “flaw” is the slow speed of the secondary drive, a 5400RPM SATA drive is an unfortunate choice.  That said having the primary 128GB SSD drive makes this an inconvenience at worse and I rarely notice it.  The drives are easily accessible though should you wish to swap them out.

All told, this is an amazing machine.  When I purchased my Razer it was unique in the category, but as we saw there are now a number of high powered portable machines on the market now.  And with all things considered, price, size, weight, power and performance, the P34 came out a clear winner.

Totally Off Topic


31. August 2015

 

In this Closer Look At we look at take a look at the jMonkeyEngine.  The Closer Look At game engine series is a cross between an overview, a review and a getting started tutorial to help you decide if a game engine is the right fit for you.  The jMonkeyEngine engine is a Java based, open sourced, cross platform 3djMonkeyCloserLook_450px game engine that runs on most Java supported platforms and can target Windows, Linux, Mac and Android, with iOS and Oculus VR support currently being tested.  jMonkeyEngine is available as both a game library, or as a set of tools built on top of the NetBeans IDE.  For this closer look, we will focus on the full SDK experience.

 

 

This closer look is also available in HD video format here.

 

 

Although we are going to focus on the complete set of tools including in the jMonkeyEngine SDK, keep in mind it can be used in library form if you prefer working in Eclipse or IntelliJ.  You will however lose access to some very convenient tools.

 

 

Meet jMonkeyEngine

 

As I mentioned earlier, jMonkeyEngine ships in two forms, as a set of libraries, or as a complete SDK build on top of the Netbeans IDE.  You can download load the SDK for Windows, Mac or Linux right here.  As of writing, 3.0 is the current released version, while 3.1 is available in development on Github.  This version marks the first public release using the Github platform.  jMonkeyEngine has a few prerequisites before installing, but they basically boil down to having an OpenGL 2 compatible video card and JDK 6 or higher installed.

 

Once downloaded and installed simply run the jMonkeyEngine SDK application.   This is jMonkeyEngine:

image

 

As mentioned earlier, this is actually a preconfigured version of the Netbeans IDE with a set of plugins and extensions to support jMonkeyEngine development.  This means in addition to the various jME tools you get a complete modern Java development environment, meaning code completion, project management, refactoring tools, debugging and more.  I won’t be specifically covering Netbeans functionality in this guide.  If you’ve got prior experience in Eclipse or IntelliJ, you should feel right at home.  Personally I rate the Netbeans experience somewhere between the two, with IntelliJ being quite a bit better, while Eclipse is many many many times worse.  That all said, that is purely opinion, each platform has it’s strength and weakness, it’s fans and haters.  If you prefer to use Eclipse or IntelliJ you can.

 

Hello jMonkeyEngine

 

It is often easiest to start with a simple project, so let’s do exactly that.  Select File->New Project

image

 

A New Project wizard will appear.  All of the standard project types supported by Netbeans are available, but also the new jMonkeyEngine templates are available too.  Select BasicGame and click Next.

image

 

Pick a name and location and click Finish.

image

 

Your project will now be created.  You can have several projects open in the IDE at the same time, just be sure to select the right one in the Projects panel:

image

 

The wizard will have automatically created a project hierarchy for you:

image

 

It’s optional to use this layout, but you are making life more difficult for yourself if you do not.  File paths for textures in imported models are absolute, forcing your hand somewhat in how you import your data.  Again, you can code around this design, but you are making your life more complicated.  For the most part I found the layout fairly logical, but the suggestion to import your models into the Textures folder then relocating them to Models ( well discuss this more later ), well that simply a gross kludge.

 

The New Project wizard also generated a default source file for us, Main.java, with the following contents:

 

package mygame;

import com.jme3.app.SimpleApplication;
import com.jme3.material.Material;
import com.jme3.math.ColorRGBA;
import com.jme3.math.Vector3f;
import com.jme3.renderer.RenderManager;
import com.jme3.scene.Geometry;
import com.jme3.scene.shape.Box;

/**
 * test
 * @author normenhansen
 */
public class Main extends SimpleApplication {

    public static void main(String[] args) {
        Main app = new Main();
        app.start();
    }

    @Override
    public void simpleInitApp() {
        Box b = new Box(1, 1, 1);
        Geometry geom = new Geometry("Box", b);

        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        mat.setColor("Color", ColorRGBA.Blue);
        geom.setMaterial(mat);

        rootNode.attachChild(geom);
    }

    @Override
    public void simpleUpdate(float tpf) {
        //TODO: add update code
    }

    @Override
    public void simpleRender(RenderManager rm) {
        //TODO: add render code
    }
}

The code is all pretty straight forward.  You game code extends the class SimpleApplication, which in turn implements Application plus implements some “out of the box” behaviour like key mappings for exiting the application and implementing a camera.  These default behaviours can easily be overridden as we will see shortly.  SimpleApplication exposes three critical methods as part of your games life cycle, simpleInitApp(), called when your app is created, then simpleUpdate() and simpleRender() called over and over by the game event loop.  Basically stick your setup code in the init() method, your update code in the update() method and drawing code in the render() method.  If these methods start getting overly complex, you can refactor your design to use States, something we will cover later on.

 

You can run or debug your project using the toolbar:

image

 

Or via the Run menu:

image

 

Once launched you will see a configuration Window.

image

 

Select your preferred configuration and click Continue.  You may be asking, can I get rid of this damned window?  The answer is yes you can, but you have to use code to do it.  I can’t really fathom why there isn’t a “Remember my settings” check box.  Once you click Continue, your first app will run.

FirstApp

 

As you move the mouse cursor around, the camera implemented in SimpleApplication is moving the camera position around.  You may also notice the debug details and of course that startup window.  As said earlier, this can all be override, let’s look at how.

First we can get rid of the configuration window ( which I admit, gets old very quickly ) and set a default resolution using the following code:

    public static void main(String[] args) {
        Main app = new Main();
        
        // Dont show window
        app.showSettings = false;
        
        // Create a new app settings loaded with defaults
        AppSettings appSettings = new AppSettings(true);
        
        // Override resolution
        appSettings.put("Width",720);
        appSettings.put("Height",480);
        
        // Add a title, just because
        appSettings.put("Title", "Super Awesome Megagame 9000!");
        
        app.setSettings(appSettings);
        app.start();
    }

 

Next in our init we add the following logic to disable the camera and debug info. These need to be called after app.start(), thus why they are in init.

    @Override
    public void simpleInitApp() {
                
        // Disable fly cam
        this.flyCam.setEnabled(false);
        
        // Turn off debug info and FPS window
        this.setDisplayFps(false);
        this.setDisplayStatView(false);
        
        Box b = new Box(1, 1, 1);
        Geometry geom = new Geometry("Box", b);

        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        mat.setColor("Color", ColorRGBA.Blue);
        geom.setMaterial(mat);

        rootNode.attachChild(geom);
    }

 

Now when you run your game, you should no longer see the config window, nor display stats when running.  Instead you should see:

image

 

Importing a 3D Model

 

One of the first things I do when testing a new engine is check to see how hard it is to get a 3D model imported.  In jMonkeyEngine you have a couple of options, you can import to their native format, use a Blender plugin, support an OBJ file, or import files converted using the Ogre XML toolchain, which is also available as a Blender plugin as well as several other packages.

 

I will use the native format (j3o) later, for now, let’s look at the process of importing a Blender model, since jMonkeyEngine has solid Blender integration built in.  In fact, jMonkeyEngine actually ships with a copy of Blender as part of the SDK install, currently version 2.69 (as of writing, 2.75 is the most current version).  When you run Blender from within jMonkeyEngine, this included version is the one that is run.  (Note, for performance, you should always prefer using the native binary format unless you have a very good reason not to).

 

You can add a new textured Blender cube (you don’t have to by the way), right click the desired location and select File->New->Other…

image

 

Then select Blender->Box prepared for UV texturing.

image

 

Name it and confirm the location, then click Finish.

image

 

This will run a copy of Blender and set up a cube with textures defined for you.

image

 

What’s extremely odd here is the configured cube isn’t actually ready to go.  You still need to UV unwrap the cube, attach a texture and set the UVmap.   You can see the entire process in the video if you need more details.

 

You can confirm that the blend file works fine, right click the blend and select View Model.

image

 

This will open the Viewer.

image

Be sure to click the light icon (top left) to enable lighting in the viewer.  Now that we know the Blender file works, let’s move over to the code to load a Blender file.  there is a bit of a challenge first, Blender support is actually added as a plugin, we need to add it in first.

 

Right click Libraries and select Add Library…

image

 

Select jme3-libraries-blender then click Add Library.

image

 

We need to add a light to the scene or the model isn’t going to show up.  Simply drag and drop SunLight from to the drop of the simpleInitApp() code and it will drop all the code we need.

image

package mygame;

import com.jme3.app.SimpleApplication;
import com.jme3.light.DirectionalLight;
import com.jme3.math.ColorRGBA;
import com.jme3.math.Vector3f;
import com.jme3.renderer.RenderManager;
import com.jme3.scene.Spatial;

public class Main extends SimpleApplication {

    public static void main(String[] args) {
        Main app = new Main();
        app.start();
    }

    @Override
    public void simpleInitApp() {
        /** A white, directional light source */ 
        DirectionalLight sun = new DirectionalLight();
        sun.setDirection((new Vector3f(-0.5f, -0.5f, -0.5f)).normalizeLocal());
        sun.setColor(ColorRGBA.White);
        rootNode.addLight(sun); 
        Spatial blenderModel = assetManager.loadModel("Models/demoBox.blend");
        rootNode.attachChild(blenderModel);
    }

    @Override
    public void simpleUpdate(float tpf) {
        //TODO: add update code
    }

    @Override
    public void simpleRender(RenderManager rm) {
        //TODO: add render code
    }
}

And run it:

image

 

So other than Blender configuration, getting a model into a jMonkeyEngine app is fairly straight forward.

 

Tools in jMonkeyEngine

 

Code Palette

We briefly saw the Palette in action in the previous example.

image

This is a selection of code snippets you can drag and drop into the editor.  One major gotcha however, many of these samples depend on a library, jme3-test-data, that isn’t included by default oddly enough.  We saw earlier when we set up the Blender plugin the process of adding a library.

 

3D File Importer

While jMonkeyEngine supports the Ogre XML format and Blend files, working with a game oriented file format is almost always the best performing option.  Fortunately jMonkeyEngine provides just such a format, j3o.  These files can be created easily using the menu File->Import Model menu:

image

 

Then select the model

image

 

Material/Shader Editor

You can easily create shaders right clicking an Asset folder such as Materials, New->Other…

image

 

Then Material->Empty Material file

image

 

You can then define a shader using a UI tool.  You can also set a template that other materials inherit from.

image

 

3D Scene Composer

image

 

The Scene Composer can be use to assemble and create 3D scenes.  There is also a corresponding scene graph:

image

 

A variety of game nodes can be created here:

image

 

Terrain Editor

In addition to the Scene Composer, there is also a 3d terrain tool:

image

You can create terrain visually.  Easily pull and push terrain into shape, paint with multiple textures.  The generated terrain can be used in the scene composer.

terrain

 

Engine Capabilities

 

We only briefly touched upon the code capabilities of the jMonkeyEngine due to time and space restraints.  jMonkeyEngine is a full functioning engine with the following functionality, excerpted from their website.

image

 

Documentation and Community

jMonkeyEngine is well documented, with a comprehensive collection of tutorials and guides available on the wiki.  I encountered a few entries that were out of date or invalid, but for the most part the document was solid and easy to follow.  There is also a good reference in the form of the JavaDoc.  I may not always be the biggest Java fan, but I almost always love JavaDoc generated references!

Until recently the forums for jMonkeyEngine were pretty terrible, but thankfully they’ve recently transitioned to an improved forum.  There is an active community and questions rarely go unanswered.  They have also recently transitioned the source code to Github.

 

Books

 

There are two books available for jMonkeyEngine.

jm1jm2

 

 

The Video

 

Programming


25. August 2015

 

I’m about to date myself brutally with this post (hint… I’m old… much older than this book, which is also old ), however when I stumbled upon this book it stirred a bit of my childhood in a way that no Michael Bay butchered film can even attempt.  You see my first home computer was the Atari 800XL, a machine that still owns a solid place in my heart.

 

SONY DSC

 

Such an amazingly sexy thing, no?  Well in 1983 it certainly was.  Within minutes of bringing it home, my dad managed to erase the disks that came with it, leaving me alone with an Atari 800XL, the manual, the ROM version of BASIC ( thankfully ROM is remarkably Dad proof… ) and 6-8 weeks will waiting for media replacement from Atari.  On this day two journeys began.  My Dad’s continuing and overwhelming hatred of computers and my programming career.

 

I’ll admit however, although I managed to scrape together some simple text adventures, a dice rolling game and a few other simple examples, I was simply too young to get very far.  I was still quite young and information simply wasn’t as available as it is now.  It wasn’t really until I got a PC that I really started to learn to program properly.  Unless of course you count copying hundreds of lines of assembly from the pages of a magazine programming…

 

This is a bit of a shame too as the world of programming on 8bit machines was almost magical.  While those lines of cryptic bytes I typed back then seemed like magic, now that I’ve got a good 20 years of programming under my belt, I have an appreciation for how simple things actually were.  On top of that, expectations were so much lower, it truly was the age where a single developer in his garage could make a successful game.   Yes, you may have been working in BASIC or even Assembly, but the underlying processors were so simple compared to today, that with the right information, it really wasn’t the nightmare you expect it to be.

 

It’s funny, you hear lots of people say they want to work in C++ or C because they want to “get closer to the machine”.  Want to get closer to machine?  Travel back in time!  I actually think there is a lot of value in people messing around in these old systems.  So when I saw this book appear on Safari, I decided to give it a look.

 

Retro Game Programming:Unleashed for the Masses

 

Available on Amazon for less than $10 (starting at $2 actually).  With a 1.5/5 star review… that’s not a good start.  The book is old, the book is cheap, is it worth reading?

 

RetroGameProgrammingCover

I suppose that entirely depends.  The book is in a word, sloppy.  It covers a number of old systems including the Atari 800, C64 and TRS80.  It actually wastes a chapter on plugging these various machines in…  yeah.  This chapter alones suggests to me that the book may not have in fact had an editor.

 

But then it gets a bit more interesting, there’s a touch of history which I almost always enjoy, I’m not sure how it would go for someone without my rose coloured glasses on.  Then the book seems to flip back and forth between being a complete beginners book and… not.  We get a chapter on 6502 assembly programming… very cool.  We get some coverage of setting up the video and drawing to the screen, which are good reads.  Then a chapter on input and player AI, which frankly doesn’t have a single purpose for existing.  Followed by a chapter on audio programming.  It is then all capped off with a completely meaningless BASIC text adventure.  Had the book actually concluded on a complete Assembly project using what we’d learned so far, I think that 1.5 star rating would be a great deal higher.

 

So do I recommend this book?

 

No, not really.  However as I said earlier, I discovered it on Safari and it provided a few hours of amusement.  If you were looking for an interesting, but sloppy, look back at the way things were, it’s certainly worth the couple bucks it’s being sold for these days.  Even more so because it is now easy to get a hold of incredibly solid emulators of all the systems used in this book.  There is value in modern programmers experiencing how things used to be, and it’s amusing for the older folks among us to take a trip down memory lane.

 

You may be asking yourself…  hey did he just review a 10 year old book that he didn’t particularly like?  Why yes, yes I did.  I will say however, one of the advantages of being a book on retro game development is…  you never really become out of date, do you?

Totally Off Topic


4. August 2015

ParadoxHeader

EDIT -- Paradox is now Xenko Game Engine and is available at xenko.com.  Everything else should remain the same however.

In this Closer Look At we look at take a look at the Paradox Game Engine.  The Closer Look At game engine series is a cross between an overview, a review and a getting started tutorial to help you decide if a game engine is the right fit for you.  The Paradox game engine is a C# based, open sourced, cross platform 2d/3d game engine that runs on Windows and can target Windows platforms, iOS, Android and soon the PlayStation 4.  Now let’s jump right in and see if Paradox is the right engine for you.

 

This review is also available in HD video right here.

 

First off, if you are just starting out, let me save you some time.  No, Paradox is not the right engine for you.  At least, not yet it isn’t.  The same is true if you aren’t willing to deal with an unstable and developing API or less than great documentation.  This is very much an engine under development and it shows.  There is however much here to love as you will soon see.

 

Overview

 

As mentioned earlier, Paradox is a Windows based game engine capable of targeting Windows, Windows Universal, Windows Phone, plus iOS and Android using Xamarin.  PlayStation 4, Mac and Linux support are listed as coming soon.  Paradox provides an editor but is built primarily on interop with Visual Studio which for small teams or individuals is now thankfully free.  I tested with both Visual Studio 2013 and Visual Studio 2015 without issue.

 

The engine itself is impressively full featured:

  • Paradox Studio 3D editor
  • Target Windows, Windows 10, Windows Phone, Android, iOS and coming soon PlayStation 4, Linux and MacOS
  • Tight integration with Visual Studio
  • Broad 2D and 3D file support, asset management
  • 2D and 3D engines
  • Pre-generated and dynamic font support
  • 2D frame based and 3D bone/blended animation
  • Full customizable rendering pipeline
  • Physics via the Bullet Physics Library
  • Shader support via composition with inheritance and mixin support
  • Target both HLSL and GLSL
  • Complete UI system with text, images, scrolling, modals, 9patch, scrolling, etc
  • Layout system including canvas, grid, panel, stack panel and uniform grid controls
  • music (mp3) and sound effect support with positional support
  • mouse, keyboard, touch (with gestures) and gamepad input support

 

Paradox is currently available for free.  The source code is also available on Github under the GPL license.  Please note the GPL license is incredibly restrictive in what you can do using the source ( must release all changes and derived source code! ) and is by far the open source license I like the least.  You do not however have to release source code if you link to the binary versions.  They also negotiate source licenses if the GPL doesn’t work for you.  I do believe that the source license is under review, or at least was.

 

Getting Started

 

Getting started with Paradox is easy, start by downloading the installer available here.  When you run the launcher it will install the newest version of the SDK as well as the Visual Studio plugin.  You can update the SDK and re-install the plugin using the launcher.

image

 

Assuming you are running for the first time, click the big purple “Start” button in the top left corner.  By default the launcher will be left open unless you click “Close the launcher after starting Paradox” option.

Next you will be taken to the New/Open Project dialog:

image

 

As you can see, there are a wealth of samples you can get started with, or you can create your own New Game or Package.  We will be creating a new package.  These samples however are absolutely critical, as they are probably the primary source of reliable/current documentation when using Paradox.


Let’s select New Game:

image

 

Fill in the relevant information and click Select

image

 

Next we select the Platforms we want to support as well as our targeted graphic fidelity and default orientation.

image

 

Your project will now be created, bringing you  to Paradox Studio.

 

Paradox Studio

 

Meet Paradox Studio:

image

 

The above screenshot demostrates the default starting scene that will be generated for you when creating a new project.  There are a few things to realize right away… first, none of the above is required.  You could remove everything and create your game entirely in code.  Of course you will generally be creating more work for yourself if you do.  Let’s run our default application.  Choose your application and press the play or debug icon:

image

 

When you hit either button, Visual Studio is invoked via MSBuild and your project is compiled and run (Visual Studio does not need to be open, but it must be installed).  And here is the default application running:

image

 

Now let’s take a look at the various components of Paradox Studio. 

image

 

This is the scene graph of your world.  Using the * icon you can instance new entities:

image

 

You can create hierarchies of entities by selecting one then creating a child using the * icon:

image

 

In Paradox all items that exist in the game’s scene graph derive from the Entity class.  Paradox is a component based game engine and the entity class is basically a component container coupled with spatial information.

 

Below the Scene Graph is the Solution Explorer:

image

 

Somewhat interestingly, the Paradox game engine uses the Visual Studio Solution (sln) as their top level project format.  If you look in the project folder you will see YourProj.sln, then a folder hierarchy containing your code, assets, etc.  Outside of creating new packages and folders, there isn’t a ton of reason to use the Solution Explorer, at least so far as I can figure out.

 

Next up is the Asset View:

image

 

This is where you can see and select the various assets that compose your game.  They can be organized into folders to keep the mess to a minimum.  You can instantiate and asset by simply dragging it to the 3D view.  You can also import existing assets and create new assets using this window.  Creating a new asset once again involves clicking the * icon:

image

 

The views across the right are context sensitive.  If you select an asset in the Asset View, it’s properties (if any) will be exposed in the Property Grid:

image

 

The above show a portion of the settings that can be configured for a Material.

 

Below the Property Grid is the References/Preview/History panel.  References shows you either all of the objects that reference, or are referenced by the selected object:

image

 

Action History is simply a recently performed task history:

image

 

While Asset Preview enables you to see your asset in action, for example your material applied to teapot:

image

It’s a fully zoom/pan-able 3D view.

 

The property grid however performs double duty.  When selecting an instanced object ( from either the scene graph or the 3D view ) as opposed to a template from the Asset View you will have complete different options available:

image

 

This is where you configure or add new components on your entity.  Public properties of a component will have the appropriate fields available.  Click Add Component to add a new component to your entity:

image

 

Keep in mind that components that were already added ( such as Light and Transform in this case ) will not be displayed.

Components can in turn have Assets attached to them:

image

 

Click the hand icon and the asset chooser dialog is shown:

image

 

Finally we have the 3D View.

Paradox3DView

 

The 3D View can be used to create and position the various entities in your scene.  As you can see in the image above, the 3D view provides the traditional transformation widgets from the 3D graphics world.  It also uses the traditional QWERT hot keys for selection,transform, rotate and scale that Maya made famous.  The view can be zoomed using the mouse wheel or Alt + RMB, panned with middle mouse button and orbited using RMB.  You also have the ability to toggle between local, camera and global coordinates as well as snap to the grid.

 

One oddly missing component however is axis markers, making navigation a bit more difficult than it should be.

 

For the most part the editor does it’s job.  Occasionally it can become a bit unresponsive and I’ve had to restart it a few times to sync changes between it and Visual Studio.  The primary purpose of the editor is to add and manage assets in your game, to position them in space.  As I mentioned earlier, usage is entirely optional.  There are however a few glaringly missing features, such as the ability to see and manipulate collision volumes ( you can create them, just oddly not see them ) or the ability to create nav visibility meshes.

 

The Coding Experience

 

So far we’ve only seen the project creation and configuration components of Paradox3D, however it’s when you leave Paradox Studio that is either going to make you love or loathe Paradox.  As I mentioned earlier, the ultimate project type of Paradox is a Visual Studio solution.  Paradox is designed to work hand in hand with Visual Studio.  In the main editor you should see this button:

image

 

Clicking the Visual Studio logo will automatically open your project in Visual Studio, in my case Visual Studio 2015 (which is supported, along with 2013 and I believe 2010).  Here is our default project:

image

 

Hmmm… not a lot of code here… in fact there is only one file, our platform specific bootstrap.  Obviously there would be one such project for each platform you selected when you created your game.  The code contained within is certainly not huge:

 

using SiliconStudio.Paradox.Engine;

namespace DemoOh
{
    class DemoOhApp
    {
        static void Main(string[] args)
        {
            using (var game = new Game())
            {
                game.Run();
            }
        }
    }
}

 

This file implements your specific platform’s main and simply creates an instance of the Game class, then calls Run().

 

Well then, how exactly do we code our game?  Well that’s where the component based nature of our game comes in.  In your Game project, add a new class like I did here with ExampleScript.cs:

image

 

There are a couple choices of the type of script you can create depending on your needs.  For a game object that is updated by the gameloop you have a choice between an asynchronous script using C# async functionality, or a more traditional synchronous script, which implements an update() method that is called each frame.  There is also a Startup Script that is called when the engine is created but not on a frame by frame basis.

 

I’ll implement a simple SyncScript for this example, as it’s the most familiar if you are from another game engine. 

 

using System;
using SiliconStudio.Paradox.Engine;

namespace DemoOh
{
    public class ExampleScript : SyncScript
    {
        public override void Update()
        {

            if (Game.IsRunning)
            {
                if (Input.IsKeyDown(SiliconStudio.Paradox.Input.Keys.Left))
                {
                    this.Entity.Transform.Position.X -= 0.1f;
                }
                if (Input.IsKeyDown(SiliconStudio.Paradox.Input.Keys.Right))
                {
                    this.Entity.Transform.Position.X += 0.1f;
                }
            }
        }
    }
}
 
This script simply checks to see if the game is running, if it is we check to see if the left or right arrow key are down.  If either is, we move along the X axis accordingly.  Since all entities have a Transform component, this script can now be attached to any Entity we create in the world, either programmatically, or using Paradox Studio.  One very cool thing about these scripts is you have code access to 100% of the underlying engine.  One VERY important thing to notice before moving along is the public modifier on our class!  If you do not make your class public, it wont be scene as an option in studio!  Now do a build in Visual Studio to make sure your code compiles. (Ctrl + Shift + B )
 
Now let’s take a look at the process of attaching this script to an entity in Paradox Studio.
 
First in 3D View or the Scene Graph, select an object we are going to attach the script to.  Personally I am using the default sphere that was created.
 
image
 
 
With the Entity selected, in the Property Grid we should now be able to attach a Component.  Select it then add a Script component.
 
image
 
 
Scroll down to the Script section and your newly created script should now be available.  Click the + icon next to the List, then choose your script:
 
ParadoxSelectScript
 
 
If for some reason the script doesn't show up as an option:
  • verify it compiled successfully in Visual Studio
  • if it did, then verify it’s set as public
  • if it is, then reload your project in Paradox:

image

 

There are enough common bugs in Paradox Studio that a Reload will fix.  It’s annoying but quickly becomes second nature.

 

Now that your script is attached to a Script component, you can run the application and see you can now update the sphere position using the arrow keys.  Also not, you don’t have to run from Paradox Studio, after you make the edits in Studio, make sure to save your project, then in you can also run in Visual Studio using F5 or by hitting the Start/Debug toolbar.

ParadoxGameRunning1

 

The Documentation and Community

 

As mentioned earlier, this is where it all starts to go a bit wrong with Paradox.  There is full documentation, including getting started guides and reference materials, all available online only.  There is also a forum as well as a stack overflow style answers site.

 

The biggest challenge is with the engine being beta and under active development, much of the documentation is simply wrong.  What remains is often sparse at best.  Frankly the samples are going to be your primary learning source for now.  Of course the game engine is open source and available on github, just be sure to read up on the license thoroughly.

 

Conclusion

 

I think the Paradox Engine has the potential to be a great engine.  It is certainly not for beginners, not by a mile.  All of the functionality you require to create a game is in there, with a few glaring exceptions.  The rendering engine is extremely nice and I personally liked the programming model, of course I like component based engines, so I was bound to enjoy it.  The documentation however is…  yeah, not good.


I did however enjoy Paradox enough that I think I am going to do a tutorial series to help others get started with it.  Of course, I will suffer the same problems that Paradox do, a changing code base is going to break my work constantly.  So I am going to try and focus on smaller more bite sized tutorials.  Let me know if you are interested.

 
 
 

The Video

Programming


20. July 2015

 

In this “A Closer Look at”, we will be taking an in-depth look at the Stencyl game engine.  The Closer Look At series is a cross between a preview, review and getting started guide and should help you determine if a game engine is right for you.  Stencyl is a cross platform 2D game engine with tools that run on Windows, Mac and Linux and capable of targeting all of those, plus Flash, Android and iOS.  Stencyl is free to use for the Flash target with additional platforms coming with a fee.  Stencyl provides a high level Lego block type programming experience but coders need not fear, you can drop into code easily if you want.  Amazingly enough, you may find you do not actually want to!

 

There is an HD video version of this guide available here.

 image

 

The Editor

 

Stencyl is a relatively self contained providing almost all of the tooling you need in a single editor.  When you first launch Stencyl this is your initial view of the editor:

image

 

It comes with a sample game included and one nice feature of Stencyl is the ability to seamlessly download additional assets from their website including additional examples and editor extensions.  Once you’ve actually created a project you’ve got even better integration with their online store ( misnomer, as everything currently is free ).

 

The Dashboard is the home page of your game.  The game itself is broken up into Scenes and scenes are composed of Actors, Backgrounds, Fonts, Sounds and Tilesets.  Created resources are available across all scenes. 

 

image

 

Scene/Level Editor

Loading  a Scene brings up the scene editor

image

 

The editor has several modes available across the top (Scene, Behaviors, Events, Physics, Atlases and Properties).  The Scene editor (shown above) enables you to paint scenes using tiles for a tileset, or to place your various actors within the world.  The editor supports multiple layers of tiles with various blending modes available.  The tile placement experience is very smooth with functionality you would expect like snapping, flood filling (painting an entire region with a single tile) and grids. There is also support for defining regions, placing physics joints, adding rows and columns of tiles all at once and more.  The ability to paint with multiple textures is also present:

s1

 

The Tilesets themselves are created as a Tileset resource at the dashboard:

image

image

image

 

You can then edit each tile in the tileset:

image

Three things can be set for each tile, a custom piece of metadata that can be access by code (perhaps a text description of the tile), the collision shape for the bounds of the triangle, using either a default shape or defining your own, and finally the frames of animation for animated tiles.  Should you require more precise collisions than the default shapes, you can define your own Collision Bounds:

image

 

The Create A Polygon tool is a bit clunky but gets the job done:

image

 

Back to the Scene editor, you will notice the next two tabs after Scene are Behaviors and Events:

image

These are basically the way you “program” your Stencyl game and we will revisit both shortly.  Just remember them for now.  Physics enables you to configure some global level physics properties for you scene:

image

 

Atlases are akin to spritesheets in other game engines.  It enables you to bundle like minded resources into a single file to improve performance.  This is more of an implementation detail, so we wont cover it in depth.

image

 

Finally Properties enables you to set some critical details of the scene that you otherwise set during creation.

image

 

Basically Scene is your game level and Stencyl provides a complete and comprehensive level editor with most of the required tools for placement, physics, etc.  You will notice at this point that Stencyl is highly configured for creation of 2D tile based games and if your game doesn’t fit this description, Stencyl becomes less and less useful.

 

Actors

 

Next let’s take a look at the Actors interface.  An Actor is basically any game entity that isn’t a tile.  So your main character, your main menu, a high score widget and enemy sprites may all be actors.  As you will see, the interface for actors is remarkably similar to Scenes:

image

 

An actor can contain multiple animations, each of which is composed of frames of animation.  You can define as many animations as you desire and each animation you can control the order of frames and the duration that each one lasts.  Animation frames use the same interface as loading a tileset.

 

You may notice across the top there are several editor options for Actors available as well.

image

 

Appearance is the editor you see in the above screenshot were you specify the animations of your Actor.  Behaviors and Events are the programming interface and once again, we will cover those shortly.  Collision enables you to define the collision properties of your Actor:

image

One unfortunately missing feature is the ability to define a collision shape per frame of your animation.  This means if the collision volume changes massively as your Actor is animated you will either need to split it into separate animation groups or settle for less than accurate collisions.  Hopefully this functionality is added in the future.

 

The Physics tab enables you to set the Physics properties of your actor:

image

 

Note the various sub settings you can set:

image

 

This is perhaps the most accessible and least confusing physics integration I have ever seen in a 2D game engine.  Physics properties are often cryptic and simply figuring out what a particular setting does is an exercise in frustration, especially for new game developers.  So bravo for making a complicated subject dead simple.

 

Finally there is the properties section:

image

 

Which contains the button for launching the Collision Group interface:

image

 

Collision groups are handy for determining how various groups interface with each other.  For example, a Bullet may collide with Actors, but not other bullets.  One nice feature with Stencyl is the link to help on each topic:

image

 

If the purpose of an editor isn’t obvious to you, you can click the How do ____ work button and be brought to a well written help web page.  This should keep newer developers from getting overly lost and encourages exploration.

 

Programming in Stencyl

 

As I mentioned earlier in both the Scene and Actor sections, programming is done via Behaviors and Events in Stencyl.  Behaviors can be added to both scenes and actors and each is a distinct thing.  The same is true for events.  If you are coming from another game engine or programming language, Behaviors are analogous to methods or functions and can be re-used ( a scene behavior can be used on several scenes, while an actor behavior can be used across multiple actors ).  There is also a variable type named an Attribute, which can be though of the same way you would consider a property.  If that made no sense think of it this way… a Behavior makes a scene or actor do stuff, while an Event tells a scene or actor that stuff happened while an attribute stores information about stuff.

 

Programming itself can be accomplished either by using predefined behaviors or by defining your own using a building block type programming interface.  Let’s take a look. 

 

We can create a simple actor like this one:

image

 

We can easily add an instance to our Scene using the Add to Scene button, or by going to the Actors panel in the Scene editor:

image

 

Now let’s add some logic to our Actor.  In the Dashboard, select your Actor and choose edit.  Now select Behaviors and you will be greeted with:

 

image

 

Clicking it allows you to select a pre-created Behavior or one you have already defined for your game:

image

 

There are several pre-defined behaviors and more you can download from StencylForge.  Let’s add a simple behavior to our Actor.  We simply want to move left and right automatically.  Select Motion->Back and Forth Horizontally

image

 

You can then set configurable attributes of that behavior:

image

 

Now run your game by hitting Test Game and your actor will move left and right 100 pixels:

s2

 

So you can add functionality to an Actor as simply as adding a behavior to it and an instance of that actor in your Scene.  Obviously in this case our animation isn’t ideal as it only makes sense when traveling to the left.

 

Let’s now flip the character if he’s going right.  This means our first programming experience.  We can do this either in the scene or in the character itself, in this case we do it in the Scene.  Edit the Scene, select Events then add a new Event.

image

 

First click Add Event, then Basics->When Updating.  These are the three lifecycle stages.  This will create a brick named always that we can then drop other bricks in to program the behavior of our game.  Create the following structure:

image

 

This brick will be called every frame.  We check to see if the user is going left (negative) or right(positive), in the case of positive, we scale –100% in width, which is the same as flipping.  Now running the code we see:

s3

 

You can also bundle together functionality it re-usable components using virtually the same manner with Behaviors

image

 

Now one of the coolest features of Stencyl, all this visual programming you’ve been doing… it’s ultimately just a code generator using the Haxe programming language.  Click Preview Code and you can see the code generated behind the scenes:

image

You can even edit the code using an external editor like Flash Develop or IntelliJ, the process of which I describe here.  This turns Stencyl into a rapid development Haxe/OpenFL code generator and you can define the remaining game logic using a traditional programming interface if you prefer.  You can also extend the Stencyl editor itself (using Java), as well as create new blocks completely, using Haxe.    It’s a good thing this functionality exists too, as it helps make up for one of Stencyl’s biggest flaws… there is no debugger.  You can do Print style output to the log which can be viewed in the Log Viewer, but there is very little debugging functionality (breakpoints, watches, etc ) built in.  You can however debug your code in an external IDE if you are comfortable working in the Haxe language.

 

Documentation and Community

 

One of the impressive features of Stencyl is it’s documentation.  Almost none of it is local however, so if you do not have an internet connection you are in trouble.  The Stencylpedia is your starting point for help.

image

 

There is also a class reference for Haxe programmers, as well as guides for programming extensions and more.  The quality of the documentation is quite solid, especially the more entry level materials. 

 

In addition to the Stencylpedia there is StencylForge, a built-in (free) store for downloading behaviors, actors, scenes, sounds and even complete games.

image 

 

There are a few existing books on Stencyl including Stencyl Essentials and Learning Stencyl 3.1.

 

There is also an active community forum available here.

 

 

The Flaws

image

Of course no tool is perfect and there are a few negatives to Stencyl.  The first and biggest limitation is it is limited mostly to 2D games with a tileset approach to level design.  If you aren’t creating this style of game Stencyl is probably not the right tool for you.  Perhaps the most glaring flaw with Stencyl is a memory leak that seems to be present.  I often received a message “You have reached 90% of memory usage, please restart”, sometimes quite almost right after loading Stencyl, other times after several hours had passed (it can be fixed though).  There have been a few other times where I wasn’t getting the behavior I expected and had to restart to fix things.  Saving changes is also quite slow and seems to be an all or nothing prospect.  Finally the debugging support is extremely weak.

 

The Verdict

I came into Stencyl expecting one thing and discovered something much different.  I had fairly low expectations, a simple click and build type experience that while accessible and easy to use, it would ultimately prove to be quite limited.  I was wrong.  Stencyl is certainly accessible, and provides a simple drag and drop visual style of programming experience.  What I was shocked at was the flexibility, wealth of tools included and advanced coding options.  Stencyl is not for everyone; if your game isn’t 2D tile/scene based for example.  However if you are just starting out or even if you are an experienced developer creating a relatively simple game, Stencyl might be the perfect tool for you.

 

In fact, Stencyl maybe just maybe became my primary recommendation for new developers looking to get started in game development.  It’s an approachable well documented game engine that has a long runway to explore as your skills improve.

 

The Video

Programming


GFS On YouTube

See More Tutorials on DevGa.me!

Month List