Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

14. May 2014

 

I’ve had a few users run into this error when trying to run the GameFromScratch C++ Game Dev tutorial:

 

image

 

The program can’t start because MSVCR100D.dll is missing from your computer.  Try reinstalling the program to fix this problem.

 

Fortunately this can be pretty easily fixed, simply download and install the Visual Studio 2010 runtime redistributable.  You can download it here.

 

However…

 

The binaries I include with the SFML tutorial of SFML 1.6 are compiled for Visual Studio 2010 and aren’t compatible with Visual Studio 2012/2013.  Normally this is just a matter of recompiling SFML 1.6 in the newest version of Visual Studio, then linking against those Lib/DLL files.  However this process certainly isn't straight forward as the SFML 1.6 code base was actually targeting for Visual Studio 2008 and amazingly enough, depending on some external libraries compiled for Visual C++ 2005!

 

To be honest, if you are running through this tutorial series, by far the easiest solution is to install Visual C++ 2010 Express.  It can be installed side by side with newer versions.

 

If there is enough demand, I can try to make 2013 compatible binaries that you can include with your project.

Programming ,

10. May 2014

 

First off, sorry for the horrible pun… I wont do it again… at least not today.

 

That said, Unreal may have just flipped the industry on it’s head… or may have just dropped a cleaver marketing gimmick.  By now you have probably heard that Unreal Tournament development will be done in the open.  At least for Unreal Engine subscribers it will be.  Basically if you subscribe to Unreal Engine for 19$ a month, you get Unreal Tournament for free.  The biggest part of the announcement is you get access to a Github repository, so you can watch the game develop, or perhaps even get involved!

 

In Unreal’s own words:

 

HERE’S THE PLAN:
  • We’ve created a small team of UT veterans that are beginning work on the project starting today.
  • From the very first line of code, the very first art created and design decision made, development will happen in the open, as a collaboration between Epic, UT fans and UE4 developers. We’ll be using forums for discussion, and Twitch streams for regular updates.
  • If you are a fan and you want to participate, create a free account and join the forum discussion.
  • All code and content will be available live to UE4 developers on GitHub.
  • The game will be true to its roots as a competitive FPS.
  • Development will be focused on Windows, Mac and Linux.

 

SO WHAT’S THE CATCH?
  • It will take many months until the game is playable by gamers. This is real development from scratch.
  • When the game is playable, it will be free. Not free to play, just free.
  • We’ll eventually create a marketplace where developers, modders, artists and gamers can give away, buy and sell mods and content. Earnings from the marketplace will be split between the mod/content developer, and Epic.  That’s how we plan to pay for the game.

 

So why do I find this move so impressive?  There are a couple reasons…

 

First I was wondering if I would maintain my subscription.  If I am not actively developing in Unreal Engine, was there any point in paying 19$ a month?  I, and many others, wondered if Unreal would keep a stream of content coming that would keep developers paying.  To actively open up a potentially AAA game’s development process is certainly a good hook to keep me watching.  ( Plus, they’ve done a pretty good job keeping the content coming… more on that in a second ).

 

Second, quasi-open sourcing a game could be a brilliant strategy.  Indie developers get to contribute to a large project, probably beyond the scope of what they would otherwise be able to participate in.  Unreal of course gets a ton of free development effort, but retains dictatorial control that large scope games need.  Of course they will have to be selective about what they commit to their main trunk and may bruise some egos, so this could be a bit of a balancing act and will require additional resources on their end, but the trade-offs are probably worth it.  I would generally think this would be mostly a read only process, basically just Unreal developing a game and the community watching.  However they have recently accepted a number of community fixes into the Unreal engine base, so I don’t think this is just marketing.  If nothing else, many indie game developers get the opportunity to eavesdrop on a AAA game’s development, including developer discussions and twitch streams, for a price tag of 19$ a month.

 

The Unreal Tournament github repository is now online:

image

Of course, this is a from scratch project, so have very little expectations for now!

 

 

Finally and perhaps most disruptively “create a marketplace where developers, modders, artists and gamers can give away, buy and sell mods and content. Earnings from the marketplace will be split between the mod/content developer, and Epic”.  This point is MASSIVE.  Basically Unreal are releasing a F2P title where the microtransactions come from the community.  This is a powerful concept, enabling artists and coders to actually get paid for their work, using the exact same tools and process as the parent.  Just as artists and programmers can make a living providing assets to the Unity store, in the future, they will potentially make a living contributing to a game.  A game they potentially helped create.

 

 

Oh, remember earlier where I said Unreal would have to keep a pretty steady stream of updates to keep people subscribed?  Well, impressively enough, they have been.  Since the 1.1 patch ( adding XBox One and PS4 support ) there have been a half dozen new tutorials added, covering topics such as Localization, skeletal meshes and Blueprint complexity management.  Additionally they added a SciFi hallways level:

SciFi Screenshot 1

 

The marketplace is quickly being populated with professional quality examples to work from.  You can read more about the design process here.

 

I have to say Unreal are impressing the hell out of me.  They are taking bold risks and truly are throwing their resources at this, it’s not some half assed indie release like CryEngine or prior UDK releases… this is a slick well supported product and most importantly a thriving community.  Unreal are willing to try some very disruptive strategies and we should applaud them for it.

 

I for one will be keeping my 19$ a month subscription going.

 

Oh yeah, and on that topic, they’ve also laid out a blueprint ( ugh, bad accidental pun! ) for future Unreal development.  You can check it out here on Trello.  This transparency is certainly a good thing.  You can also vote and comment on features that are most important to you, a nice feedback loop with subscribers.

News, Programming ,

10. May 2014

 

Sorry for the quietness in these parts of late, I recently purchased a new place and have been taken off line for most of the last week as a result.  This explains the lack of posts here on GameFromScratch.com.  Fortunately things should get back to normal starting early next week.

 

On the bright side, I have MUCH more space than before and for better or worse, I now have natural light where I work.  Perhaps I will no longer burst into flames when coming into contact with the stuff!

 

Below is ground zero for GameFromScratch, or at least 90% there, still some unpacking to be done.  Although reality is, I still spend the majority of my time on the move.

 

1

 

2

 

3

 

I really need a good solution for cable management.  For now I am just going to use black twist ties, but that always gets annoying.  I am also in the market for a small side table with wheels, as I’ve got a couple machines still wrapped up and unusable for now.  Nice to not be completely cluttered for now though at least.

Totally Off Topic

4. May 2014

 

Last year the Torque2D was open sourced under an MIT license by GarageGames.  Torque2D is a cross platform 2D game engine.  Originally it only targeted Windows, OSX and iOS.  Now fortunately support for Android, Web and Linux have been added with the release of version 3.0.

 

From the release notes, here is what’s new:

What’s New in 3.0


The following is a summary of the major changes and additions:


Android, Linux, and Web Support

The major focus of this release brings several additional platform publishing options for your game or application. T2D truly delivers on cross platform support, making it easy with one codebase to reach many different audiences on many different devices.

64-bit Applications

In addition to the standard 32-bit support we’ve always had, the engine can now compile as a native 64-bit application for platforms that support it.

Named Image Cells and Frames

Until now, image frames have always been referenced using a numerical index. Now, developers have the opportunity to give explicit ImageAsset cells specific names. Those names can then be used with all SceneObject derived classes that consume ImageAssets.

<ImageAsset 

  1.     AssetName="soldierWalk"
  2.     ImageFile="@assetFile=soldierWalk.png">   
  3.     <ImageAsset.Cells> 
  4.         <Cell RegionName="walk1" Offset="2 2" Width="103" Height="66"/> 
  5.         <Cell RegionName="walk2" Offset="179 100" Width="37" Height="35"/> 
  6.         <Cell RegionName="walk3" Offset="2 70" Width="65" Height="31"/> 
  7.         <Cell RegionName="walk4" Offset="161 137" Width="36" Height="41"/>         
  8.     </ImageAsset.Cells> 
  9. </ImageAsset> 
  10. <AnimationAsset 
  11.     AssetName="soldierWalkAnim"
  12.     Image="@asset=ToyAssets:soldierWalk 
  13.     NamedAnimationFrames="walk1 walk2 walk3 walk4"
  14.     AnimationTime="1" /> 

Skeletal Animation

We are pleased to announce that an initial implementation for skeletal animation is now available. The first format supported comes from the animation program Spine.
t2dtutorials.com/img/SpineToy.png
Leap Motion Controller

The Leap Motion controller takes input from hands, fingers, and small tools that are moved just above its surface and provides their absolute position and rotation through the Leap SDK. Torque 2D offers built in integration and now includes a demo toy to show off how it works.
t2dtutorials.com/img/LeapToy.png
Xbox 360 Controller

Gamepad support has always been part of the engine, but now the necessary code to use an Xbox 360 controller with T2D has been added.

JSON Format for TAML

Joining XML and binary, developers can how serialize their game objects and scenes in the JSON format, with the engine being able to read-in or write-out this format as easily as the others.

 

  1. "Sprite": { 
  2. "SceneLayer": "31", 
  3. "Size": "100 75", 
  4. "BodyType": "Static", 
  5. "BlendColor": "SlateGray", 
  6. "Image": "@asset=ToyAssets:highlightBackground", 
  7. "Frame": "0"
  8.     } 

ConsoleMethodWithDocs

A major undertaking in the codebase, the vast majority of TorqueScript binding methods and global functions have moved into their own header files. This makes the engine code much easier to read and allowed us to further integrate Doxygen support for a comprehensive reference guide available in the wiki.

ScriptObject Behaviors

Behavior support was added to the ScriptObject class. If you enjoy writing behaviors, now there is an engine class outside of the Scene and SceneObjects which can use them.

Polar Coordinate Changes

One of the few changes made that would break any of your existing scripts - polar coordinates have been standardized throughout the engine to follow the typical polar axis convention where 0 degrees is horizontal and to the right.

New Sandbox Toys

A few more toys were added to the Sandbox, giving new users even more practical examples to learn from. These include AudioToy, AngleToy, LeapToy, and SpineToy.
t2dtutorials.com/img/AudioToy.png

Change List


Below is a list of all changes that have been made to the development branch of the Torque2D repository since the 2.0 release and have now been pushed to the master branch and tagged as Torque 2D 3.0.
TAML supports reading and writing in JSON format
Batch renderer now works exclusively with triangles instead of quads
Fixed SceneObject.applyForce and applyLinearImpulse
Added signum convenience function (PR #56)
New Gui Object: GuiGridCtrl (PR #9)
Added missing TorqueScript methods to ParticleAsset/Emitter/Player, renamed a few static fields for consistency (breaking change) (PR #68)
Fixed ImageAsset typo - image width and height were swapped (PR #70)
All picking modes for CompositeSprite are now functional (PR #69)
TextureManager fix - replaced call to use expandPath (PR #83)
ParticleAsset creation fix - now writes out correctly to TAML (PR #84)
ParticlePlayer play and stop functions now correctly pause and unpause emitters (PR #85)
Added functions to get the explict width and height of cells to ImageAsset (PR #88)
Fixed AABB size in ImageFont (PR #97)
Fixed TAML bug with ImageFont (PR #99)
Fixed TAML bug with ShapeVector (PR #104)
Added Mac OSX 10.6 support (PR #101)
Added linear interpolation and smooth step functions, SceneWindow now uses these (PR #95)
OpenAL streaming audio fix (PR #106)
OpenAL pause and unpause audio fix (PR #115)
OpenAL shutdown fix (PR #114)
PointForceController getPosition definition fix (PR #110)
SimXMLDocument crash fix (PR #113)
Replaced most ConsoleMethod (and functions) with ConsoleMethodWithDocs for easier Doxygen reading, moved most console methods into their own ScriptBinding.h files. (PR #116)
Behavior support for ScriptObject (PR #121)
Angle/polar coordinate issue fixes (breaking change), AngleToy added to Sandbox (PR #123)
Input bug fix for OSX (PR #125)
Fix assert conditional in consoleNamespace.cc (PR #126)
Android platform support added
Xbox 360 controller support (PR #136)
Leap Motion controller support, LeapToy added to Sandbox (PR #137)
Added missing Mutex to StringTable::lookupn (PR #127)
Asset support for named cells and frames (PR #139)
Bugfix for SceneObject::getContacts (PR #142)
Fixed deleting a clone of an object breaking the original object (PR #143)
Fixed bug that prevented scene controllers from being read by TAML (PR #145)
Initial implementation of Spine support, SpineToy added to Sandbox (PR #146)
Doxygen file cleanup (PR #148)
Fixed some Xcode compiler warnings (PR #150)
64-bit platform support (PR #154)
Fixed GUI object namespace issue (PR #152)
Fixed crash when executing FileDialogs (PR #153)
Linux platform support (PR #138)
AudioToy added to the Sandbox
Exposed method CompositeSprite::getSpriteLogicalPosition in TorqueScript (PR #155)
Emscripten platform support (PR #157)
Fixed TAML binary writer crash (PR #158)
Fixed compile errors and warnings resulting from the Xcode 5.1 update (PR #159)
Windows platform fixes (PR #168)
SkeletonObject now respects scene layer depth settings (PR #171)
Named cell and frame improvements (PR #172)
Fixed iOS7 bug with audio not playing (PR #175)
Arm64 support (PR #176)
Removed PVRTexTool files (PR #177)
Android platform fixes (PR #174)
Visual Studio 2013 solution files added (PR #182)
Behavior Connection bug fixes (PR #183)

 

Torque2D is available on Github.

 

I’ve personally never checked out Torque2D, one of the biggest drawbacks was the limited platform support, which has been solved by this release.  My other major caveat is their use of a proprietary scripting language, something I am generally not a fan off.

News ,

4. May 2014

 

You know one of the things that suck about working in Java?

 

Java.

 

Or more precisely the Java runtime.  The need to have the Java runtime pre-installed in order to run your game is a bit of a pain.  Fortunately Badlogicgames, the people behind LibGDX have released Packr.

 

In their own words:

Packages your JAR, assets and a JVM for distribution on Windows (ZIP), Linux (ZIP) and Mac OS X (.app), adding a native executable file to make it appear like the app is a native app. Packr is most suitable for GUI applications.

 

To be honest, that explanation kinda sucks, their description on Reddit is much better.

This has been a pain point for a few of our users, though Minecraft made pretty much anyone on this planet install Java anyways :)

I wrote a little tool called packr which does the following:

  • bundle your jar/assets with an embedded JRE
  • add a native executable for the respective platform to make your app look native
  • minimize the JRE (zipped: 23mb, extracted 40mb)

This should make the user experience a bit better, as there aren't any things the user needs to have installed before trying your game/app. All they need to do is download a ZIP/App Bundle and execute the native executable.

It's very easy to use, either via CLI arguments, a JSON config file, or by invoking it directly from code (it's really a library).

 

There are a couple limitations right now:

    • Icons aren't set yet on any platform, need to do that manually.
    • Windows is 32-bit only, Linux is 64-bit only, Mac OS X is 64-bit only
    • JRE minimization is very conservative, depending on your app, you can carve out stuff from a JRE yourself, disable minimization and pass your custom JRE to packr

 

If this sounds useful to you, you can learn more at the Packr github page.

News ,

Month List

Popular Comments

A Closer Look at the Godot Game Engine
Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


4. January 2015

 

Gamefromscratch has a long running series taking an indepth look at various game engines available.  Today we are going to look at the Godot game engine, an open source C++ based game engine with a complete Unity-esque world editor.  Godot runs on Windows, Linux and Mac platforms and can target all of those, plus iOS, Android, PS3 and PS Vita, NaCL with HTML5 and Windows Phone both being in development.

 

In Godot’s own words:

Godot is an advanced, feature packed, multi-platform 2D and 3D game engine. It provides a huge set of common tools, so you can just focus on making your game without reinventing the wheel.

 

That description is incredibly apt as well, you will certainly be surprised by just how many tools are included.  Now let’s jump right in!

 

There is a video on this post available here (and embedded at bottom of the page) which goes in to a bit more detail.

 

The Editor

 

You get started with Godot by downloading the executable from the downloads page.  You probably expect this to be an installer, but you would be wrong.  Instead when you run it you get the Project Manager:

image

 

Here you can either create a new project or load an existing one.  Finally once you’ve selected or created, you are brought to the editor:

image

 

This is where the magic happens.  The above screenshot is of the Platformer demo being edited.  The left hand window is where your scene is composed.  As you can see from the four tabs above, you can work in 2D, 3D, Script editing or browse the built in help in this window.  The top left icons are actually menus and a lot of the functionality and tools are tucked away behind Scene and Import.

 

The top right hand dialog is your scene graph:

image

 

Here you can see ( and create/instance ) the items that make up your world.  Simply click the New Icon to add a new items to the world, or the + Icon to add a new instance instead.  The other icons are for wiring scripts and signals (events) up to the objects in your world.

 

Below the scene graph, you’ve got the Inspector window, which enables you to set properties of objects in your scene.  As you can see from the screen shot, Godot takes a very modular/component approach which is quite popular these days:

image

 

This enables you to visual inspect and edit properties of your game objects.  It also represents one of the first flaws of Godot… some of the controls are just awkward to use.  For example if you don’t hit enter after editing a text property, the values are lost.  Additionally modifying numeric fields can be a pain in the ass at times.  It’s all stuff that can be fixed with time ( Godot was only open sourced about a year ago after all ) but for now its clunky and somewhat annoying.

 

Coding

 

So that’s the visual editor… what about code? 

 

Well the majority of your programming is going to be done in GDScript, using the included editor.  GDScript is a Python-esque proprietary scripting language.  I don’t generally like this approach as it makes all the existing tools and editors worthless, lose the years of bug fixing, performance improvements, etc…  while forcing a learning curve on everyone that wants to use the engine.  That said, the idea behind a scripting language is they should be easy to use and learn.

 

The authors explained their decision in the FAQ:

 

The short answer is, we'd rather a programmer does the small effort to learn GDScript so he or she later has a seamless experience, than attracting him or her with a familiar programming language that results in a worse experience. We are OK if you would rather not give Godot a chance because of this, but we strongly encourage you to try it and see the benefits yourself.

The official languges for Godot are GDScript and C++.

GDScript is designed to integrate from the ground to the way Godot works, more than any other language, and is very simple and easy to learn. Takes at much a day or two to get comfortable and it's very easy to see the benefits once you do. Please do the effort to learn GDScript, you will not regret it.

Godot C++ API is also efficient and easy to use (the entire Godot editor is made with this API), and an excellent tool to optimize parts of a project, but trying to use it instead of GDScript for an entire game is, in most cases, a waste of time.

Yes, for more than a decade we tried in the past integrating several VMs (and even shipped games using them), such as Python, Squirrel and Lua (in fact we authored tolua++ in the past, one of the most popular C++ binders). None of them worked as well as GDScript does now.

More information about getting comfortable with GDScript or dynamically typed languages can be found here.

 

That covers the why anyways, now let’s look at the language itself.  As I said earlier, it’s a Python like (whitespace based) scripting language.  Let’s look at an example from the included demos:

extends RigidBody2D


const STATE_WALKING = 0
const STATE_DYING = 1

var state = STATE_WALKING
var direction = -1
var anim=""
var rc_left=null
var rc_right=null
var WALK_SPEED = 50

var bullet_class = preload("res://bullet.gd")

func _die():
   queue_free()

func _pre_explode():
   #stay there
   clear_shapes()
   set_mode(MODE_STATIC)
   get_node("sound").play("explode")
   

func _integrate_forces(s):

   var lv = s.get_linear_velocity()
   var new_anim=anim

   if (state==STATE_DYING):
      new_anim="explode"
   elif (state==STATE_WALKING):
      
      new_anim="walk"
      
      var wall_side=0.0
      
      for i in range(s.get_contact_count()):
         var cc = s.get_contact_collider_object(i)
         var dp = s.get_contact_local_normal(i)
         
         if (cc):
         
            
            if (cc extends bullet_class and not cc.disabled):
               set_mode(MODE_RIGID)
               state=STATE_DYING
               s.set_angular_velocity(sign(dp.x)*33.0)
               set_friction(true)
               cc.disable()
               get_node("sound").play("hit")
               
               break
            

         if (dp.x>0.9):
            wall_side=1.0
         elif (dp.x<-0.9):
            wall_side=-1.0
            
      if (wall_side!=0 and wall_side!=direction):
      
         direction=-direction
         get_node("sprite").set_scale( Vector2(-direction,1) )       
      if (direction<0 and not rc_left.is_colliding() and rc_right.is_colliding()):
         direction=-direction
         get_node("sprite").set_scale( Vector2(-direction,1) )
      elif (direction>0 and not rc_right.is_colliding() and rc_left.is_colliding()):
         direction=-direction
         get_node("sprite").set_scale( Vector2(-direction,1) )
         
         
      lv.x = direction * WALK_SPEED
         
   if( anim!=new_anim ):
      anim=new_anim
      get_node("anim").play(anim)
            
   s.set_linear_velocity(lv)


func _ready():
   rc_left=get_node("raycast_left")
   rc_right=get_node("raycast_right")

 

As someone raised on curly braces and semi colons it can take a bit of time to break muscle memory, but for the most part the language is pretty intuitive and easy to use.  You can see a quick language primer here.

Remember earlier I said the code editor was built into the engine, let’s take a look at that now:

image

 

As you can see, the editor does provide most of the common features you would expect from an IDE, a personal favorite being auto-completion.  Features like code intention, find and replace and auto indention are all available, things often missing from built in editors.   Like dealing with the Inspector window though their can be some annoyances, like the autocomplete window appearing as you are trying to cursor around your code, requiring you to hit Escape to dismiss it.  For the most part though the editing experience is solid and hopefully some of the warts disappear with time.

 

Now perhaps the biggest deal of all:

image

Debugging!  This is where so many home made scripting languages really suck, the lack of debugging.  Not Godot:

image

You can set breakpoints, step into/over your running code and most importantly inspect variable values and stack frames.  Once again, it’s the debugging experience that often makes working in scripting languages a pain in the ass, so this is nice to see!

 

Hey, What about C++???

 

Of course, one of the big appeals of Godot is going to be the C++ support, so where exactly does that come in?  Well first and most obviously, Godot is written in C++ and fully open source under the MIT license ( a very very very liberal license ), so you can of course do whatever you want.  I pulled the source from Github and built without issue in Visual Studio 2013 in just a few minutes.  The build process however is based around Scons, which means you have to Python 2.7x and Scons installed and configured, but neither is a big deal.

 

What about extending Godot, that is what the majority of people will want to do.  Well fortunately it’s quite easy to create C++ extensions, although again you need Scons and have to do a bit of configuration, but once you’ve done it once assuming you’ve got a properly configured development environment the process should be quick and mostly painless.  From the wiki page here is a sample C++ module:

 

Sumator.h

/* sumator.h */
#ifndef SUMATOR_H
#define SUMATOR_H

#include "reference.h"

class Sumator : public Reference {
    OBJ_TYPE(Sumator,Reference);

    int count;

protected:
    static void _bind_methods();
public:

    void add(int value);
    void reset();
    int get_total() const;

    Sumator();
};

#endif

Sumator.cpp

/* sumator.cpp */

#include "sumator.h"

void Sumator::add(int value) {

    count+=value;
}

void Sumator::reset() {

    count=0;
}

int Sumator::get_total() const {

    return count;
}

void Sumator::_bind_methods() const {

    ObjectTypeDB::bind_method("add",&Sumator::add);
    ObjectTypeDB::bind_method("reset",&Sumator::reset);
    ObjectTypeDB::bind_method("get_total",&Sumator::get_total);
}

Sumator::Sumator() {
    count=0;
}

 

Then in your script you can use it like:

var s = Sumator.new()
s.add(10)
s.add(20)
s.add(30)
print( s.get_total() )
s.reset()

 

If you inherit from Node2D or a derived class, it will be available in the editor.  You can expose properties to the inspector and otherwise treat your module like any other Node available.  Remember though, for productivity sake, you should really only be dropping to C++ as a last resource.  It is however quite simple to do.

 

Nodes, Nodes and more Nodes

At the heart of Godot, the world is essentially a tree of Nodes, so I suppose it’s worthwhile looking at some of the nodes available and how they work.  From the scene graph window, you add a new node to the world using this icon:

image

 

Next it’s a matter of picking which type, which could of course include modules you created yourself in C++.

image

 

As you can see from the small portion I’ve shown above, there are a LOT of built in nodes already available.  From UI controls, to physics controllers, path finding and AI tools, bounding containers, video players and more.  Essentially you create your game by composing scenes, which then are composed of nodes.  Once you’ve created a node you can then script it.  Simply select your node in the scene graph and then click the script icon:

image

 

Then a New Script dialog will be displayed:

image

 

And your script will be created:

image

 

As you can see, the script itself inherets from the node type you selected.  You can now script any and all logic attached to this particular Node.  Essentaily your game logic is implemented here.

 

In addition to wiring up scripts to game nodes, you can also wire up Signals.

image

 

Signals can be thought of as incoming events:

image

 

HELP!

 

So, what about Help then?  Well this is both a strength and weakness of Godot.  As you saw earlier, there is actually an integrated help tab.  You can look it up any time, or use press SHIFT + F1 while coding to get context sensitive help:

image

It’s invaluable, but unfortunately the resulting help file is often just a listing of methods/parameters and nothing more.  I often instead just keep the class reference from the Wiki open in a browser window.  For an open source project, the reference is pretty good, but it could still certainly use a lot more love.

 

Next are the tutorials, there’s a fairly good selection available on the Wiki but I think a good in-depth beginner series is really needed.  To someone that just downloaded Godot and is thinking “now what”… that presents a challenge. That said, I will probably be creating one, so this shouldn’t be an issue in time!

 

Finally, and perhaps most valuably, there are several demos included:

image

 

Publishing

 

So, once you’ve finished your game, how do you publish it to the various available platforms?  Well for starters you click the Export button:

image

 

You also need an export template, which is available from the Godot downloads site.  Additionally you need to  configure the tool chain for each platform, such as the Android SDK for Android, XCode for iOS ( and a Mac!  You can’t end run around the needing a Mac for iOS development requirement unfortunately), etc.  But the process is spelled out for you and they make it pretty easy.

 

Summary

 

I haven’t even really touched upon the plethora of tools tucked away in the editor…  need to import a font, there’s a tool for that.  There’s an improved Blender COLLADA plugin which just worked when I tried it.  There’s a tool for mapping controls to commands, there are tools for compressing and modifying textures on import, for modifying incoming 3D animations, etc…  Basically if you need to do it, there is probably a tool for it shoved in there somewhere.

 

On the other hand, the process itself can be pretty daunting.  Figuring out how to get input, a script’s life cycle etc isn’t immediately obvious.  It really is an engine you have to sit down with and just play around.  Sometimes you will hit a wall and it can be pretty damned frustrating.  However, it’s also a hell of a lot of fun and once it starts to click it is a great engine to work in.

 

I definitely recommend you check out Godot, especially if you are looking for an open source Unity like experience.  That said, calling this a Unity clone would certainly be doing it a disservice, Godot is a great little game engine on it’s own accord that deserves much more exposure.

 

The Video Version

 

Click here for the full resolution 1080p version.

Programming , , ,

blog comments powered by Disqus

Month List

Popular Comments