Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
3. June 2015

 

In this tutorial we are going to look at Sprite Animation in Godot Engine, specifically on using the AnimatedSprite class.  We are going to import and create a node that has multiple frames of animation, then look at some code to flip between frames.  In the immediately following tutorial, we will then cover a much better animation method using AnimationPlayer.

 

As always, there is an HD Video version of this tutorial available right here or embedded below.

 

Alright, let’s just right in with AnimatedSprite.

 

Sprite Animation

AnimatedSprite is a handy Node2D derived class that enables you to have a node with multiple SpriteFrames.  In plain English, this class enables us to have a sprite with multiple frames of animation. 

 

Speaking of frames of animation, this is the sequence of png images I am going to use for this example:

image

 

You can download the zip file containing these images here, or of course you can use whatever images you want.

 

Now we simply want to import them to our using the standard Import->2D Texture method.  Be aware, you can multi select in the Importer, so you can import the entire sequence in one go.  Assuming you’ve done it right, your FileSystem should look somewhat like:

image

 

Now add an AnimatedSprite node to your scene like so:

image

 

Now we add the frames to our AnimatedSprite by selecting Frame->New SpriteFrames

image

 

Now drop it down again and select Edit:

image

 

The 2D editor will now be replaced with the SpriteFrames editor.  Click the open icon:

image

 

Shift select all of the sprite frames and select OK

image

 

All of your sprites should now appear in the editor:

image

 

Now let’s add some code to flip through the frames of our AnimatedSprite.  Attach a script to the AnimatedSprite node, then use the following code:


extends AnimatedSprite

var tempElapsed = 0

func _ready():
   set_process(true)
   
func _process(delta):
   tempElapsed = tempElapsed + delta
   
   if(tempElapsed > 0.1):
      if(get_frame() == self.get_sprite_frames().get_frame_count()-1):
         set_frame(0)
      else:
         self.set_frame(get_frame() + 1)
      
      tempElapsed = 0
   
   print(str(get_frame() + 1))

The logic is pretty simple.  In our process tick we increment a variable tempElapsed, until 1/10th of a second has elapsed, at which point we move on to the next frame.  If we are at the last frame of our available animation, we then go back to the very first frame.

 

When you run it, you should see:

walking

 

Pretty cool!  However, instead of advancing the frame using code there is a much better approach to animation, that we will see in the next tutorial.  Stay tuned.

 

The Video

Programming


22. May 2015

 

Following the Beta release a few weeks back, the Godot Engine team have just released Godot Engine 1.1.

 

The highlights of the release are:

  • Rewritten Auto-Completion in the Code-Editor. Supports a lot of scenarios and perform smart-completion of node types if a scene where the script is being used is open.
  • Visual Shader Editor (Edit shaders connecting nodes)
  • New API in OS for managing the screens and window, with multi-monitor support.
  • Largely rewritten 2D engine, with support for:
    • Shaders (Visual and Code)
    • 2D Materials
    • 2D Independent Z ordering per-node.
    • 2D Lights
    • 2D Shadows with Polygonal Occluders
    • 2D Normal Mapping
    • Back-Buffer compositing for shaders that read from screen (allows all sorts of post-processing effects).
    • Improved Isometric TileMap Support (proper Z ordering of tiles and children nodes).
    • Distance-Field font support.
  • New 2D Navigation Polygon support, for efficient 2D pathfinding. Navigation Polygons can be edited visually and combined, disabled, etc.
  • Improved Usability in 2D Physics API:
    • Area2D and RigidBody2D can receive input events
    • Area2D can detect overlap with another Area2D
  • New Dark Theme
  • Much Improved Blender Collada Exporter (BetterCollada).
  • Large amount of bug fixes and smaller improvements.

 

Full (enormous) changelog since 1.0 here.

 

They also put together a video showcasing the new features:

 

Of course, if you are interested in learning more GFS has an extensive Godot Tutorial Series to get you started.

News


28. April 2015

 

In this tutorial we are going to explore the tilemap functionality built into the Godot game engine.  A tile map is a 2D game map composed of layers of “tiles”, which are essentially just a fixed size sprite with some additional properties.  It allows you to quickly paint a level and reuse art assets, greatly decreasing storage and memory requirements for levels.  In addition to supporting tile maps, Godot also includes a handy editor, although there certainly are some warts.

 

There is an HD video version of this tutorial available here or embedded below.

 

We are going to require two scenes for this example, one to create our tileset and one to actually use it.

 

Creating a Tileset

 

Before we continue though, I need a tileset to use.  Instead of creating one, I am going to use this one from OpenGameArt.org.  Of course, you can use whatever image you want, just be sure the tiles are the same size and have no spacing between them (if you want to keep the math easy).

 

Here is the tileset I chose:

PathAndObjects

 

This version however is shrunk down, use the link above if you want to use the exact same tiles.  Each tile in this image is 32x32 pixels in size.  This will be important shortly.

 

Now let’s create a tileset in Godot.  Create a new scene.  This process is really labor intensive unfortunately, but very powerful too.  Create a root Node, then a Sprite for your first tile.  Each tile needs to have a unique name.  I am only going to use a subset of what is available on that spritesheet, but you simply repeat the process to add more.

 

Create a hierarchy like this:

image

 

Now for Sprite Tile1.  Now configure the sprite’s Texture to your spritesheet.  Importantly, set Region to on and set the Region Rect to 0,0,32,32, like so:

image

 

This sets the image source of this tile to a 32x32 region at the top left corner of the texture.  Now you should see:

image

 

Now let’s setup snapping, so we can arrange our tiles in a nice grid.  Select Edit->Configure Snap

image

 

Set Grid step to the same dimensions as your tiles, in my case 32x32:

image

 

Now select “Use Snap” as seen in the menu above.

 

The next part is optional, if you want to use physics or collisions or not.  If you do, we now need to set up StaticBody and hit detection boundaries.  This process is the same as we went through in the previous tutorial so I am not going to go into details on how.  You do want the end result like this however:

image

 

Then define the areas of your CollisionsPolygon2D that are collide-able or not, like so:

image

 

Turning snap on and off is critical here.  Snap makes it easy to create the initial bounding box, as it will automatically snap to each corner.  However, when you start adding fine detail, be sure to turn it off.

 

Now repeat this process for each tile you wish to include from your spritesheet.  You can make the process a great deal quicker using the Duplicate option ( or Ctrl +D ).  Simply select your first tile then duplicate.  Then you just need to reposition it on the map, redefine the CollisionPolygon2D bounds and of course, update the region to the next tile, like so:

image

 

This will select the next tile from the top left of the image.  Repeat until you have all of your tiles defined.  Yes, it would be nice if this was an automated process!

 

Because I’m lazy, im only going to define three tiles, like so:

image

 

Which look like this with collision polygons defined:

image

 

Please note, there was no need to put space between each tile like I have here.  Now that we’ve defined our tiles, first save your scene, I called mine tilemap.scn.  Now we are going to export a tilemap.  Simply choose Scene->Convert To…->TileSet…

 

image

 

I called mine tileset.xml.  Be aware of the option Merge With Existing.  When you make changes to your tileset in the future, you probably want to turn this off if you want your changes to be completely overwritten.

image

 

I personally found the Collision polygon exporting to be extremely buggy.  You may want to open up the generated XML file and make sure collision information was properly exported:

image

 

Using a Tilemap

 

Now that we’ve got our tileset created, our collision polygons configured and all things ready to go, it’s time to create a new scene then create a Tilemap.

 

The Node you want to add is a TileMap, like so:

image

 

Configure your tilemap like so:

image

 

If you are using Physics, set Use Kinematic on, otherwise don’t.  Set the Cell Size to the size of your tiles and tileset to your newly exported tileset.

 

You will notice now, with the TileMap node selected, your tiles will appear down the left hand side of the 2D editor window:

image

 

You can now use these to “paint” your level, like so:

image

 

You can create multiple TileMap objects if you need to have different layers of tiles (like foreground props for example).  Today though, we are going to stick to this simple example.

 

Finally I created a RigidBody sprite to interact with our tilemap, so our final scene looks like this:

image

 

Now when we run it, it should look like:

g1

 

You can make some edits to your tilemap from within Godot without re-exporting the tileset.  With your Tilemap selected, select your Tileset property, then Edit:

image

 

You will notice a new Theme menu appears, allowing you to edit your Tileset, such as adding new items:

image

 

You can also see the tiles that make up the tileset in the Inspector:

image

 

The Video

 

Programming


19. March 2015

 

In this tutorial we are going to take a look at two key topics in Godot game development, Collision Detection and Physics Simulations.  Collision Detection is simply detecting if two objects overlap.  Physics on the other hand simulates the movement and interaction of game objects based on physical properties.  This of course also includes handling collisions.  There is also a video of this tutorial and this might be one of those times, due to all of the motion in the results, that you may in fact want to refer to the video even if you prefer text based tutorials.  So if you struggle to understand what I am talking about here, be sure to quickly check the video, it may have the answer.

 

You can watch the video here, or embedded below.

 

Checking for Collisions

 

Let’s start with checking collisions between two objects, in this case, two different Sprite objects.  I have created the following scene:

image

It’s simply two sprite objects side by side.  I then attached a script to the one on the left.  This script updates the position of the left sprite until a collision occurs, at which point it resets to the beginning and does it all over again.  Like so:

anim

 

Let’s take a look at the script now:

extends Sprite

var start_pos = Vector2()
var box1 = null
var box2 = null

func _ready():
   set_process(true)
   start_pos = get_pos()
   box1 = RectangleShape2D.new()
   box2 = RectangleShape2D.new()



func _process(delta):
   # Get a reference to the other sprite
   var sprite2 = get_node("/root/SceneRoot/Sprite 2")
   
   # Update our location
   self.move_local_x(0.1)
   
   # set the boundaries of each RectangleShape2D to those of the texture making up our sprite
   # values are relative to center, thus half width and height
   box1.set_extents(Vector2(self.get_texture().get_size().width/2,self.get_texture().get_size().height/2))
   box2.set_extents(Vector2(
sprite2.get_texture().get_size().width/2,sprite2.get_texture().get_size().height/2)) #Now check to see if box1 at sprite1's pos collided with box2 and sprite2's position if(box1.collide(get_transform(),box2,sprite2.get_transform())): set_pos(start_pos) # it did, so reset position to beginning, what's old is new again!

Essentially what you are doing here is creating a RectangleShape2D using the boundaries of each Sprite’s texture image.  AKA, creating a rectangle the size of the texture.  You then check if box1 at the transformed position of Sprite1 collides with box2 at the transformed position of Sprite2.  Of course, since they both use the same texture map, you don’t actually need to create two different RectangleShape2D objects!  Also, since the size never changes, you don’t actually need to set_extents() in process().  There are a number of simple shape classes that can be used to check for collisions such as concave and convex polygons, circles and even rays ( for mouse picking ).

 

This is one way to check for simple collisions.  However you will quickly find it gets unwieldy as you add more and more objects and have to check them against each other.  Fortunately the physics engine makes this process a whole lot easier.

 

Physics Simulations

 

Now that we looked at a way to test for collisions, lets move on and discuss the physics system.  Basically a physics engine simulates movement using complex math, calculating how items interact with each other and external forces like gravity.  The physics simulation then updates, either on a fixed or per frame basis, a set of objects with the new locations calculated by the simulation.  You then update your visible game objects positions accordingly.  In Godot however, you don’t generally need to perform that last step, it’s done automatically.

 

Let’s start with an extremely simple example, gravity.

 

First we start by creating a RigidBody2D node:

image

 

Next, parented to the RigidBody2D node, create a sprite node.  I am using the default icon.png that comes with Godot.  Your heirarchy should look like this:

image

 

… and that’s it.  You have now created a physics object that gravity will be applied to.  Run your game and you should see:

anim2

 

Now let’s pause a second to see exactly what is happening here.

 

First, let’s start with the RigidBody2D part…  There are three kinds of physics objects you can use in your 2D game world:

image

The biggest difference is how they are dealt with by the simulation.

 

A RigidBody can be thought of as a typical physics object.  It’s the most processing intensive, but it’s also got the most functionality.  Unless you have a reason otherwise, if something needs physics, it’s probably a rigid body.  This is a physics object that can move, can collide with other objects and itself by collided with.

 

Next up is the StaticBody2D.  This is an unmoving object in your world.  Basically things can hit it, it can be hit, but it doesn’t move.  It also takes a lot less processing power to handle.  Generally things like the world, or invisible but unmoving triggers will be static bodies.

 

Finally is KinematicBody2D.  This is a physics object that doesn’t have the range of functionality of a rigid body ( for example, you cant apply force to it ), but can move and can collide with other physics objects.  The biggest thing about a Kinematic body is that its motion is generally controlled directly by you no the physics simulation.  Generally this is the character sprite.  You want the physics simulation to react to its actions, but you generally control those movements directly in code.

 

So, those are the three major types of physics objects, now let’s look at global settings.  You notice how gravity is being applied to our simulation automatically?  Where is this coming from?

 

The answer is trust ole project settings:

image

 

So… what do those values means?  Well this is one of the nice things about working entirely in Godot.  In many physics engines like Box2D, you work in meters, then have to translate from meters to pixels when transforming your sprites.  In godot, these values are in pixels.  So a gravity value of 98 means gravity moves at 98 pixels per second.

 

Now what about Rigid Body settings?  Well let’s take a look:

image

 

Mass Friction and Bounce are the most commonly used values.  Hey, aren’t mass and weight the same thing?  Nope, not exactly.  Mass is the amount of “stuff” that composes and object, while weight is the amount that stuff weighs.

 

Consider the classic question “What weighs more, a ton of bricks or a ton of feathers?”  Both objects would have identical weights ( one ton ), but vastly different masses.  In some ways it can be easier to think of mass instead as density. 

 

Friction on the other hand is how it slides in contact with another surface.  Picture sliding a mouse down a surface on a 45 degree angle.  If one surface was rubber and the other was glass, the mouse is going to move at vastly different rates.  Friction controls this.   Bounce is often refered to as restitution.  This is the amount of, well, bounce in an object.  Or how much it reacts to a collision.  A rubber ball has a higher “Bounce” value, while a brick is almost 0.  Another key concept is sleep, this is the ability to turn the Rigid Body off during calculations, determines if it is or isn’t used as part of the over all simulation.  Linear and Angular velocity finally are the default movement values of the object.

 

Collisions Physics Style

 

Now let’s take a look at how collisions are handle using a Physics engine.  Let’s change the above scene to add another physics item, this time a static body, like so:

image

 

The top sprite has a RigidBody2D as it’s parent.  The bottom has a StaticBody2D for a parent.  Now we need to define a collision volume for each one, just like we did back at the beginning.  Simple add a new node to each Body ( not the sprite, it’s parent! ) of type CollisionShape2D, so your hierarchy looks like this:

image

 

Then for each CollisionShape2D, you need to pick a bounding shape.  With the CollisionShape2D selected in Inspector simply select the Shape dropdown and pick the one that is best suited:

image

Finally, size it so it covers the collide-able portions of your sprite:

image

 

Now when you run the game:

anim3

 

Tada!  Collisions calculated by the physics engine.  Now you can play around a bit with the physical properties of your Rigid Body and see how it reacts differently.

 

In this case we used a simple box for our collision detection, and that works well for box shaped objects.  But if your object isn’t box or circle shaped, what do you do?  Enter CollisionPolygon2D:

image

 

It works exactly the same as CollisionShape2D, but you can define the shape yourself.  Remove one of the CollisionShape2D nodes and replace it with a CollisionPolygon2D node.  With the Collision node selected, you will notice a new option in the 2D window:

image

 

Click the pen, and you can now draw a polygon around your object:

image

 

And once closed:

image

A MUCH more accurate representation of your object for collisions!

 

Kinematic Nodes

 

Finally let’s look at KinematicBody2D objects.  These are special in that the physics engine doesn’t control their motion, you do.  They can however collide with entities in the physics world.  Generally speaking, this is how you would create your character.  Unlike RigidBodies you cannot apply forces or impulses.  Instead you move them directly.  Let’s create a simple example:

 

First add a KinimaticBody2D to your scene, add a sprite and collision shape for it, like so:

image

 

Now apply a script to the KinematicBody2D with the following code:

extends KinematicBody2D



func _ready():
   set_process(true)
   
func _process(delta):
   move(Vector2(0.04,0))

We are simply moving the body by 0.4 pixels per update.  As you can see from the results however collisions will occur between your game code controlled object and the physics simulation:

anim4

 

There is obviously quite a bit more to the physics simulation.  You can create joints and springs and define what objects collide with other objects, but that covers most of the basics.  Be sure to watch the video if you struggle, as it covers things in a bit more detail!

 

The Video

 

Programming


23. February 2015

 

Until this point in the series we have only created single scene games.  In any non trivial application you are often going to want to have several scenes make up your game.  For example you might have a scene for your title screen/intro, then a main menu, then a game playing then finally a game over scene.  Today we are going to look at how to do exactly this.  We are also going to look at sharing information between those scenes.

 

This scene is available as an HD video here.

 

Creating Multiple Scenes

 

First and foremost, you always need to have at least one scene to start up.  Let’s go ahead and create one, the Title screen seems logical enough.  Create a scene that draws a simple graphic, called it “title_scene.scn” and set it as your startup scene.  If you are unfamiliar with this step, please see prior tutorial parts.  Once complete it should look something like this:

image

 

Next we want to create a scene to transition to.  I called mine game.scn.  It may not be completely obvious, but you actually close your scene to create the new scene.  Select Scene->New Scene:

 

Then say yes to the scary dialog that pops up ( of course, we assume you’ve saved your scene and set it as the startup scene already! ):

image

 

Now in the second scene, I just created a simple Panel, with a pair of label controls, like so:

image

 

It doesn’t really matter what you do.  The labels are just to show that information can be shared between Scenes.  Our game isn’t actually going to do anything.

 

 

Ok… so now we have our two scenes… how are we going to wire them all together?  Well that requires a script.  Re-open the title_scene.scn scene.  There is a handy Open Prev Scene menu option, or you can use open Scene…

image

 

Adding a Script to control scene switching

 

Now that we have our original scene selected, we need to add a script to it.  To do this, switch to the Resources tab and select the New Resource icon:

image

 

For type select GDScript:

image

 

I named mine ‘global.gd’.

 

Now we write out our script.  We are going to be auto loading this as a node into our game when our application starts, so we need to inherit from Node or a Node derived class.  In my case I used node.  You can inherit a class using the extends keyword.

 

Here is the code for our simple Node script.  We create a function so scenes can switch between scenes, and demonstrate getting a session variable, as well as setting a global variable.

extends Node

#The currently active scene
var currentScene = null

#just some data for our game.  It could be HPs, Alignment, Direction, etc...
var PlayerName = "Mike"


func _ready():
   #On load set the current scene to the last scene available
   currentScene = get_tree().get_root().get_child(get_tree().get_root().get_child_count() -1)
   #Demonstrate setting a global variable.
   Globals.set("MAX_POWER_LEVEL",9000)
   
# create a function to switch between scenes 
func setScene(scene):
   #clean up the current scene
   currentScene.queue_free()
   #load the file passed in as the param "scene"
   var s = ResourceLoader.load(scene)
   #create an instance of our scene
   currentScene = s.instance()
   # add scene to root
   get_tree().get_root().add_child(currentScene)
   
   
#simple accessor function to retrieve playerName   
func getPlayerName():
   return PlayerName

 

Autoload script on startup

 

Be sure to save your newly created script.  Now we want to set it so that this screen runs automatically when our game is started.

To do this, go to Scene->Project Settings.

In the resulting dialog, you want to select the AutoLoad tab.  Now you specify the script you want to autoload, and the name you want the node to be known as.  This is case sensitive by the way.

In path, select your newly created global.gd.  In Node Name call it globals then click Add:

image

 

Now this script will be run automatically when your game or application starts up!

 

Now that we can switch scenes, let’s make us of this ability.  In your title_scene.scn project, attach a script to the image you used.  Personally I used a TextureFrame to hold my title screen.    We are simply going to check for the user pressing the left mouse button, and if they do, we are going to switch scenes.

extends TextureFrame


func _ready():
   set_process(true)
   
func _process(delta):
   if(Input.is_mouse_button_pressed(BUTTON_LEFT)):
      get_node("/root/globals").setScene("res://game.scn")

 

As you can see you can access the script by getting it as a node using the name you provided in the AutoLoad dialog.  Once again this value is case sensitive and you have to include the /root/ part. 

 

So, once we click our title image, it should load our other scene.  Let’s add a bit of logic to it.  Load the game.scn ( yes, I wish their was a project mode that prevented this switching between scenes stuff… ), attach a script and add the following code:

extends Panel


func _ready():
   var name = get_node("/root/globals").getPlayerName()
   get_node("Label").set_text(str(name, " is the greatest player ever!"))

   var powerLevel = Globals.get("MAX_POWER_LEVEL")
   get_node("Label2").set_text(str("Maximum power level is ", powerLevel))

 

This code illustrates too simple concepts... calling a global instance ( Singleton in Godot parlance btw ), such as setScene() or getPlayerName() or calling a global variable. Both methods make it very easy to share data between various scenes, escentially forming the backbone of your application.

 

The Video

 

Programming


GFS On YouTube

See More Tutorials on DevGa.me!

Month List