29. May 2015

 

Up until this point we’ve covered a ton of the items that go into making a game, but nothing resembling a game… the pieces simply didn’t fit together.  In this tutorial we are going to change that and start bringing everything we learned together.  We are going to be covering a lot today, so if I lose you let me know.  This might be one of those tutorials where the video version comes in very handy.

 

Once again, I am simply going to assume you’ve gone through all the prior tutorials, so instead of telling you how to make a flipbook, I simply say “Make a flipbook”.  So if you haven’t already, you may want to go back and read or watch the earlier tutorials.  Ok, let’s jump right in.

 

There is an HD video version of this tutorial [coming soon], or available embedded below.

 

 

Actors, Pawns, Characters and Controllers

 

In the world of Unreal Engine, things that exist in the game world are Actors.  Quite simply an Actor is an object that can be placed into a level.  It contains details like position, rotation and scale.  Most importantly, Actors are containers for Components, or even a hierarchy of components.  Components can be thought of as attributes or properties of an actor…  these are the things the actor is and does, and the Actor->Component relationship is a big part of Unreal’s modular design.

 

There are a few very important classes derived from Actor that are very important.  The first of which is the Pawn.  Basically a Pawn is an Actor that can be controlled by either the player or the games AI. Each Pawn has a Controller and each Controller has a pawn.

 

The Controller can control a pawn.  This takes two forms, AI controllers and character controllers.  The AI controller is responsible for the artificial intelligence that controls a pawns movements.  The Player Controller on the other hand is responsible for handling input from the player(s) and applying the results to the character’s pawn.

 

Finally you have Characters. A Character brings a number of objects together to represent that character.  In the 3D world, the Character class extends Pawn to include a skeletal mesh, a mesh for collision detection and of course whatever components you add.  In the Paper2D world there instead is PaperCharacter, which instead of a mesh instead has a Flipbook.

 

These key classes all work together to provide the building blocks of your game.  Don’t worry, we are about to see it all in action in a few minutes.

 

Getting Ready

 

We are now going to create the skeleton of a game, but this is going to require you to do a few things.  First of course create a new project, I am using these settings:

image

 

After loading I want a completely clean slate so I select an delete everything the project included:

image

 

Next, we need to import some sprites, both as a background and to create a flipbook for our main character.

 

I am using a simple three frame animation using this frame, this frame and this frame.   For my world background I am using this image.  Any likeness or similarity to an existing game is purely coincidental…   Obviously you don’t have to use these images, but if you want to follow along exactly you can.

 

Load all four images in as textures, then make a sprite from each.  Create a new Sprite Flipbook out of our 3 frames of animation and set the frame rate at 2fps. Then drag the fourth sprite in as our scenes background.  Be sure to set the backgrounds Y value to a negative so our game sprite will draw in front of it! 

 

Ultimately you should have something like this:

image

 

With a Flipbook like this:

pacbook

 

Creating a Main Character

 

Now that we have a world and an animation, it’s time to add a character to the game.

 

To do so, select Add New, then Blueprint Class:

image

 

It is going to present a dialog with a number of the options we talked about earlier.  The one we are going to use in this example isn’t actually on the list so select All Classes:

image

 

In the filter type “Pap”, then locate PaperCharacter, click it and press Select.

image

 

This will create a new Blueprint for you, I immediately renamed mine MyPlayer.

image

 

I suppose I should point out, you don’t have to use PaperCharacter, any Pawn derived class is fine, although the process will be slightly different.

 

In the Content Browser, double click MyPlayer to bring up the Blueprint editor, it should look something like this:

image

 

Now we need to set the Flipbook for our Player.  You will notice on the left hand side, several components are already defined:

image

 

Select Sprite.

 

Now with sprite selected, it’s details should appear on the right hand side.  No locate Sprite and select the Flipbook you created earlier:

image

 

In the Viewport tab, your Player should now look like:

pac2

 

Now we want to shrink the capsule down to match our sprite.  The capsule container is used for doing collision tests and should be as near an approximation as possible.  Simply select the capsule in the viewport, then in details locate Shape and set the two values until it just fits around your sprite.  I used:

image

 

And the end results looks like:

image

 

 

Adding a Camera

 

Let’s look at the process of adding a component to an actor, in this case a Camera.  This will create a camera centered on the Actor.  To do so, in the Components panel select Add Component, then Camera:

image

 

In the viewport you will now see your new Camera component:

image

 

Right click select it, hit E to rotate and rotate it 90 degrees.  Then hit W to move it, and move it back along the X axis.  Something like this:

image

 

The angle and distance between the camera and the sprite are important, but once you’ve got things configured correctly ( in a few minutes ), you will be able to hit the Play icon and preview the effect of the camera on your player.  If we needed more fine tune control of the relationship between the camera and the sprite, we could add a Swing Arm component and attach the camera to it.  We don’t need this in this particular example though.

 

Configuring your game

 

Now that we have our player class, we need to let the game know that it is our player.  This is done by creating a GameMode blueprint.  To do so drop down the Blueprints icon, select GameMode->Create->GameMode, like so:

image

 

In the resulting dialog, name it then select OK.  I’m going with the default NewGameMode.

image

 

This will create a new Blueprint but the part you are most interested in are the properties.  It is here that you configure a number of important top level classes for your game.  Locate “Default Pawn Class” in the Classes section and select your Player class.

image

 

Now when the game starts, and instance of your Player class will automatically be created.

 

Now we just need to tell the game WHERE the player should be created, and this is done using a Player Start object.  In the Modes dialog, locate or search for Player Start and drag one onto the scene where you want the player pawn to be created.

image

 

And position it like so:

image

 

Now press play and we see…

pac3

 

Hmmm… that’s not good.

 

The problem is, our game world has gravity enabled by default and we don’t want this.  The easiest fix is to turn gravity off.

 

To turn off gravity, in the World Outliner, double click your map to bring World Settings dialog up.  Now locate the Physics section, check Override World Gravity and make sure gravity is set to 0.

image

 

Now when we press play we should see:

pac4

 

Much better, we are now one step closer.  We have a world (sorta…  I’ll admit, we are faking that part pretty heavily here), we have a main character… now we just need to add some controls.

 

Simple Keyboard Controls

 

Now we are going to jump into some Blueprint programming to add some keyboard controls to our player.  Double click your MyPlayer blueprint to bring it up in the editor, then select the Event Graph task.  Personally I am deleting all of the premades that they provide to keep things a bit cleaner.

 

Now we are going to add an input handler for when the user presses the Right arrow key.  Simply right click the canvas, type Right and select Key Events –> Right like so:

image

 

We create this simple blueprint.

image

 

Now when the user releases the right arrow, we move the Character Movement component of our player by 20 along the X axis.

 

Now through the power of Cut and Paste, we quickly create the following simple control scheme:

image

 

All that changes is for each key pressed we move in a different direction, either +/- x for left and right, or +/- z for up and down.

 

In case you didn’t know, you can rectangle select a region of blueprint and replicate it use the traditional cut/copy/paste hot keys.  Now we we run our game, we have primitive control over our player:

pac5

 

This is a very very very trivial example, and as you can see, it’s missing some logic for left and right as “definitely not PacMan” doesn’t turn to face the direction we are facing.  If you watch the video version of this tutorial I will show a simple way to handle that situation, we are already running pretty long here.

 

More on Input

 

The above example was super simple, we simply respond directly to a certain key being pressed.  In your game you probably wont end up using this logic.  Let’s take a quick look at some more advanced control options before moving on.

 

First, there was additional options for the key handling events that I never showed.  With a Key event selected in the Details panel you will see additional options:

image

 

In addition to changing the key handled you can enabled/disable modifier keys like Ctrl and Shift.  You can also control if the keyboard event is handled or will be propagated to the rest of the application by setting Consume Input.

 

More commonly however, you are going to want to handle Input more generically.  Responding to a single key event is all well and good, but what happens when you want the same code to work on a device without a keyboard?  Or you want a joystick to do the same thing?  Or you want the user to be able to remap their own keys?  Well, good news, there is an answer for that.

 

First, select Edit->Project Settings:

image

 

On the left, under Engine select Input then locate the Bindings section:

image

 

This area allows us to create input bindings between controls and either an action, or the axis of a controller ( virtual or otherwise ).  Let’s look at an example of mapping a “Left” axis.

 

Start by clicking the + next to Axis Mapping, expand the new value and rename it left, then add a key like so:

image

 

Now I am going to repeat the task, but also mapping for the left D-pad on a controller and the A key.  The end result looks like:

image

 

Now instead of handling each controller/key separately they will all emit the same “LEFT” event.  When you are creating your input handling blueprint, you can now respond to an Input->Axis Events->LEFT event:

image

 

You will notice the Event for an axis has one additional parameter:

image

 

Axis value is the “amount” along the axis it is.  All of our examples are on/off inputs, but if you had an analog stick, the Axis Value would indicate how far to the left the stick was pressed.  Coincidentally, that is the use of the “Scale” property in the Axis mapping process.  If for example you wanted the Left arrow key to be equivalent of pushing the Left analog stick 50%, you would set the scale value to 0.5.

 

Video

 

Coming soon.

Programming , , ,

27. May 2015

 

So today I fired up Steam to finally pull the trigger on Pillars of Eternity and what do I see….

 

image

It seems that Degica games, the makers of the popular RPG Maker series of game building tools are having a sale today.  Their flagship product RPG Maker VX Ace ( … quite the name ) is currently on sale for 80% off.

 

On top of RPG Maker Vx Ace, RPG Maker XP and RPG Maker 2003 are all also discounted, 80% and 50% respectively.  What perhaps caught my eye most of all however wasn’t the RPG Maker line of products, but Spriter is also on sale for 75% off.   Spriter was a successfully kickstarted project made by BrashMonkey, I had no idea Degica was now the publisher.

 

About Each Program

 


RPG Maker

 

 

This is a program that has been around for a very long time, first released in 1988.  As the title suggests, it’s a game building tool for making RPG’s, generally of the classic jRPG format.

 

That said, this is a proper game building application, a number of commercially shipped games were created using the various iterations of RPG Maker.  RPG Maker was mentioned as an option in my guide to getting kids started in game development.  Bundled with a ton of premade assets, it is a good way to get your hands wet in game development.  In addition to world, character, dialog, etc… building tools, there is also a programmatic layer using the Ruby programming language. 

 


Spriter

 

Perhaps of most interest to GameFromScratch readers is Spriter.  Spriter is essentially a modular 2D animation system.  You basically cut your sprites up into multiple independent pieces which in turn can be animated.  You can also apply an IK chain ( inverse kinematics… think skeleton ) that controls the animation for you.  You can then export the resulting animation as a sprite sheet, sequence of images or as an animated gif.

 

Most likely though you will want to use the Spriter API, or one of the pre-existing plugins, and use the Spriter animations directly in your game engine, such as Construct, Unity or LibGDX.

 

Truth is, I did a pretty lousy job there describing Spriter, so I will just show their video instead…

 

 

Both are on sale until May the 29th. 

 

Oh, and as I finish typing this up, the Steam page for the sale now appears to be broken…

News ,

26. May 2015

 

As part of GameFromScratch’s ongoing A Closer look at game engine series, today we are going to be taking a look at LibGDX, a Java based cross platform game engine(sorta).  The “Closer Look” series is intended to be a cross between a tutorial, review and overview of a game engine, aimed at helping those evaluating which game engine is right for them.  We are going to go into a bit less technical detail with LibGDX, as this site already has a massive text based and video based tutorial series covering LibGDX in depth.

 

There is an HD video version of this post available as well, also embedded below.

 

Introduction to LibGDX

 

Let’s start with their own description:

Libgdx is a Java game development framework that provides a unified API that works across all supported platforms.

The framework provides an environment for rapid prototyping and fast iterations. Instead of deploying to Android/iOS/Javascript after each code change, you can run and debug your game on the desktop, natively. Desktop JVM features like code hotswapping reduce your iteration times considerably.

Libgdx tries not be the "end all, be all" solution. It does not force a specific design on you.

You can get a complete feature list here.

 

So basically LibGDX is a cross platform, JVM based 2D/3D game engine(sorta) capable of targeting desktops, iOS, Android and HTML.  It is free and completely open source.  When I say JVM based, LibGDX is written primarily in Java but your own applications code could theoretically be written in any JVM based language, such as Kotlin or Scala.  LibGDX is able to compile to HTML using the GWT compiler, while iOS support is provided using RoboVM.  For the most part, 99% of the time, the platform specific portions are pretty well hidden from you the developer.

 

So why do I keep throwing a (sorta) disclaimer every time I use the word “Game Engine”?  Well that’s technically because LibGDX isn’t a game engine, it’s more of a framework, similar in scope to SFML, MonoGame/XNA or SDL.  It provides the underlying “guts” required to make game a game, things like graphics, audio and input.  It however doesn’t provide a scenegraph, essentially the “heart” of a game.  However it does provide a simple 2D scene graph/ UI / Widget library named Scene2D, which is built over top of LibGDX.  The use of Scene2D is completely optional.

 

Getting Started

 

Getting started with LibGDX is incredibly simple.  If you want to use it as just another library that is of course your option.  If you are for example making a desktop only project, you can download and build LibGDX from it’s Github repository.  If you want to create a cross platform game, or like me, want to avoid Java build systems like the plague there is a handy project creation tool available right here.  Simply download and execute the linked Jar file.  It will automatically download all of the required dependencies, although you will have to have a Java Development Kit and the Android SDK pre-installed.  For more detailed installation instructions watch this.  Assuming you have a properly configured Java dev environment, you should see the following:

image

 

This will automatically generate a project for you.  Clicking Advanced allows you to have LibGDX generate IntelliJ IDEA or Eclipse projects for you.  You can also select which platforms you want to support and which extensions to you want enabled.  Once you click Generate, Maven will automatically create a project for you and download all the dependencies.  If you want the tools such as a font generator, particle tool or sprite packer, be sure to select Tools under extensions.

 

If you are looking for more details on working with your specific IDE, check the tutorials for more details.  There are IntelliJ and Eclipse configuration tutorial available.

 

A Simple Project

 

Let’s take a quick look at the project it generated.

 

The heart of your game is the platform agnostic ApplicationAdapter located in the core project.  ( More on this shortly ).  Here is the code:

package com.gamefromscratch;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;

public class MyGame extends ApplicationAdapter {
   SpriteBatch batch;
   Texture img;
   
   @Override
   public void create () {
      batch = new SpriteBatch();
      img = new Texture("badlogic.jpg");
   }

   @Override
   public void render () {
      Gdx.gl.glClearColor(1, 0, 0, 1);
      Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);
      batch.begin();
      batch.draw(img, 0, 0);
      batch.end();
   }
}

 

If you’ve previously worked in XNA, the overarching structure should be immediately familiar to you, XNA and LibGDX feel incredibly similar to me, and this is a good thing.

 

The nutshell version of what’s happening here is our game extends the ApplicationAdapter class… we will see why shortly.  In it’s create() method we create a SpriteBatch and a Texture object, the texture “badlogic.jpg” is loaded from the assets folder ( by default in the Android project, unless you didn’t create an Android project, in which case it will be in Core ).  The assets folder is basically the root where all of your game’s non-code content is located.  In render() method we clear the background color, start our sprite batch, draw the texture to it, then finish the batch, which results in it’s contents being drawn to the screen.

 

There are a few things to be immediately aware of.  LibGDX provides a fairly shallow abstraction over top of OpenGL ( or WebGL/OpenGL ES, depending on platform ), which can be access with Gdx.gl. calls.  Most of the GL functions are accessible this way, but in a cross platform friendly manner.  The other thing to be aware of is the coordinate system by default follows the OpenGL convention of having the origin (0,0) be the bottom left corner of the screen.

 

When you run the generated code, you should see:

image

 

That’s about as detailed as I am going to get with the code, if you want more details, simply go through the tutorial series for dozens of them.

 

Now the neat part about this whole process is, using the exact same code you could switch your run target to iOS, Android or HTML and it should just work.  Let’s look at exactly how that works.  If you look at the project, your folders should be structured like so:

image

 

Basically you have a project/module for each targeted platform, then core where the cross platform ( majority ) of your code exists.  Let’s take a quick look at the desktop project for a look at exactly how this works. Expanded, the desktop project should look something like this.

image

 

It’s the DesktopLauncher class that is of the most interest.  For desktop projects, this is your application entry point.  Let’s take a quick look inside:

package com.gamefromscratch.desktop;

import com.badlogic.gdx.backends.lwjgl.LwjglApplication;
import com.badlogic.gdx.backends.lwjgl.LwjglApplicationConfiguration;
import com.gamefromscratch.MyGame;

public class DesktopLauncher {
   public static void main (String[] arg) {
      LwjglApplicationConfiguration config = new LwjglApplicationConfiguration();
      new LwjglApplication(new MyGame(), config);
   }
}

 

This is where you would put the platform specific code related to desktop platforms.  You can see the traditional program main() is here, inside of which we create a simple configuration object and pass it to our LwjglApplication.  LWJGL stands for Light Weight Java Game Library, and it’s the OpenGL layer that LibGDX desktop implementation is based on.  There is a similar entry point created for the Android application, the iOS application and the HTML5 application.  Each and every one creates a new instance of your game class and passes in the platform specific configurations.  Ideally, this is the extent of your platform specific code, but quite often you have to implement some details on a platform by platform basis.

 

If you look at the various config objects being created, you will notice each is full of properties that are specific to that particular platform, like so:

image

 

Splitting your project up into this format makes platform independence mostly an after thought for most developers.

 

I wont be going into depth of the functionality that LibGDX provides, it’s covered in detail elsewhere.  That said, if functionality is required by a game, but isn’t game specific, chances are its in LibGDX.  This includes graphics, audio, input, motion, asset management and much more.

 

LibGDX Tools

 

Not being strictly a game engine, the tooling support in LibGDX is minimal, but there are some tools included, many of which are command-line based.  There is no world editor, animation tools, etc…  The tools are bundled in the project if you included the Tools extension.  The tools include:

image

 

Most of the tools are Java callable and can be invoked from the command line/terminal.  This means integrating them into your build process is trivial.  The primary tools above are for font and sprite sheet creation.  Only hiero and particleeditor are GUI based:

 

Hiero is a tool for creating bitmap fonts from system/ttf fonts:

image

 

The Particle Editor is a GUI tool for creating particle systems:

image

 

Another critical tool, not included by default, is the fbx-conv project, which is used for importing 3D assets into LibGDX.

 

Built on LibGDX

 

Although not directly part of LibGDX, there are some tools build over top of LibGDX and provide some of the functionality typically ascribed to a full game engine.  They include:

 

Overlap2D  A 2D level and UI editor for LibGDX games built over LibGDX

 

GDX-Proto A 3D game engine built over LibGDX

 

BDX Another 3D engine built over LibGDX, this one built over top of Blender as the world editor.

 

Spine A commercial 2D IK animation tool built using LibGDX by the author of Scene2D.

 

 

Documentation and Tutorials

 

Of course, there is the GameFromScratch.com tutorial series, which I happen to think are pretty good, but I’m biased.  On top of that, there is the Wiki, which is pretty comprehensive.  There is also a generated from code complete reference guide, that while a little shallow in spots, is generally quite useful.

 

There are a couple recently published LibGDX books available as well, one which I somewhat recently reviewed.  I am not sure the other books are really needed between the Wiki and tutorials available on this site.  If you want however, there are some beginner oriented books available as well.

 

For support, there is a quite active forum available.  Well worded questions are generally answered quite quickly.  Stackoverflow also sees a fair number of LibGDX questions.  All told, it’s got a very large community, making community based support pretty solid.

 

Conclusion

 

Personally I am a big fan of LibGDX, even though I am not the biggest Java cheerleader you will find.  If you are looking to create complex 3D games, or want extensive editor support, LibGDX is probably not the engine for you.  If you want a code focused, open source, free, accessible cross platform game engine capable of doing 2D or 3D, you really should check out LibGDX.

 

 

The Video

 

Programming ,

26. May 2015

 

I will admit, the end results look a heck of a lot like the starting point, but behind the scenes it was pretty much a complete rewrite of all the underlying CSS and a good chunk of HTML changes.  Sorry for the delay in new tutorials, but the end is finally here.  I ended up keeping a very similar over all layout and colour scheme to the original site.  I had a darker theme temporarily, but it was harder to read and caused me to receive a fair number of less than happy emails… ;)

 

 

So what’s new here?

 

The most immediately obvious is the old interface has been stripped away.  Outdated menus to obsolete tutorials no longer clutter the site.  Behind the scenes, the HTML is optimized and the page should load better.  The biggest changes are highlighted below.

 

Responsive and Mobile Friendly site

 

This was the number one reason behind the rewrite.  Basically Google tied their search rankings to the mobile friendliness of a site.  I could (and did) turn on the mobile theme for the site as a temporary workaround, but having separate styles for different browsers was ugly.  The new site now scales better across a broad range of devices, from high resolution monitors to small mobile screens.

 

Here for example is the site running on my HTC One mobile phone.

GFS

 

The layout is such that an iPad in portrait mode will get the mobile site, while turning to landscape will get you the full UI.  Use the icon in the top right corner to bring down the site menu.

 

New Getting Started Page

 

A lot of people arrive here with no prior experience.  I have set up a new landing page to get them started with a series of simple questions.  I will be expanding upon and improving this area over time.

 

New Game Engines section

 

Over time I did “Closer Look at” guides for a number of game engines.  I have gathered them together into a single resource, and intend to start adding more guides for more popular engines very soon.  Thing of this as an ideal resource for getting started choosing between different game engines.

 

New Tutorials Page

 

This area is still very much a WIP.  Basically I have done a number of tutorials for a number of different  gamedev topic.  This page is going to bring them all together on one spot.  Once again, very much a work in progress.

 

image

 

Video Section

 

I’ve been producing more and more video tutorials, hosted on YouTube and linked from individual blog posts.  The video gallery is an attempt to bring all of these videos together in a single location.  Still very much a work in progress too.

image

 

Miscellaneous Small Changes

 

There were tons of small incremental changes… site actually has icons now, links to Digg removed, tags improved, font and colour changes, etc.  Most importantly though, Google is now happy and hopefully so are you all.

 

Hopefully you find the new site to be an over all more pleasant experience.  Some things are still in a WIP stage, but good enough IMHO that I can focus again on creating content while I slowly fix the rough edges.  There are bound to be a few bugs, so if you catch one, let me know.  Also, if you absolutely hate a change I’ve made, please also let me know!

News

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 ,

Month List

DisqusCommentsSummary