Particle Effects: Adding Texture To Your Canvas Game

This is part 4, the conclusion to a series that details our team’s journey to creating disasteroids.com for NodeKnockout 2012, a 48 hour coding competition that showcases projects built on node.js. You can find part one here, part two here, and part three here.

We Need Eye Candy!

Once we got the basic physics and rendering in place it was time to figure out how to make the explosions and rocket trails.  We initially had something like Scorched Earth in mind where the rockets draw a permanent trail, but we weren’t tied to the idea. After some quick hunting around we came across Javascript Particle System by @jsoverson and we were sold.  It’s more of a demo than a library meant for reuse, so there are no docs.  Luckily it was written pretty well and it wasn’t too hard to discern how to use it and pull out the functionality we needed.

There are six objects at the core of the particle system.

• Display - Wrapper for canvas element
• ParticleSystem - This runs the show and tells all the other element what to do
• Vector - A wrapper for x,y coords with some convenience methods
• Particle - represents an individual particle
• Field - Basically a source of gravity.  negative gravity is repulsion.
• Emitter - Emits particles

Initialization

Basically how it works is you wrap a canvas element in a Display object which you then pass into ParticleSystem’s init like so:

// wrap canvas with Display and initialize
var display = new Display(this.canvas);
display.init();

// Initialize ParticleSystem and init with display
var particleSystem = new ParticleSystem().init(display);

// set an upper limit for total number of particles
particleSystem.maxParticles = 10000;

// start
display.start();

Missile Thruster Particle Trail

Once this is done all you need to do is create an Emitter and push into the appropriate array and the particle system will do the rest. for example, here is a piece the render method for a missile:

    
render: function(canvas, particleSystem) {
  var self = this;

  // play shoot sound
  app.playAudio('rocketShoot');

  // create local handle for particle system
  this.particleSystem = particleSystem;
      
  // create new emitter called thruster
  this.thruster = new Emitter();

  // set parameters
  this.thruster.position = new Vector(self.model.get('x'), self.model.get('y'));
  this.thruster.velocity = Vector.fromAngle(self.model.get('angle')*180/Math.PI, 5);
  this.thruster.size = 0;
  this.thruster.particleLife = 100;
  this.thruster.spread = .5;
  this.thruster.emissionRate = 0.5;
  this.thruster.jitter = 0;
  this.thruster.particleColor = [255,130,0,1];

  // push emitter into particle system
  particleSystem.emitters.push(this.thruster);
}

This starts shooting particles out of the back of the missile.  Since we already have all the math done to update the missiles position and angle, we can simple hook into that in the missiles reposition method.

    
reposition: function(model) {
  var self = this;
  
  // reposition the missile
  this.object.set('left',self.model.get('x'));
  this.object.set('top', self.model.get('y'));
  this.object.set('angle', self.model.get('angle')*180/Math.PI);
      
  // reposition the thruster emitter
  var thrusterVector = Vector.fromAngle(self.model.get('angle') + Math.PI/2, self.model.get('height')/2);
  this.thruster.position = new Vector(self.model.get('x') + thrusterVector.x, self.model.get('y') + thrusterVector.y);
      
  // update the angle so it is always shooting out the tail of the missile
  // velocity takes a vector that governs the angle as well as the speed
  this.thruster.velocity = Vector.fromAngle(self.model.get('angle') + Math.PI/2, 2);
}

That gives us a missile with a particle trail!

Explosions and Blasts

Now we just need to handle what happens when the missile hits something.  Basically what we want to do is:

1. remove the truster emitter
2. create an explosion emitter
3. create a repulsion field so the particles don’t just emit in a circle but get blasted away
4. wait a bit and remove the explosion and repulsion field.

exit: function() {
  var self = this;

  // play impact sound
  app.playAudio('rocketImpact');
      
  // remove thruster
  this.particleSystem.removeEmitter(this.thruster);

  // create explosion emitter and set params
  this.explosion = new Emitter();
  this.explosion.position = new Vector(this.model.get('x'), this.model.get('y'));
  this.explosion.velocity = new Vector(0, 5);
  this.explosion.size = 0;
  this.explosion.particleColor = [255,50,0,1];
  this.explosion.spread = 50;
  this.explosion.emissionRate = 10;
  this.explosion.particleLife = 7;

  // create repulsion field and set params
  // remember negative gravity will repel
  this.repulsion = new Field(this.explosion.position, -1000);
  this.repulsion.size = 0;

  // push explosion and repulsion field into particleSystem
  this.particleSystem.fields.push(this.repulsion);
  this.particleSystem.emitters.push(this.explosion);
  
  // wait 250ms and remove the explosion
  setTimeout(function() {
    self.particleSystem.removeEmitter(self.explosion);
  }, 250);

  // wait 1500ms and remove the repulsion field
  // the wait is longer here so the particles can all get blown away
  setTimeout(function() {
    self.particleSystem.removeField(self.repulsion);
  }, 1500);
}

That gives us a nice particle explosion that blasts away debris

The End

Thats the gist of how the particle physics implementation works.  Thanks for taking time to read and we hope you have fun playing the game as well.

Note: We did have to customize the Javascript Particle System a bit to meet our needs.  Primarily to allow for different sized particles and different colors.  It also depended on require.js, which we removed as well.  Here is the custom code on github.  Thanks again to @jsoverson for making such a cool and extendable project.  

VOTE!

If you enjoyed disasteroids.com or this post, please consider throwing us a vote on our team’s page. It requires Facebook authentication to ensure that there isn’t rampant cheating, but the awesome NodeKnockout organizers @visnup and @gerad would never use your information in a malicious way. They’ve been crazy enough to organize this event for the 3rd year now despite the operational headaches of putting together such a massive event.

Making it Feel Real: Math and fabric.js

This is part 3 of an ongoing series that details our team’s journey to creating disasteroids.com for NodeKnockout 2012, a 48 hour coding competition that showcases projects built on node.js. You can find part one here and part two here.

REALIZING THE WORLD:

With Bundy putting together the physics and world state and Travis crafting the design assets, one of the remaining tasks was fitting the two together in a way that looked good and made sense. In essence, we needed to create the world that the user sees. This process fell fairly neatly into two main pieces:

1. Adjusting the state of the physical box2d objects so that they behaved in an intuitive way.
2. Fitting design assets (mechs, missiles, asteroids) to client-side view objects and updating those view objects with the proper state data to display them correctly.

MATHEMATICS OF ALIGNMENT:

Warning, mild math ahead: We had the physics engine running fairly early in the competition, and we quickly realized that the objects we created behaved like one would expect objects to behave in space. When objects were created and set into motion, they would maintain their orientation until they collided with something. When they collided, the involved bodies would careen off into space spinning wildly until they landed on an asteroid, often sideways, upside down, or somewhere in between. This caused two visual problems:

1. When a player jumped, it was very unlikely that they would land on their feet.
2. When a missile was fired, it didn’t always point in the direction it was traveling.

Thankfully, box2d has a method for bodies called SetAngle(), which allowed us to set the orientation of any body at any point in time. All that remained to solve these issues was a little bit of trigonometry:

The nonsensical chicken-scratches you see above were just the desperate musings of a math major who took trigonometry way too long ago. The actual calculations behind these alignment solutions were really quite simple. Let’s examine the player alignment problem first.

If we want to ensure that a player flying through space lands on their feet on an asteroid, at the point of impact we need to adjust the angle of the player object such that its angle corresponds to the angle defined by the player body’s relative position to the center of the asteroid. If that didn’t make much sense, here’s a diagram to help illustrate the idea:

We can find the angle, theta, by using the triangle formed by the coordinates of the centers of the player and asteroid bodies. Since we have the opposite and adjacent sides of the triangle relative to theta, we can use the inverse tangent to solve for theta:

Now that we have a method for alignment, we need to decide when to align. We chose to define a distance from the asteroid, or a “Radius of calculation” to govern this rule. When a player falls within the radius, it constantly recalculates its new angle and aligns itself until it comes to rest:

Perfect, right? Almost. We just need to account for multiple asteroids. We don’t want the player aligning to any old asteroid on the field. What we did was ensure that the player was only aligning to the nearest asteroid surface. This was calculated with the standard formula for distance. Once implemented, this solution worked pretty well, although unfortunately, some bugs still do exist as players are landing on their heads every now and then.

Now, using the same principles, aligning the missile is pretty easy. We just want to point the missile in the direction it’s going. Box2d has a method that allows us get the linear velocity vector of a body, basically how fast and how much in the x and y directions a body is moving. With these x and y values we can draw a similar triangle to one for the player angle, and determine the angle from the inverse tangent of the relationship of the sides:

That pretty much covers the math involved with object alignment. I will mention that determining the firing angle of the missiles involved some trigonometry as well, but the calculations were similar enough to omit here. Overall the math is simple, involving only triangles and polar coordinate conversion, but it’s the application of the formulas that give the world its proper look and feel.

ENOUGH MATH, BACK TO THE SHINY STUFF:

Now that the objects are behaving properly on the backend we need to make sure that they are represented properly on the frontend. Rather than drawing directly to HTML5 canvas, we chose to use a framework that managed the drawing for us. We landed upon fabric.js. It allowed us to define objects and render SVG (Scaleable Vector Graphics) based on an object’s x position, y position, angle, and scale. Once we created the data models to receive and hold this state data from the server, rendering the objects was as simple as updating the fabric object instances. Then each object was re-rendered with each draw cycle.

Fabric.js was a fantastic find that saved us a lot of time. It removed a lot of the headache of rendering which allowed us to focus on other aspects of the projects. Even more, it played nice with other canvas rendering systems like particle effects, which Josh will detail in our next post.

Part 4: Particle Effects Adding Texture To Your Canvas Game

VOTE!

If you enjoyed disasteroids.com or this post, please consider throwing us a vote on our team’s page. It requires Facebook authentication to ensure that there isn’t rampant cheating, but the awesome NodeKnockout organizers @visnup and @gerad would never use your information in a malicious way. They’ve been crazy enough to organize this event for the 3rd year now despite the operational headaches of putting together such a massive event.

Physics in Javascript Using Box2D

This is part 2 of an ongoing series that details our team’s journey to creating disasteroids.com for NodeKnockout 2012, a 48 hour coding competition that showcases projects built on node.js. You can find part one here.

THE GOAL:

When we set out to create Disasteroids, we knew that how we model gravitation would be an integral part of what defines the experience when playing the game. We envisioned insane, well calculated trick shots that looped around the gravitational pull of multiple asteroids. We sat down and started to discuss the specifics of how mass, gravity, and velocity would all be handled and we were quickly faced with the decision of rolling our own simple physics engine or investing the time to familiarize ourselves with an existing open source alternative.

It was a harder call than expected considering that the competition was only a 1-2 days away and none of the members of the team had ever used a physics engine let alone heard of one that’s written in Javascript. Thankfully, some quick Google searches brought up Box2D which had a Javascript port called box2dweb. After being blown away by a few tech demos that made you ask yourself, “This is being done in the browser using Javascript?” we decided to bet on Box2D and go full force. We spent what time we could stepping through Seth Ladd’s excellent intro to using Box2D in Javascript before the final hours before the competition.

BOX2D FEATURES:

Box2D allows you to setup a “world” of arbitrary size and populate it with any number of objects that they individually refer to as a “body.” Each body has a set of properties such as “restitution” (bounciness), friction, and density. Primed with this knowledge, we created a world and threw up circular bodies as asteroids and rectangles as player and missiles. This was easy enough, but we quickly realized that Box2D is a physics engine and is only meant to simulate a virtual world. It was entirely up to us to translate the data that Box2D provided into a visual scene. How we achieved this will be detailed in a later post, but for now, we will talk about Box2D’s awesome debug draw feature.

box2dweb (the Javascript port of Box2D) includes a debug draw class that takes in a canvas reference. This class then draws a simple representation of the world which shows every body’s position, orientation, and status.

 http://code.google.com/p/box2dweb/ has a great in browser example of what this looks like. The Box2D documentation made it very clear that this is to be used to debug purposes only, but it proved to be invaluable in quickly testing how our code made bodies interact without having to immediately worry about how to translate Box2D’s simulation into sprites and images on canvas. This allowed for us to independently start work on modeling Disasteroid’s physics even before any of the design assets were finalized and ready for us to use.

RADIAL GRAVITY:

“Radial Gravity,” is the term that we learned was used to refer to gravitational simulations that involved planetary bodies in space. It turned out that simulating this kind of environment is not too uncommon and we were able to pull some blog posts and tutorials detailing just how to go about implementing it using Box2D. This was an amazing find for us considering we only had 48 hours. Here’s a post by Emanuele Feronato that saved us tons of time and effort. The tutorial was written in ActionScript 3, but he provided an extensive line by line breakdown of the code, which made porting most of the core concepts effortless.

Box2D doesn’t have a built in way of applying gravity onto an arbitrary object in the simulated world. As a result, we had to custom build this feature by applying a force to all objects towards the asteroids on every tick of the physics simulation. The basic algorithm for applying radial gravity worked as follows:

1. Get the distance of the player/missile to all nearby asteroids.

2. Apply a force on the player/missile towards the asteroids.

3. Make sure the force is proportional to the radius of the asteroid

4. Make sure the force applied is lowered as the object’s distance from the asteroid increases.

That’s it! It sounds complicated, but the implementation was extremely simple. 

CHALLENGES:

The main challenge using Box2D for Disasteroids was the fact that it was a multiplayer game where the node.js server would serve as the authoritative source of what was going on in the world. This would mean that the Box2D simulation needed to be run on the node.js server. We threw out the idea of running predictive simulations on the client side solely based on the fact that we only had 48 hours. This posed a few challenges:

Challenge #1: The physics simulation on node.js had to run FAST in order to properly relay the world state to all connected players.

To circumvent this issue, we had to lower the FPS of the game to 30 from 60 and also optimized/rewrote the main loop that processed the Box2D world simulation at least 4 times throughout the span of the 48 hour coding event.

Challenge #2: There was no way for us to use the debug draw class on node.js to get a picture of what was going on. Node.js isn’t a browser and doesn’t have a canvas object that we can easily hook into in realtime.

We knew of projects such as LearnBoost’s node-canvas (https://github.com/LearnBoost/node-canvas), but we didn’t really have to time to look into it and had to come up with quick tests that ensured we were translating the positional data from the node.js server to correct visual representations on the browser. This certainly created some frustrating moments where things were off center, oriented in the wrong direction, or not showing up entirely, but we somehow managed to get through all the issues in the end. There were instances, however, where we weren’t able to pinpoint issues quickly because it was unclear if things were showing up incorrectly as a result of a bug in the physics simulation on node.js or the rendering on the browser.

WRAP UP:

In the end, Box2D was an awesome choice that made Disasteroids what it is today. We were only able to scratch the surface of what it has to offer. It has already been rolled into popular HTML5 game engines such as Impact.js and Cocos2D and we hope to bring it some more exposure as it definitely helped us save the time and trouble of implementing a physics engine.

Part 3: Making It Feel Real: Math And Fabric.js

VOTE!

If you enjoyed disasteroids.com or this post, please consider throwing us a vote on our team’s page. It requires Facebook authentication to ensure that there isn’t rampant cheating, but the awesome NodeKnockout organizers @visnup and @gerad would never use your information in a malicious way. They’ve been crazy enough to organize this event for the 3rd year now despite the operational headaches of putting together such a massive event.

Disasteroids: How we built a real time gravity-based space shooter in 48 hours for the 2012 Node.js Knockout — Part 1 of 4: Countdown and Kickoff

T-Minus 48 Hours

On Wednesday afternoon we made a trip to the airport.

Since the last Node Knockout some 15 months ago, 3/4 of the team had moved from Santa Monica to Boulder, CO to get involved with TechStars, but our fourth man @bundy_kim was flying in from LA for a couple days of brainstorming and wandering around town before the start of the competition.

We are all avid gamers, but had never built a game of our own before, and decided that the NKO provided a great opportunity. We considered a handful of different ideas, but settled on a modern adaptation of the classic artillery games. In short order we knew what we had to add: space, missiles, robots, and real time multiplayer.

T-Minus 24 Hours

If we learned anything from last year’s NKO, it’s that a little planning goes a long way. We spent the afternoon at the whiteboard, mapping out the game mechanics and prioritizing features: gravity, collisions, and shooting had to happen for us to have a game. Things like weapon variety, a scoreboard, and strategic game types would be cool, but only if we got done with the core features in time.

More than once an office mate would walk by and stop to see what we were staring at so intently, only to break into a broad grin as they realized what we were up to.

T-Minus 5 Hours

On our way back to the office after lunch, we ran into a couple Red Bull girls handing out free samples. This was a good omen.

T-Minus 4 Hours

We headed to Alfalfa’s, the local grocery store, for snacks and supplies. With the exception of some not-so-healthy energy drinks, we actually picked up some pretty solid food. Despite the conventional wisdom, you probably don’t want to be running on pizza for two straight days of hacking. We opted for corn chips, salsa, protein bars, beef jerky, trail mix, and lots of green tea-based beverages. All in all it seemed to work fine. We each got only 5-6 hours of sleep over the weekend, and didn’t have any major crashes or bouts of exhaustion.

T-Minus 3 Hours

In the final hours before kickoff, we held one more meeting to decide on architecture, map out specific tasks, determine which libraries we would need, and get a rough idea of who would be responsible for each item. We’re very fortunate to have a team with lots of skill overlap, so we knew it would be useful to set rough boundaries so we didn’t step on each others’ toes.

T-Minus Zero

git clone was run and we were off to the races.

I (@travhimelf) fired up Illustrator while the other guys (@bundy_kim, @joshonthweb, and @mtoymil) started installing the important modules and libraries we would need. I went to File > New Document, and Illustrator promptly decided to give me the pinwheel of doom. I briefly considered downloading Inkscape but decided it was best to not mess around, and set about installing a fresh copy of CS6.

While I waited for a fresh install, I Googled around for Mobile Frame Zero models (go ahead and browse for 20min, I’ll wait…), which I thought would make good reference material for our mech designs.

There’s plenty of mech art on the web, but most of it is uber-detailed — lego models made better references because they’re built with simple polygons. We had been toying with the idea of 16-bit-style art, but ultimately headed in a Geometry Wars direction after looking at this awesome style breakdown on Quora and deciding that we’d better keep it simple. (After all, none of us had ever designed game art before.)

For the animations I looked at sprite sheets from NES classics like MegaMan. The designers of those games achieved some pretty smooth looking sequences using only a handful of frames. We didn’t get a chance to implement walking around the surface of asteroids, but it was cool to get some rudimentary animation experience under my belt.

With the artwork well underway I decided to check in with Bundy, who was tackling the first major feature, and the key to the game design: gravity.

Check back tomorrow for Part 2, where Bundy walks through our implementation of radial gravity and the technologies behind it.

If you enjoyed disasteroids.com or this post, please consider throwing us a vote on our team’s page. It requires Facebook authentication to ensure that there isn’t rampant cheating, but the awesome NodeKnockout organizers @visnup and @gerad would never use your information in a malicious way. They’ve been crazy enough to organize this event for the 3rd year now despite the operational headaches of putting together such a massive event.

The story of eightbitbeats.com: How we built a social 8bit music sequencer in 48 hours

Node Knockout 2011, held between August 27 and 29, was a programming competition in which teams of developers were charged with designing, building, and launching a web app in a single weekend. The only basic requirements were that 1) each entry must use node.js, a javascript-based web server, and 2) that all designing, coding, tweaking, and deploying be done in the 48 hour period allowed for the contest.

Our team, made up of four developers from Mahalo.com, had not competed in last year’s Node Knockout, but we were excited and impressed by the entries we saw, and we decided we had to enter this time around. We tossed around a few concepts and eventually settled on the idea of eightbitbeats.com, a multi-user music sequencer built around an 8bit theme. At 5pm pacific time August 27, we got cracking.

But before we get into the nitty gritty, check out the finished product:

We were fortunate enough to have a team with very strong backgrounds in design, UI, and product, which was great when it came time to bounce ideas around. Whenever one of us got stuck or needed input, we would call a huddle at the whiteboard, quickly churn through all the options, and make a decision, often within 20 minutes — sometimes much faster. The ability to do this came partly from having worked together in this way on a daily basis, but beyond that, we had a common understanding of user interface. We didn’t need to waste any time defending one idea or lobbying for another. We knew from experience which options would work, which wouldn’t, and which ones needed to be explored further.

In terms of visual design, the biggest challenge for eightbitbeats was making efficient use of space. Although available screen real estate gets larger every year, the standard width for a web page still tends to be around 960px, and our first mockups stuck to that standard. However, once we settled on a reasonable size for the sequence buttons (10x10) — and started laying out additional elements like user avatars, instrument selection, and labels for each instrument’s notes — we realized we would need increase the width, and eventually settled at 1300px. We made a judgement call that, at least for the purposes of the Node Knockout, we could probably assume our audience would be using fairly new hardware with wide-format, high-res displays. (In the days since the code freeze, we’ve had lots of feedback but no comments regarding page width, so it seems we guessed right.)

Next up, we needed to consider the sequencer matrix. We kept image assets to a minimum in favor of CSS3 to lighten the load, but even so we still had to contend with potentially hundreds of divs on screen at any time. Add to that the fact that each button needed several states including disabled, enabled, active, played, downbeat, measure downbeat, some of which would require nested divs, and we were quickly talking about thousands of elements. Rather than go down that road, we opted to use :before and :after pseudo classes to insert containers dynamically. (See Nicolas Gallagher’s excellent post for details on this method). Using this approach simplified our markup considerably and allowed us, with the help of less.css, to handle all the assorted states in a legible stylesheet (less than 400 lines total).

    .step {
        float: left;
        margin-right: 3px;

        &.active .note {
            border-color: rgba(255,255,255,.1);
            box-shadow: 0 0 3px rgba(255,255,255,.1);
        }
        &.active .note.on:after {
            background: rgba(253,154,0,1.0) !important;
        }
    }

    Socket

    App model
        User model

        Instruments collection
            Instrument model

        Player model
            MegaMan collection
                MegaMan models

            Tracks Collection
                Track models
                    Steps Collection
                        Step models
                            notes: [0,1,0,0,1,0,0,0,0,0]    
        ChatLog model
            Messages collection
                Message models

    // Pseudo javascript for demonstration
    Player.play = (function() {
        // Set up timing variables
            var skipTicks = 60000 / 4, // 60000ms per min over 4ticks per beat
            nextTick = (new Date).getTime();

            return function() {
                while ((new Date).getTime() > nextTick) {
                    // While it's time to tick, tick until it isn't time anymore.

                    // Do the work
                    $.each(Player.notes, function(note) {
                        note.play();    
                    });

                    // Increments nextTick by the correct ms per tick
                    nextTick += skipTicks / Player.bpm; 
                }
            };
    })()

    // Start the loop
    Player.loopInterval = setInterval(Player.play, 0);

    soundManager = (function () {
        // Make-shift HashSets
        var toPlay = {};  // Sounds to play for the current step.
        var cache = {};  // Sounds to cache for the next step.
        return {
            // Add a file if it’s not been added.
            addFile: function(file) {
                if (!cache.file) {
                    cache[file] = file;
                    // This value should probably just be set to true.
                }
            },

            // Play the collected sounds.   
            play: function() {
                // Play sounds if we have them
                if (!!_.size(toPlay)) {
                    _.each(toPlay, function(name) {
                        playSound(name);
                    });
                }

                // Update the sets.
                toPlay = $.extend({}, cache);
                cache = {};
            }
        };
    })();