Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
8. November 2014


Amber have just open sourced Copperlicht, a WebGL 3D JavaScript engine.  Copperlich was previously available for 99 Euro per year.



Here is an overview of Copperlicht’s functionality:

  • 3D World editor: CopperLicht comes with a full 3D world editor named CopperCube.
  • Many supported 3D file formats: 3ds, obj, x, lwo, b3d, csm, dae, dmf, oct, irrmesh, ms3d, my3D, mesh, lmts, bsp, md2, stl, ase, ply, dxf, cob, scn and more
  • Built-in Collision detection: Throw a polygon soup into the engine and walk around the 3D world.
  • Lots of 3D graphics features, see below.
  • Incredibly fast: CopperLicht is highly optimized and able to render and animate even huge 3d scenes.
  • Character/Skeletal animation: supports playing back animated meshes with an unlimited amount of joints and an unlimted amount of weights
  • Simple to use: easily understandable SceneGraph API with lots of tutorials and examples in the documentation
  • Binary compilation: Unlike other WebGL 3D Engines, CopperLicht compiles your 3D meshes into a small, binary file which downloads quickly, reducing bandwith usage for your users. Simply import your 3D files into the CopperCube editor and publish it as CopperLicht scene.
  • Totally free: CopperLicht is free to use. And open source. Just download and go!


You may notice the strike through that Copperlicht includes a 3D world editor; this isn’t entirely true with the open sourced version.  There is a commercial editor available named CopperCube, however it is a commercial product


I have to say, I like this move.  You can create a full game using Copperlicht without the editor, while the editor is available on a 14 day trial.  This means people can contribute to a Copperlicht project without paying money, but there is a value add sell that means the developer can eat!  I hope this will result in an increase in popularity for Copperlicht that in turn increases sales for Coppercube, which would be win/win.  I personally would like to see the demo extended to 30 days, or preferably be 14 actual days, not 14 calendar days.


This announcement is quite timely, as I just recently had this conversation on Twitter:




I feel almost prescient!


This is a slightly different business model, but one I firmly support.  On the whole I think this is a great change.  I have used Irrlicht in the past and was impressed by the engine.  Now I am going to look closer at Copperlight and possibly due a tutorial series on it in the future.  Now that Copperlicht and Coppercube are a bit less intwined, I wonder if Coppercube could move to being more agnostic and be of use to say… Three.js or Turbulenz.


Are you at all interested in hearing more about the Copperlicht engine here on GameFromScratch?


7. November 2014



I’ve already cheated a few times using physics with the caveat that “I will cover this later”.  Well, welcome to later!  One thing you should be aware of right away is that there are a number of different physics engines available in Phaser.  In this particular tutorial we are going to cover Arcade physics, but there is also P2, Ninja and coming soon as a premium plugin, Box2D.


You may be thinking to yourself… huh?  Why the hell are there 3+ physics engines?   Let me try to break it down as best as I understand it.  First thing to know is, there is zero overhead from all of these systems, you need to enable them before you can use them, so you only pay the costs of what you need.


The Physics systems in Phaser are:

  • Arcade is a light weight engine, not the most accurate or full featured, but fast.  It’s also historically what was in Phaser all along.
  • P2 is an existing Javascript physics library.  It’s far more featured than Arcade, but also a lot slower as there is a ton more calculations going on behind the scenes.
  • Ninja… well Ninja I don’t entirely get the purpose behind.  As best I understand it, the author of Phaser, Richard Davey, wrote it a while ago and ported it from Flash to Phaser.  I think it falls somewhere in between Arcade and P2 in the feature/performance scale.  It’s stripped down in functionality from P2.
  • Box2D, well first off, it’s not available yet.  It is about as close to industry standard as 2D physics systems get though.


You can also use more than one physics system at a time, but they wont interact.  So if you have something either with tons of them in the scene ( say bullets or particles ) or where you need only basic physics, you can use Arcade.  Then if you require more accuracy, use P2.


This particle tutorial is going to look at Arcade Physics.  Let’s start with a very simple example.  We are going to enable physics, turn on gravity and enabled a sprite to be a physics body.

/// <reference path="phaser.d.ts"/>
class SimpleGame {
    game: Phaser.Game;
    player: Phaser.Sprite;

    constructor() { = new Phaser.Game(640, 480, Phaser.AUTO, 'content', {
            create: this.create, preload:this.preload, render: this.render
    preload() {"decepticon", "decepticon.png");
    render() {
        // This renders debug information about physics bodies;
    create() {
        this.player = / 2, 0, "decepticon");

        // Start the ARCADE Physics system;
        // Enable physics on the player sprite, Phaser.Physics.ARCADE);

        // Set the sprite to collide with the worlds edge
        this.player.body.collideWorldBounds = true;
        // And set bounce in the Y axis ( called restitution in most physics system ) to 1, 
        // which will make it bounce equal to 100 %
        this.player.body.bounce.y = 1;

        // Set the physics engines overall gravity.  98 == 98 pixels per second in this demo = 98;

window.onload = () => {
    var game = new SimpleGame();


Run it:



This example is pretty heavily commented, so I wont go into much detail.  It illustrates a few key concepts.  First, you need to start the physics subsystem before you can use it.  Second, you need to initialize a sprite to be a physics object.  Finally, you can render debug information using game.debug.body(), which will draw the bounding box as seen by the physics engine.  This can be incredibly useful for debugging physics simulation problems.


Now one of the very first things people are going to want to use a physics engine for is collision detection, so lets do that next!

/// <reference path="phaser.d.ts"/>
class SimpleGame {
    game: Phaser.Game;
    player1: Phaser.Sprite;
    player2: Phaser.Sprite;

    constructor() { = new Phaser.Game(640, 480, Phaser.AUTO, 'content', {
            create: this.create, preload: this.preload,
            render: this.render, update: this.update
    preload() {"decepticon", "decepticon.png");
    update() {
        // Now check for a collision between objects, this.player2);
    render() {
    create() {
        this.player1 =, / 2 - 50, "decepticon");
        this.player2 =, / 2 - 50, "decepticon");;

        // You can enable multiple bodies at once by passing in an array like so:[this.player1, this.player2]);
        this.player1.body.collideWorldBounds = true;
        this.player2.body.collideWorldBounds = true;

        // Set the players to bounce along x axis instead
        this.player1.body.bounce.x = 1;
        this.player2.body.bounce.x = 1;

        // Now set them moving.  Move to the center of the screen accelerating to 100pixels per second, / 2,
                                       / 2 - 50, 100);, / 2,
                                       / 2 - 50, 100);
        = 0;

window.onload = () => {
    var game = new SimpleGame();

And the results:


This example shows us a couple things.  Most important is for collisions to occur you need to test for them using collide().  You can also see from this example that it’s possible to initialize multiple physics bodies at once by passing all the sprites in to game.physics.arcade.enable as an array.  This demo also illustrates that you can easily turn gravity off in a simulation.


In this particular demo we used AccelerateToXY to get our bodies moving.  There are a number of other functions for moving physics bodies, checking for intersections, measuring distances and angles available in the Physics.Arcade class, they work fairly straight forward so I leave exploring them as an exercise for the reader.  There are a few final concepts I want to touch on before moving on.


The first is collision handling.  The above example simply tested if a collision happened.  Phaser Arcade physics however give you a great deal more control than that, as will now see.  When you call collide() you have the option of passing in a pair of callbacks, like so:

    update() {
        // Now check for a collision between objects, this.player2,
            // This callback is called when a collision occurs
            // In this example we scale object1 on collision until its 2x bigger in size
            (object1: any, object2: any) => {
                // object1 and object2 will be either of type Sprite, Group, Tilemap or Particle Emitter
                if (object1 instanceof (Phaser.Sprite)) {
                    (<Phaser.Sprite>object1).scale.multiply(1.1, 1.1);
                    if ((<Phaser.Sprite>object1).scale.x > 2) {
                        (<Phaser.Sprite>object1).scale.set(1, 1);
            // This callback is called for additional testing, AKA user driven logic on if a collision occurs
            // If you return true, a collision occured, if you returned false, a collision doesn't occur
            // In this example, object checks the direction in the X axis it's moving, if moving right to left
            // then a collision wont occur.  As a result, the first collision test 
            //both objects will pass through each other.
            (object1: any, object2: any) => {
                if (object1 instanceof (Phaser.Sprite)) {
                    if ((<Phaser.Sprite>object1).deltaX < 0)
                        return false;
                        return true;

Which when run results in:

The code comments explain most of what happens.  Basically you have a pair of callbacks available.  The first one is the action to perform IF a collision occurs, in addition to any action the physics engine is going to take that is.  In this simple example, we scale one of the two colliding objects up until it’s size has doubled.  As you can see, the colliding and collided objects are passed in to this function.  The type of this object can be a Sprite, Group, Particle Emitter or Tilemap.  We actually used Arcade Physics in earlier tilemap and particle tutorials if you want more details on collisions between these types. 


The second callback determines if a collision occurs at all.  Returning false out of that function means that no collision occurred, while true indicates one did.  If you run this example ( click here to open it in a new browser as it’s probably already run too far ), you will notice that on the first pass, no collision occurs.


The final thing I want to touch on is grouping.  As mentioned above, in the collision callbacks, one of the types of collisions that can occur is between groups.  I am not going to go into detail as I already covered grouping earlier, but I wanted you to be aware that you can group sprites together then perform collisions that way.  This is handy when you have a large number of similar sprites, such as bullets, because frankly doing a collide() call for each possible combination get’s old quickly!


In the future I will look at some of the other physics systems, but for quick and dirty collisions and simple physics, Arcade Physics should be enough.



6. November 2014


I will admit, I am somewhat late to this party… I’ve shared a project or two to Github in the past, but I’ve never really embraced it.  It’s one of those things I should probably change and I will start to address. 


So here we are starting with the code samples for the TypeScript with Phaser series.  For many tutorials I often didn’t keep the solutions I used to create examples, so I have nothing to share.  However for this series, I have done all of the work in a single Visual Studio solution, so it made pushing it up to Github easy.  You will find 90% of the examples from that series are now available on Github.  For a few minor samples, I simply made changes to the base project to come up with the derived code, so you wont find those ones.  I pushed everything up, so that means all the assets used are included too.  Since I continue to use this single solution for the entire project, as I add new examples, they will be available on Github as well.


You can access all the samples here on Github.




I will be the first to admit, I know very little about Github as anything other than a consumer, so expect so tales of epic stupid while I get the hang of things.  Right now there are 29 projects in the PhaserTypescript repository, although PhaserArcade is a WIP ( guess what I’m working on… ).


Let me know if I’ve made any mistakes here. Hope this code proves useful to somebody.


5. November 2014


One of the challenges of working on the iPad only is the lack of animation and composition tools.  There are tons of art applications out there as we saw earlier, but nothing for getting them into game ready form.  So I had a bit of an idea and ran with it.


The basic idea is I am using iDraw to create individual body parts, which I then add to shape libraries so I can see how it will look all put together.  My game is going to be giant robots, so I can take a mix and match approach to character composition.  By building out the characters from parts, I can then create a variety of characters using minimal art.  Here is the process in iDraw:



The problem is, when I export the end result into Codea, I don’t have something that I can use.  I would have to export each frame of animation for each mech combination one by one from iDraw to Codea to get an animated resulted, which ruins almost all of the benefits.


So, essentially, what I have to do, at least initially, is reproduce this functionality in Codea, so I can then create animations and variations without a massive increase in body parts.  So that is exactly what I did.  In a second you are going to see massive walls of code that I used to accomplish the task.  First I should make a few things clear.


The biggest one is, this is one of those things I am doing for fun, so most of this code was written during intermission between hockey periods, while waiting for something or while falling asleep in bed.  On the one hand, it’s really really cool that you can code at those times.  On the other hand… code quality tends to suffer a bit.


The next is along the same lines.  Lua is one of those languages that encourages experimentation… and a language that I haven’t used in a while.  A lot of times I got something to work and refactored later, if at all.  So if you see some things that make you aghast… that is probably why! :)  I am by no means done… at this point I’ve mostly just replicated the functioning above, I still intend to add several features before the tool is usable.  First and foremost I need to keyframe animations.  I added the controls, just no logic.  Of course I also need to save the results so they can be used in another game.  On top I want to polish the functionality by adding parenting, different control modes ( selection, parenting, positioning, animating ).  That all said, you do see the skeleton of a genuinely useful tool written entirely in Lua on an iPad.


This is VectorPoser




The code, although rather ugly and in need of refactoring, is pretty well commented, so it should require minimal explanation… I hope.


Main.lua This is the application entry point.  Most of the touch logic is currently handled here, but should slowly be moved out


-- VectorPoser

-- welcome to the league of evil globals
imageList = nil  -- The image selector down the side of the screen
cachedWidth = WIDTH -- The original width, used to check if screen width changes
character = nil -- The character you are working on
selectedPart = nil -- The currently selected part of the character, if any
animationControl = nil -- Functionality, coming soon, stay tuned!

-- Use this function to perform your initial setup
function setup()
    local files = spriteList("Dropbox")
    local vectors = {}
    for k,v in pairs(files) do
        table.insert(vectors,readImage("Dropbox:" .. v))
    imageList = ImageList(WIDTH-100,HEIGHT,100,HEIGHT,vectors)
    character = Character(WIDTH/2,HEIGHT/2)
    animationControl = AnimationControl(60,0)

-- This function gets called once every frame
function draw()
    background(40, 40, 50)
    update()  -- put all non rendered updates in a single function so we can eventually decouple
              -- updating from the rendor loop, maybe, someday, I promise. Maybe.
    -- This sets the line thickness in pixels I think
    -- render our image list, which again is the list of images down the right hand side
    -- now draw our VCR style animation controls
    -- clip our viewport so it wont draw in the same space as the image list
    -- now draw our character

function touched(touch)
    -- pass along touches to all the touchables so they can be touched, duh!

    -- TODO, spin the following code out to a function or class so we can have different 
    -- touch handling in different modes 
    -- Check to see if there is a currently selected part
    if selectedPart then
       -- if something is already selected, continue until touch up 
        if(touch.state == ENDED or touch.state == BEGAN) then
            -- If the touch ended or paradoxally began, unselect the active part and trigger 
            -- changed so UI updates
            selectedPart = nil
            -- otherwise move the selected part to the touched location
            selectedPart.x = touch.x
            selectedPart.y = touch.y
            -- now update so parameters get updated
        -- There is no currently selected part, check if this touch hits an existing part
        local hits = character:getPartsAtPoint(touch.x,touch.y)

        if #hits > 0 then
            -- find the highest z value and make it selected
            -- yes, this makes touches items behind other items a pain in the ass
            for i,v in pairs(hits) do
                if selectedPart == nil then selectedPart = v
                    if v.z > selectedPart.z then
                        selectedPart = z
            -- Notify UI of the change
    -- if you swipe the right edge right, hide the ui off the screen to the right
    -- on swipe left nring it back on screen
    -- TODO: Move logic into the ImageList
    if touch.x > WIDTH-100 then
      -- clear selection if user clicks off main area
          selectedPart = nil
        if touch.deltaX < -20 then
            --left swipe
            local x,y = imageList:getPosition()
            if x == WIDTH then
        if touch.deltaX > 20 then
                -- right swipe
        -- otherwise lets clear selected if touched anywhere else
        local img = imageList:getSelected()
        if img then


-- handle all non graphical updates on a per frame basis
function update()

-- called when device is changed from landscape to portrait and vice versa
-- we need to resize our ImageList
function orientationChanged(orientation)
    if imageList then

-- there may be a better way to do this, but check for a change in size, specifically
-- due to parameters windows going away and coming back causing a resize
function checkResize()
    if cachedWidth ~= WIDTH then
        -- resize occured, handle accordingly
        cachedWidth = WIDTH
        -- TODO: This currently brings hidden panel back on screen... probably shouldn't
        imageList:setPosition(WIDTH -100,HEIGHT)

-- when the selected part changes update params
function selectedPartChanged()
    if selectedPart == nil then
        -- z axis changed
        parameter.integer("Z order",0,20,selectedPart.z,
        function(val) selectedPart.z = val end)
        -- delete button, remove selected part from character
        function(val) selectedPart.rotation = val end)


ImageList.lua This is the control down the right hand side that enables you to select images.  It handles scrolling up and down, as well as flick left to hide flick right to show.  Most of the logic is in displaying the images and mapping from touch to selected image.

-- imagelist is for displaying a number of images for selection
-- supports scrolling via long drag up and down

ImageList = class()

function ImageList:init(x,y,width,height,imgs)
    -- you can accept and set parameters here
    self.x = x
    self.y = y
    self.width = width
    self.height = height
    self.imgs = imgs
    self.IMAGE_HEIGHT = 100
    self.maxVisibleImages = math.floor(self.height/self.IMAGE_HEIGHT)
    self.topImageIndex = 0
    self.selected = nil
    self.touchDeltaY = 0

function ImageList:draw()

function ImageList:touched(touch)
    if self:_isTouchInFrame(touch) then
        if touch.state == ENDED then
            self.touchDeltaY = 0
        -- as the user swipes up or down within the imagelist track the y delta
        -- if it exceeds 50 increase or decrease the topImageIndex
        -- thus scrolling the available images
        if touch.state == MOVING then
            self.touchDeltaY = self.touchDeltaY + touch.deltaY
            if self.touchDeltaY > 50 then
                if self.topImageIndex + self.maxVisibleImages <= #self.imgs then
                    self.topImageIndex = self.topImageIndex + 1
                self.touchDeltaY = 0
            if self.touchDeltaY < -50 then
                if self.topImageIndex > 0 then
                    self.topImageIndex = self.topImageIndex - 1
                self.touchDeltaY = 0


-- draw a frame around our control
function ImageList:_drawFrame()
    stroke(13, 0, 255, 255)
    line(self.x,self.y,self.x + self.width, self.y)

-- draw the visible images within our control
function ImageList:_drawImages()
    local currentY = 0
    for i= self.topImageIndex,self.topImageIndex+self.maxVisibleImages do
        local curImage = self.imgs[i]
        if curImage then
            local aspect = curImage.width/curImage.height
            if aspect < 1 then -- taller than wide
            sprite(curImage,self.x +self.width/2,self.y-currentY-self.IMAGE_HEIGHT/2,self.width * aspect
,self.IMAGE_HEIGHT) else -- when its wider than tall, shrink it proportionally local newHeight = self.IMAGE_HEIGHT * aspect - self.IMAGE_HEIGHT sprite(curImage,self.x +self.width/2,self.y -currentY-self.IMAGE_HEIGHT/2,self.width,
newHeight) end currentY = currentY + self.IMAGE_HEIGHT end end end -- draw a line above and below selected image function ImageList:_drawSelection() if self.selected then rectMode(CORNER) strokeWidth(2) stroke(255, 16, 0, 255) local x = self.x local y = self.y - (self.selected -1)* self.IMAGE_HEIGHT fill(255, 4, 0, 255) line(x+5,y,x+self.width-5,y) line(x+ 5,y-self.IMAGE_HEIGHT,x + self.width-5, y-self.IMAGE_HEIGHT) end end -- convert to local coordinates and figure out which item is selected at touch position function ImageList:_touchToSelected(touch) -- convert touch relative to top left of screen if self:_isTouchInFrame(touch) then -- local localX = touch.x - self.x local localY = self.y - touch.y local offset =math.ceil(localY/self.IMAGE_HEIGHT) if offset <= #self.imgs then self.selected = offset else -- self.selected = nil end end end -- check if touch within the bounds of our control function ImageList:_isTouchInFrame(touch) if touch.x >= self.x and touch.x <= self.x + self.width and touch.y <= self.y and touch.y >= self.y - self.height then return true end return false end function ImageList:setPosition(x,y) self.x = x self.y = y end -- handle resize, mostly for orrientation change function ImageList:setDimensions(width,height) self.width = width self.height = height self.maxVisibleImages = math.floor(self.height/self.IMAGE_HEIGHT) end function ImageList:getPosition() return self.x,self.y end -- gets the index into the img array of the selected image function ImageList:getSelectedIndex() if self.selected then -- hack for foggy brain -- if self.topImageIndex > 1 then self.topImageIndex = self.topImageIndex - 1 end return self.selected + self.topImageIndex end return nil end function ImageList:clearSelected() self.selected = nil end -- gets the actual image function ImageList:getSelected() return self.imgs[self:getSelectedIndex()] end


Character.lua -- This holds the character we are creating. Mostly just a collection of VectorPart now, but more functionality will be coming in the future

-- a character is composed of several VectorParts.
-- this will ultimately be the class you use to control everything as a single entity
-- AKA, the end result

Character = class()

function Character:init(x,y)
    -- you can accept and set parameters here
    self.x = x
    self.y = y = {}

function Character:draw()
    -- order drawing by z order
        function comp(a,b)
            if a.z < b.z then return true end
            return false

    for i,v in ipairs( do

function Character:touched(touch)

function Character:addPart(part)
     part.z = +1 -- z order equal order added initially

function Character:removePart(part)
    if(part) then

function Character:getPartsAtPoint(x,y)
    local results = {}
    for i,v in pairs( do
        if x >= v.x - v.img.width/2 and x <= v.x + v.img.width/2 and
            y >= v.y - v.img.height/2 and y <= v.y + v.img.height/2 then
            v.curIndex = i
    return results

function Character:getParts()


VectorPart.lua -- These are the individual parts, right now it's just the image, x,y and rotational data, but in the future it will have pivot and parenting information. Keyframe data will essentially be a snapshot of these values per animation frame

-- A vector part is simply the vector img, plus positional and rotation data
-- will be adding parenting information

VectorPart = class()

function VectorPart:init(img,x,y,z)
    -- you can accept and set parameters here
    self.img = img
    self.x = x
    self.y = y
    self.z = z
    self.rotation = 0
    self.curIndex = nil

function VectorPart:draw()

function VectorPart:touched(touch)


AnimationControl.lua -- This is a VCR style keyframe animation control, mostly just a placeholder for now

AnimationControl = class()

function AnimationControl:init(x,y)
    self.x = x
    self.y = y
    self.buttonFirst = IconButton("First",x+0,y+0,64,64,"Documents:IconFirst","","")
    self.buttonFirst.callback = _firstButtonPressed
    self.buttonPrevious = IconButton("Previous",x+66,y+0,64,64,"Documents:IconPrevious","","")
    self.buttonPrevious.callback = _previousButtonPressed
    self.buttonPlay = IconButton("Play",x+66*2,0,64,64,"Documents:IconPlay","","")
    self.buttonPlay.callback = _playButtonPressed
    self.buttonNext = IconButton("Next",x+66*3,y+0,64,64,"Documents:IconNext","","")
    self.buttonNext.callback = _nextButtonPressed
    self.buttonLast = IconButton("Last",x+66*4,y+0,64,64,"Documents:IconLast","","")
    self.buttonLast.callback = _lastButtonPressed

function AnimationControl:draw()

function AnimationControl:touched(touch)
    -- Codea does not automatically call this method

function _firstButtonPressed()
function _previousButtonPressed()
function _playButtonPressed()
function _nextButtonPressed()
function _lastButtonPressed()


Finally I used a library called Cider for the UI controls. You can get Cider here. I used the IconButton class, but it didn't have callback support, so I hacked it in like so:

--# IconButton
IconButton = class(Control)

-- IconButton 
-- ver. 7.0
-- a simple control that centers an image in a frame
-- ====================

function IconButton:init(s, x, y, w, h, img, topText, bottomText)
    Control.init(self, s, x, y, w, h)
    self.controlName = "IconButton"
    self.background = color(255, 255, 255, 255)
    self.font = "HelveticaNeue-UltraLight"
    self.fontSize = 32
    self.img = img
    self.text = s
    self.topText = topText
    self.bottomText = bottomText
    self.textAlign = CENTER
    self.smallFontSize = 12

function IconButton:draw()
    local h, w
    w, h = textSize(self.text)
    fontSize(self. smallFontSize)
    w, h = textSize(self.topText)
    text(self.topText, self:midX(), self:top() - h / 2 - 4)
    if self.bottomText then
        text(self.bottomText, self:midX(), self:bottom() + h/2 + 4)
    if self.img == nil then
        text(self.text, self:midX(), self:midY())
        sprite(self.img, self:midX(), self:midY())

function IconButton:initString(ctlName)
    return "IconButton('"..self.text.."', " ..
        self.x..", "..self.y..", "..
        self.w..", "..self.h..", '"..
        self.img .. "', '"..
        self.topText .. "', '"..
        self.bottomText .. "', '"..

-- added by mjf... not sure why there wasnt a touch handler on this control
function IconButton:touched(touch)
        if self:ptIn(touch) then
            if touch.state == ENDED then
                if self.callback ~= nil then self.callback() end
                return true


There is some bugginess around the selectedPart handling that leads to the occasional crash, and I am on occasion crashing Codea if I use lots of images, but for the most parts, it's the skeleton of a downright usable tool. It's never going to compete with the likes of Spline or Spriter, but it should suffice for making game ready models and animations from sprite and vector graphics and at the end of the day, that's all I need. Stay tuned for an update sometime in the future.


3. November 2014



Now we are going to look at using particles in LibGDX.  This is a somewhat complex subject, so I am going to break it over a couple posts.  In this first example, we are going to create a 2D particle system in the editor.  Then we are going to write the code to run the particle system.  This process can be somewhat confusing, especially running the Particle Editor, so I have also done a video version of this tutorial.  Don’t worry, I will always continue to do text versions of all LibGDX tutorials, I am just going to mix in video when I think it will help.


So if you prefer, this topic is available in the video below.  Click directly on Youtube to see it in full resolution.  Once again, this video covers exactly the same content the text below does.


In this tutorial we are going to use one of the tutorials included with LibGDX, the particle editor.  In order to follow along you need to install the gdx-tools in your project.  Fortunately this is a pretty easy process.  When you run the setup utility to create your project, make sure you set tools to true.




This will result in the particle editor being included in your project dependencies.  Now it’s a matter of running the ParticleEditor, which isn’t as obvious as you would think.


You can run it from the command line, but this presents a certain special challenge, since LibGDX moved to a Gradle based setup…  so, where exactly is gdx.jar these days?  That’s a good question, and the answer is very very well hidden.


First make sure you’ve built your project at least once, so then all of the dependencies have been resolved ( AKA, Gradle downloaded LibGDX ).  Now LibGDX will be located somewhere in your Maven repository, which is a hidden folder.  The actual directory it will be in is random thanks to a GUID key.  On my computer on Windows its:



Obviously on your computer this will be somewhere else, and it will change with each version.  Now that you located it, you can run it.  Fortunately there is a much easier option for running the particle editor if you use either Eclipse or IntelliJ IDEA.  I will cover each in turn below ( and also show both in the video above ):




Once you’ve loaded your project into IntelliJ IDEA.  Now in your Projects window, locate gdx-tools.jar ( there will be a version number too, currently 1.4.1 ).




Expand it until you find particleeditor, then locate the class ParticleEditor.


Now right click ParticleEditor and select Run ParticleEditor… main():




The first time you need to set some configuration values:



Really, all you need to do is set the Use classpath value to your desktop module.  Now click Run:



One working Particle Editor.




Eclipse is actually much simpler… if it works, which is a big if.

Simply import your project.  Then right click your desktop project, select Run As or Debug As->Java Application.




It should now prompt you to select which Java Application to run:


Select ParticleEditor – and click OK.

The Particle Editor will now load.


Your First Particle Effect


Now that you’ve got the particle editor open, let’s save an effect to work with. 

In this particular tutorial we are just going to go with the default as it is already configured, which is a flame looking effect.  Locate and click the save button:


We want to save the resulting file to our assets folder.  If you have an Android project it will be located at [project]/android-proj/assets otherwise it will be in [project]core-proj/assets.  Save the file there, the extension doesn’t matter.  For this code example I am using


Code Time


Now let’s take a look at the code required to display this effect:


package com.gamefromscratch;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;

public class Particles extends ApplicationAdapter {
   SpriteBatch batch;
   ParticleEffect pe;

   public void create () {
      batch = new SpriteBatch();

      pe = new ParticleEffect();

   public void render () {, 0, 0, 1);;

      if (pe.isComplete())


When you run this app you should see:




It’s pretty consistent with the way most other systems work in Android.  You create the ParticleEffect then load it from file at the root of your assets folder.  We then position the emitter at the center of the screen.  Particle emitters are the source of particles and are often used to control over all behavior.  We then start the particle system running.


In render, just like with physics systems, we need to advance the particle effect using update().  This causes the simulation to calculation the position, colour, etc… of all the particles it controls.  Next we draw the ParticleEffect using draw() and drawing to our sprite batch.   Finally we check to see if the effect is complete, and if it is, we restart it.


Obviously we glossed over the Particle Editor tool, as well as 3D particle effects, so expect more tutorials soon.



AppGameKit Studio

See More Tutorials on!

Month List