Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


14. January 2016

 

Welcome to another episode in the “Closer Look at” game engine series.  The closer look series is a combination of getting started tutorial and review to help you determine if a game engine is the right fit for you.  Today we are looking at the QICI Engine and HTML5 game engine built over top of the Phaser framework which itself uses the Pixi graphics renderer. Normally when I work with a game engine, I have to spend several weeks with it before I can put together one of these guides.  With QICI, it took substantially less time, only a couple days, to come to terms with the engine.  This isn’t a slight on QICI in the slightest.  First, I am a big fan of the Phaser engine it is built on, so this gave me an immediate familiarity.  Second, it is just an extremely good, well designed, capable and well documented game engine.  Hmmm, bit of a spoiler there I suppose, but I really like the QICI engine.  Read on to find out why.

 

As always, there is an HD video version of this guide available here.

 

A Tour of the QICI Engine

The engine is available for download here.  It is bundled as a zip archive while available on Github (the code is not directly on Github however, but is included within the archive).  Simply extract the archive contents then run start-win.bat or start-mac.command depending on platform.  The engine is built around NodeJS  and Node must be installed before using the QICI engine.  The code is released under the MIT license, making QICI both free as in beer and free as in freedom.  There are future hooks for paid plugins, but currently all plugins are available for free as well.

Once you run QICI, it loads a browser window and a fairly humble project management screen:

image

Here you load existing or create new projects.  Creating a project is simply a matter of selecting an empty directory and clicking Create.

Once you’ve loaded or created a project, you will be brought to the primary editing window:

image

 

The editor is pretty typical of modern component based game engines.  You’ve got an editing surface for composing screen elements, a hierarchy view containing your current scenes contents, a project view for managing the assets in your project and finally an inspector view that updates dynamically based upon the current selection.  For a web based editor, the UI is silky smooth and doesn’t feel clunky.  For example, right click context menu support is prevalent and intuitive:

image

The editor supports common features like drag and drop, tool tips, resizes well in the browser and frankly doesn’t feel like a web app most of the time.  I encountered the occasional glitch where the cursor got stuck in the wrong mode, but they were uncommon and easily avoided.  Frankly, if you weren’t in a web browser, you would have no idea this was a web application.

You can also change the layout to work in Portrait mode, like so:

image

 

The UI can be switch between English and Chinese via the Language menu.  You can also configure the editing window to mirror common iOS device dimensions:

image

Oddly, no Android love.  Not really a big deal, as this just sets the dimensions and a Free Aspect option exists.

 

Creating Scenes

Your game project is composed of one or more scenes.  We can add, reload and save scenes via the project menu.

image

The following settings are configurable on the project by project basis:

image

Once saved, a Scene appears under states in your assets view:

image

 

Scenes are composed of the following elements:

image

 

To create a new game object, simply select it from the list and position it on screen.  Here for example is a sprite:

image

 

There are widgets for placement, free or axis confined, scaling and free scaling, but oddly enough, not rotation.  To perform rotation, you need to use the Inspector window:

image

As you can see, the Inspector has editors for the various components that go into our game object.  In this case, a Sprite contains a Transform and Sprite component.  You can add additional components via the Add Component button:

image

Somewhat confusingly, you can also add components in another manner, as we will see shortly when we attach a script.  You can add additional functionality via Plugin, like so:

image

 

Let’s add an Arcade Physics controller to our game, and make our sprite a physics object.  Select Plugins->Plugin Manager, then in Inspector enable Arcade Physics.  Next click Save and Reload:

image

Now if we click Add Components in the Inspector with our sprite selected, we get:

image

 

Select Plugins->Arcade->RigidBody.  You will see in Inspector, we now have an additional component to configure.

image

 

Set the Gravity Y value to 10, and hit the play icon and you should see:

GIF

 

As you can see, you can preview the running of the scene directly in the editor.

As you may have noticed from the game objects available, QICI has robust UI support.  You can easily use hierarchies of components to form complex UIs, like so:

image

 

An impressive number of layout properties are exposed to the inspector:

image

Assets can be imported into the engine using drag and drop, or by simply copying them into the folder in the underlying file system and click reimport in the UI.

 

Coding in QICI Engine

What might not be immediately obvious is how you actually code in QICI and of all the features, this one is probably the least intuitive.  You code by attaching behaviors to your game entities.

Start by right clicking the Scripts folder in the assets view and select New JavaScript File:

image

 

Name your script and you will see that a stub script has been created for you, you can preview the code in the Inspector:

image

 

At this point you are probably best off firing up your favourite JavaScript editor and opening the generated script.  You can jump to the script directly right clicking the script and select Open in Local File Explorer:

image

 

You can however edit using the built in editor if you prefer:

image

All scripts are qc.Behaviors.  You will notice that this class implements a number of callback methods for various points in the games lifecycle such as awake, onDown, render, onDestroy, etc.  By implementing these methods, we add functionality to our script.  Consider this simple script, that causes a button to change it’s text to “Clicked” when clicked:

var ButtonHandler = qc.defineBehaviour('qc.engine.ButtonHandler', qc.Behaviour, function() {
    // need this behaviour be scheduled in editor
    //this.runInEditor = true;
}, {
    // fields need to be serialized
});

ButtonHandler.prototype.onClick = function() {
  
    this.gameObject.find("Text").text = "Clicked";
};

 

Now attach this script to the component by dragging and dropping, like so:

GIF2

And you will see a new component has been added to our Button:

image

 

Values can easily be exposed to the editor, like so:

var ButtonHandler = qc.defineBehaviour('qc.engine.ButtonHandler', qc.Behaviour, function() {
    this.meaning = 42;
}, {
meaning : qc.Serializer.INT
});

ButtonHandler.prototype.onClick = function() {
  
    this.gameObject.find("Text").text = "Clicked";
};

Resulting in:

image

 

Behind the scenes however, Phaser is always there.  You can actually access Phaser directly using gameObject.phaser, like so:

ButtonHandler.prototype.onClick = function() {
  
    this.gameObject.find("Text").text = "Clicked";
    alert(this.gameObject.phaser.game.width);
};

 

Therefore, if you are familiar with Phaser, you should be immediately comfortable with QICI.  For more help with Phaser, I have already created a fairly comprehensive tutorial series.

 

Documentation and Community

This is a very new project, just shipping the end of last year.  There isn’t much of a community per say, but there is a fledgling question forum.  Hopefully in time a proper community forms.

 

In terms of documentation however, QICI Engine is good, shockingly good in fact.  There is a complete guide available here walking you through the fundamentals and primary components of QICI.  With the exception of a good scripting guide and a document on program flow, I found everything I was looking for in sufficient detail to accomplish what I needed.  There is also a very good searchable reference guide available here.  Between the two, and with prior Phaser experience (which is also remarkably well documented), I had no trouble whatsoever getting up to speed.  Additionally there is a pretty good collection of examples available here on Github

Frankly, for a young open source project, this is hands down the best documentation I have ever seen.  Kudo QICI team.

 

Summary

This is a game engine that takes one of my favourite HTML5 game engines (Phaser) and adds an incredibly polished layer of tooling on top of it.  Additionally a straight forward component system is added, while not getting in the way of the underling libraries.  If you are looking for a 2D HTML5 library, especially if you are already familiar or working with Phaser, this is a project you absolutely have to check out.  It is robust, straight forward, well documented and well designed.  Aside from the lack of community, there really isn’t much more you could ask of this great new engine!

I enjoyed my time with QICI and will be exploring it more in the future.  Let me know if this engine interests you and if you would like to see some tutorials from GameFromScratch.

 

The Video

Programming , ,

blog comments powered by Disqus

Month List

Popular Comments

C# comes to Unreal Engine
Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


Home > News >

24. October 2014

 

On a daily basis I use dozens of different programming languages.  Some languages are certainly better than other languages at certain tasks, while other languages truly shine on certain platforms.  Some languages are more portable than others, others are more customizable while some can be faster.  All that said, when all other things are equal and I need to just pick a language, the one I go to is generally C#.  C# just strikes that right balance for me, straddling the line between low level and productivity, convenience and speed, functional and procedural, for me at least.  This news then is welcome, for me at least. :)

 

Xamarin, the maker’s of Mono, a cross platform open source version of the .NET runtime and framework (Perhaps most famously known as the language technology that underpins Unity)  have announced they are bringing it to Unreal Engine.  Here are some of the features and benefits of Mono for Unity:

 

Hot Reload

 

We fully support Unreal Engine's Hot Reload functionality.

This means that whenever you rebuild your C# code in Xamarin Studio, your changes are immediately reloated into the Unreal Editor. The changes are also reflected with running games in the editor, so you can quickly iterate on your design.

On fast machines, the process of rebuilding the C# code and reloading it live takes less than a second. It feel instantaneous.

 

Xamarin Studio

While hard core hackers are happy editing their game code with vi or emacs and have the hot reload functionality do all the work for them, we have also provided a nice integration with the MonoDevelop (and Xamarin's branded version, Xamarin Studio).

It provides a first-class IDE with rich, accurate code completion, and powerful refactoring and analysis tools.

 

Debugging

Full support for C# debugging is included. Simply launch your game from Xamarin Studio as a standalone editor or mobile preview process, and it will connect to the runtime debug engine, giving you full access to a rich suite of abilities to inspect and debug your code.

Seamless Blueprint and Editor Integration

Your C# classes that are exposed to Unreal Engine are fully accessible from Blueprint and the Unreal Editor, just like Blueprint-accessible C++ classes.

You can continue using Blueprint for simple logic and use C# when things get more complicated.

And you can consume your C# classes from Blueprint.

 

Mixed C#/C++/Blueprint Solutions

The same tool that we use to generate bindings to Blueprint-exposed Unreal Engine APIs is integrated into Unreal Build Tool, and will automatically generate bindings to all of your Blueprint-exposed C++ gameplay code and engine modifications.

 

Native Access

In addition to the automatically generated bindings to Blueprint-exposed Unreal C++ code, the Mono runtime allows accessing any native APIs, including custom C/C++ code and the native platform API.

You can manually bind C APIs using Platform Invoke services, or use CppSharp to generate bindings to C++ APIs.

 

Async Programming

The Getting Started tutorial shows the low-level approach to defining behaviors, but this approach can become cumbersome when defining more complex behaviors and AI. Luckily, this task can be simplified with async programming, a C# compiler feature that rewrites what appears to be linear code into a state machine.

For more details about how this helps writing complex gameplay logic, see our overview of async programming.

 

API Profile

The Mono Mobile Profile is the core API profile in the support for Unreal Engine.

The Mono Mobile Profile removes a number of bloated .NET features including System.Configuration support from the Base Class Libraries. This is the same API profile used by Xamarin's Android, iOS and Mac products.

Note: The Mobile Profile is not ABI compatible with existing assemblies compiled for a different profile (like the .NET desktop, Silverlight or Windows Phone). You mustrecompile your source code to generate assemblies targeting the Mobile profile.

A full list of the assemblies in our Mobile framework profile can be found here.

 

Portable Class Libraries

You can use Portable Class Libraries with Xamarin's Unreal Engine support. This allows the same binary library to be shared across a wide range of platforms without code modifications.

To learn more about using Portable Class Libraries with Xamarin, read our Introduction to Portable Class Libraries document.

 

There are a couple limitations.  It’s based on .NET up to 4.5, with a smattering of .NET 5 features.  Well, anync, which is frankly the .NET 5 feature.  Perhaps the biggest limitation is it only has access to code from the Blueprint API.  Given that the Blueprint API has access to just about everything C++ does, this isn’t perhaps the limitation it sounds like.  If you want to make more C++ accessible to .NET you need to use CppSharp.  Additionally, Unreal AND Mono need to be available on the targeted platform, although frankly, Mono is available just about everywhere these days.  However, right now only Windows and Mac are supported, with other platforms under development.

 

Oh yeah, there is of course one other big side effect… money.

 

To redistribute code written with Mono for Unreal Engine, you must have a commercial license to the Mono runtime. These licenses are available from Xamarin for Mac, Android and iOS online, and you can request Windows licenses through support.

 

This of course is completely reasonable.  People make their money selling software, so obviously they have to sell their software.  That said, I’ve always found Xamarian’s licensing to be a bit awful.  There are almost unique in the development world for not offering a (real) free version for non-commercial development and this is a huge mistake IMHO.  The lack of a free edition makes open source software around their tools pretty much non-existent.  Of course you can open source work made with Xamarian tools, but good luck building a community around a commercial only development product.

 

That said, this is still an interesting development and one more feather in Unreal Engine’s cap.  Given that Unity is moving away from Mono and developing their own runtime, it’s not entirely shocking that Xamarin made this move.  It is somewhat ironic that the Unreal Engine .NET runtime will be substantially newer and more complete than Unity’s!

News , ,

blog comments powered by Disqus

Month List

Popular Comments