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

 

 

 

This entry in the Closer Look series is a bit different than normal.  First, Blade Engine is very much a work in progress, so expect bugs and flaws and minimal documentation.  Second, it’s actually built over top of an existing game engine, LibGDX.  Finally, it’s a game engine focused on one very specific genre – adventure games.  Given the popularity of hidden object games on mobile these days, there are no doubt a number of people looking for an appropriate engine.  So without further adieu, I present the Bladecoder Adventure Engine, an open source cross platform LibGDX based game engine and editor for creating adventure games.

image

As always there is an HD video version available here.

 

Meet Bladecoder Adventure Engine

 

Blade engine consists of two parts, the underlying game engine and the editor that is layered on top of it.  It is designed in such a way that you can work entirely in the editor and never once right a line of source code.  You assemble your game from a collection of Chapters, Scenes and Actors and added events and actions in the form of verbs.  If you want to modify the fundamental structure of the game itself, you are going to have to jump into the underlying source code.  Fortunately that is an option, as Bladecode Engine is hosted on Github and the source is available under the incredibly liberal Apache 2 license.

 

Blade Engine Features at a Glance:

  • Multi platform support: Android, IOS, Desktop (Windows, OSX, Linux) and HTML
  • Several animation techniques: sprite/atlas animation, Spine (cutout) animation and 3d model animation
  • 3d character support
  • Multiresolution to deal with different densities and screen sizes
  • Multilanguage support
  • Open source and free (as in beer and freedom)
  • Code free game creation possible

 

The heart of Bladecoder is ultimately the editor, so let’s focus there after we cover getting started.

 

Getting Started

 

To get started with Bladecoder you need to have Java and git installed and properly configured.  Bladecoder uses the JavaFX ui library so you will have to use JDK 8 or newer or be prepared to have to configure JavaFX manually in the build process.  You will also require an internet connection for the build process to succeed the first time. To start, from a terminal or command line, change to the folder you want to install Bladecoder and enter:

git clone https://github.com/bladecoder/bladecoder-adventure-engine.git

cd bladecoder-adventure-engine

gradlew build

gradlew run

 

There is an example repository, including the work in progress game The Goddess Robbery available in the repository https://github.com/bladecoder/bladecoder-adventure-tests.  You should probably clone this repository too, as this is perhaps the single biggest documentation source available right now.

 

The Editor

 

Assuming the compilation process went without issue above, you should now see the Adventure Editor, where the bulk of your work will occur.

image

 

Your game is composed of a collection of Chapters, which in turn contain Scenes.  Scenes in turn are a collection of Actors and organized in layers:

image

 

Game Props enables you to set global properties of your game:

image

 

Resolution enables you to quickly create scaling modes for supporting multiple device resolutions ( think Retina ):

image

 

While Assets enables you to import multiple defined assets include audio and music files, texture atlases, 3D models, images and more.

image

 

You organize your scene using the editor available in the center of the window:

image

You can place actors on different layers, define walk paths, etc.  Click the Test button to preview that scene in action.

 

The actual logic of your game is defined on the right hand side of the editor. 

Here you can set properties of your actors:

image

 

Create and edit dialogs:

image

 

Define sounds and animations:

image

 

Clicking the edit icon will bring up the appropriate editor:

image

 

While selecting an animation will preview it in the scene:

GIF

 

Finally Verbs are the heart of your application:

image

 

You can think of verbs an analogous to event handlers, and they can be applied at the world, scene or actor level.  There are also default verbs that will be fired if unhandled.  Think the generic “I don’t know how to use that” messages from adventure games from the past.

 

Let’s look at an example from the Scene, handling the Init verb which is fired when the scene is ready.

image

 

This verb causes the sequence of actions shown at the bottom part of the above image to be fired when the scene init verb is called.  This causes the player to move, a dialog sequence, the player is scripted to drop an item, a state value is changed, etc.  You can create new elements by clicking the + icon:

image

 

And filling out the resulting form.  Each element has a different form associated with it.  Here for example is the result of the Say element:

image

 

Once complete simply click the play or package button:

image

 

Play launches the standard loader:

image

 

This screen can obviously be customized to each individual game.  While package brings up a form enabling you to build your game for a variety of platforms:

image

 

And that essentially is it.

 

Help and Community

This is certainly a weak point of the Bladecoder engine, it’s the result of a single coder, there is minimal help available and if you don’t know how to debug Java code, you will probably end up in trouble, at least at this point in it’s lifecycle.  There is currently no community or forum available for this engine but perhaps that will change in the future.  I spoke with the developer a few times however and he was very responsive and quick with fixes and answers.  He is also on twitter at @bladerafa if you want status updates on the project.

For now documentation consists of a minimal wiki although for the most part the best source of documentation is going to be from following the examples.

 

Summary

Make no mistakes, this is very much an under development engine so expect things to blow up spectacularly at any time.  When it does, you are probably going to be on your own figuring out why as there is no community to fall back on.  All that said this is a surprisingly robust tool that makes the process of creating an adventure game exceedingly simple.  Once the engine matures a little bit it will be an excellent tool for even a non-programmer interested in making adventure games.  For now though if you are competent in Java and interested in making an adventure game, this engine takes care of a hell of a lot of work for you and provides full source code for when it doesn’t.  Plus at the end of the day, the price is certainly good too!

 

The Video

Design Art Programming


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


AppGameKit Studio

See More Tutorials on DevGa.me!

Month List