Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


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 , ,

blog comments powered by Disqus

Month List

Popular Comments

Amazon Release Lumberyard Game Engine
Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


9. February 2016

 

Not every day that there is a new player in the AAA game space, but that’s exactly what just happened with the release of Lumberyard by Amazon.  Amazon has been getting more and more involved with gaming with the launch of their own game studio coupled with their purchased of Double Helix games back in 2014.  Their cloud computing solution, AWS (and more specifically EC2 and S3) have both proven incredibly popular with game developers, providing the networking back end for companies such as Rovio and Ubisoft.  Today however they just made a much bigger splash with the release of a complete game engine, Lumberyard.

Now Lumberyard isn’t actually a brand new engine, in fact it appears to be a mashup of a number of technologies including CryEngine, in house tools created by Double Helix Games and cloud services from AWS, specifically the new Amazon Gamelift service, which is described as:

Amazon GameLift, a managed service for deploying, operating, and scaling session-based multiplayer games, reduces the time required to build a multiplayer backend from thousands of hours to just minutes. Available for developers using Amazon Lumberyard, Amazon GameLift is built on AWS’s highly available cloud infrastructure and allows you to quickly scale high-performance game servers up and down to meet player demand – without any additional engineering effort or upfront costs.

Lumberyard will also feature Twitch integration, and perhaps most interestingly, launch with support, both in forum and tutorial form but also in a paid form, something that is often lacking.  Lumberyard tools only run on Windows 7,8 and 10, while the supported targets at launch are Windows, PS4 and Xbox One.  Of course a developer license is required to target either console.  About the technical bits of Lumberyard:

The Lumberyard development environment runs on your Windows PC or laptop. You’ll need a fast, quad-core processor, at least 8 GB of memory, 200 GB of free disk space, and a high-end video card with 2 GB or more of memory and Direct X 11 compatibility. You will also need Visual Studio 2013 Update 4 (or newer) and the Visual C++ Redistributables package for Visual Studio 2013.

The Lumberyard Zip file contains the binaries, templates, assets, and configuration files for the Lumberyard Editor. It also includes binaries and source code for the Lumberyard game engine. You can use the engine as-is, you can dig in to the source code for reference purposes, or you can customize it in order to further differentiate your game. The Zip file also contains the Lumberyard Launcher. This program makes sure that you have properly installed and configured Lumberyard and the third party runtimes, SDKs, tools, and plugins.

The Lumberyard Editor encapsulates the game under development and a suite of tools that you can use to edit the game’s assets.

The Lumberyard Editor includes a suite of editing tools (each of which could be the subject of an entire blog post) including an Asset Browser, a Layer Editor, a LOD Generator, a Texture Browser, a Material Editor, Geppetto (character and animation tools), a Mannequin Editor, Flow Graph (visual programming), an AI Debugger, a Track View Editor, an Audio Controls Editor, a Terrain Editor, a Terrain Texture Layers Editor, a Particle Editor, a Time of Day Editor, a Sun Trajectory Tool, a Composition Editor, a Database View, and a UI Editor. All of the editors (and much more) are accessible from one of the toolbars at the top.

In order to allow you to add functionality to your game in a selective, modular form, Lumberyard uses a code packaging system that we call Gems. You simply enable the desired Gems and they’ll be built and included in your finished game binary automatically. Lumberyard includes Gems for AWS access, Boids (for flocking behavior), clouds, game effects, access to GameLift, lightning, physics, rain, snow, tornadoes, user interfaces, multiplayer functions, and a collection of woodlands assets (for detailed, realistic forests).

Coding with Flow Graph and Cloud Canvas
Traditionally, logic for games was built by dedicated developers, often in C++ and with the usual turnaround time for an edit/compile/run cycle. While this option is still open to you if you use Lumberyard, you also have two other options: Lua and Flow Graph.

Flow Graph is a modern and approachable visual scripting system that allows you to implement complex game logic without writing or or modifying any code. You can use an extensive library of pre-built nodes to set up gameplay, control sounds, and manage effects.

Flow graphs are made from nodes and links; a single level can contain multiple graphs and they can all be active at the same time. Nodes represent game entities or actions. Links connect the output of one node to the input of another one. Inputs have a type (Boolean, Float, Int, String, Vector, and so forth). Output ports can be connected to an input port of any type; an automatic type conversion is performed (if possible).

There are over 30 distinct types of nodes, including a set (known as Cloud Canvas) that provide access to various AWS services. These include two nodes that provide access to Amazon Simple Queue Service (SQS),  four nodes that provide access to Amazon Simple Notification Service (SNS), seven nodes that provide read/write access to Amazon DynamoDB, one to invoke an AWS Lambda function, and another to manage player credentials using Amazon Cognito. All of the games calls to AWS are made via an AWS Identity and Access Management (IAM) user that you configure in to Cloud Canvas.

Finally we come to price.  Lumberyard is free*.  I say free* instead of free because of course there is a catch, but an incredibly fair one in my opinion.  If  you use Lumberyard you either have to host it on Amazon servers or on your own.  Basically you can’t use Lumberyard then host it on a competitor such as Azure or Rackspace.  Pricing is always a bit tricky when it comes to Amazon services, but unlike Google, they have never once screwed their user base (Google once jacked up prices by an order of magnitude, over night, forever souring me on their technology), so you are pretty safe in this regard.  More details on pricing:

Amazon GameLift is launching in the US East (Northern Virginia) and US West (Oregon) regions, and will be coming to other AWS regions as well. As part of AWS Free Usage tier, you can run a fleet comprised of one c3.large instance for up to 125 hours per month for a period of one year. After that, you pay the usual On-Demand rates for the EC2 instances that you use, plus a charge for 50 GB / month of EBS storage per instance, and $1.50 per month for every 1000 daily active users.

I intend to look closer at the Lumberyard game engine as soon as possible, so expect a preview, review or tutorial shortly.

GameDev News ,

blog comments powered by Disqus

Month List

Popular Comments