Monthly Archives: April 2017

A Console Experience on the Web

Every new generation of consoles has brought with it services such as marketplaces, achievements and gamer profiles, which have made it easier for players to instantly connect with friends, as well as being able to discover, purchase and find new ways to enjoy games.

In this article I will be discussing 3 main features of traditional gaming systems, and compare them with the offerings of the open web, and discussing how you can leverage these offerings to bring in new audiences for your games.

Controllers

What kind of console game doesn’t support controllers? Analog input can make most games, from platformers to racers, easier and undoubtedly more fun to play. Games like Super Meat Boy or FIFA, while supporting keyboards, are designed to be played with controllers. The social, couch-based gaming of traditional consoles required a method of input that was simple, unobtrusive and ergonomic.

What does the open web need?

An interface that allows players (and their friends) to simply plug in any existing controller and be able to start a game without downloading any special drivers, browsers, or plugins. Unfortunately, there are a few problems with that ideal situation:

  • Most controllers require driver installations on almost every platform out there (The exception is XBOX Controller for Windows)
  • Some controllers flat-out refuse to work on certain platforms
  • Input values vary by controller
  • Not all browsers support/are working on Game Controller APIs

What’s currently available?

Clearly the folks at Mozilla and Google see the need for HTML5 to catch up to consoles, as their rapid work on Gamepad-specific APIs shows. Mozilla Firefox has a special Gamepad build. All Chrome builds require a change in chrome://flags before you can read controller input.

In terms of controller support, here’s what you can use:

  • Windows
    • XBOX360 Controller for Windows (works best)
    • PLAYSTATION DualShock3 controller – can trick Windows into reading it as XBOX360 controller using MotionInJoy
    • Logitech Gamepads such as the F310, F510 and F710
    • As a rule of thumb: any controller which emulates the XBOX360 controller should work.
  • Linux
    • Controllers in the Windows list above should all work.
    • Due to the variety of distributions and kernel versions out there, it’s hard to provide a concrete list of supported controllers, but anything using the USB HID interface should work.
  • Mac
    • PLAYSTATION DualShock3 controller is supported out-of-the-box
    • XBOX360 Controller for Windows, using special software from Colin Munro

What tools do I use?

There are a few libraries out there that ease the pain of having to customize button assignments and API calls across Firefox and Chrome.

  • Gamepad.js is clean, works well, and is super simple to work with
  • Input.js is another one that tries to abstract away the Gamepad API. It’s built by a Mozilla Engineer and is being developed as part of their Paladin gaming initiative.
  • Raw API calls. It isn’t too hard, but you’ll have to worry about button mapping across a variety of controllers.

Canvas Utility Belt

The past year has seen wonderful growth in the popularity of 2D Canvas; it’s been great to see so many people getting comfortable with the 2D context. Canvas is almost synonomous with HTML5 gaming and supported in all modern browsers including Chrome, Firefox, and Internet Explorer 10 and 9.

One thing that many people take for granted is the “bottom to top” canvas drawing order; putting down the background first, then objects in the middle of the scene, and finally drawing the foreground.

It’s true that this is how canvas works by default, and there’s a specific name for it; it’s called the source-over global composite operation (GCO).

What many people don’t know is that you can reverse this order – by setting ctx.globalCompositeOperation = destination-over, you can actually draw the background last, and it will go under what’s already been drawn on your canvas.

There are a total of eleven total GCOs at your disposal. There used to be an even dozen, but the black sheep of the bunch – darker – has unfortunately been abandoned.

In general, you should use source-atop, because it has been the focus of much optimization and is relatively fast. However, there are times when the scene you’re trying to create is difficult or impossible to pull off with source-atop alone.

The GCO modes apply to every pixel that goes onto the canvas. Whether drawn via fillRect, stroke, drawImage, fillText, or anything else – they are all subject to the active GCO. Happily, as the GCO is set on the canvas context, it is subject to the same save/restore (push/pop) behavior as all the other contextual fields (scale, rotation, fill style, global alpha, etc).

This article will explore two of the lesser known GCOs – source-atop and destination-out – and show how they can help you solve some common problems in game graphics programming.

Subtractive Drawing with destination-out

A recent problem I faced was the display of a number of control points on a strategic map. Each point provides a circular “radar” area of effect, and I wanted to depict this area visually so it was obvious to the player which areas were under the effect, and which were not.

The obvious choice to illustrate the radar area border is a simple line – a colored ring around each control point. This is very easy to do with canvas: create a few paths with the .arc() method, and stroke each one.

Blog called Physics in JavaScript

My name is Burak Kanber. I started programming in 1999 and built my first MMORPG in Perl in 2001. Years later I attended the prestigious (and tuition-free) Cooper Union, where I studied automotive and sustainable engineering. I earned my master’s in engineering simulating physics in the powertrain of hybrid cars. I’m presently an entrepreneur and the co-founder/CTO of Tidal Labs, which is proving that you can do awesome things as a bootstrapped startup in NYC. I love teaching (which I do often), and I still love physics. I scratched both of those itches by starting a series on my blog called Physics in JavaScript.

Eventually, Build New Games asked me to write an article on physics for video games. Game development is only a hobby – not my profession – so I did the only sensible thing and started building a legitimate physics engine in native JavaScript as research.

This article will guide you through the essential physics of game engines. This is not an A-Z “how-to” guide. I’ve left out some major optimization and implementation details; a single article can only cover so much. My true goal is to point you in the right direction and teach the concepts that you’ll need to build upon later. The next step is up to you. I hope you’ll use this article as a springboard and go write your own game engine, researching advanced concepts in the process.

I’ve left you a very helpful to-do list at the end of this article, if you’re just here looking for a summary of what you need to learn.

A Vector State of Mind

The first thing I learned when building my physics engine is that you really should embrace vector mathematics (linear algebra). I can already hear you groaning. For some reason, linear algebra always elicits a visceral reaction from people, but please allow me the opportunity to sway you.

Newton’s equations of motion – which dictate basically everything we’re about to do – have a very helpful mathematical quality. You can separate the equations of motion into smaller equations: one each for the x, y, and z axes.

What this means is that when you throw a baseball (in 2D, for argument’s sake) you can solve two separate equations for how it moves vertically and how it moves horizontally. When you throw a baseball, it moves forward at a constant velocity. But it also moves vertically at the same time – and its vertical motion is anything but constant, it’s affected by gravity! Newton’s equations allow you to look at these two aspects separately: “the baseball is moving forward at 90 mph but it’s also moving up and down like so under the influence of gravity”.

For many people, that’s how physics goes. You can just solve each dimension (forward and vertical motion) separately. But I’d encourage you not to do that. Why have three equations when you can have one? Sure, getting comfortable with vector math (again, called linear algebra) has a little bit of a steeper learning curve, but I’ve found that its so much better to work with. It’s worth it.

The account statement from his cloud service provider

Steve cradled his pumpkin spice latte as he walked into the office. It had been three weeks since the launch of his HTML5 multiplayer game, and things were going great. As Steve checked his e-mail, he noticed the account statement from his cloud service provider.

“Let’s see here,” Steve muttered to himself. “Virtual server… 100,000 total hours.” Steve knew this was roughly correct, given the statistics they had been gathering. Thinking about the success of the launch, Steve could barely contain his smile. Skimming further down in the statement, Steve froze. All the way at the bottom, nestled between the line for tax and the heading “Bandwidth” was a number that made Steve’s stomach sink as fast as the latte dramatically falling from his hand.

HTML5 games are growing in a strong way. Once Internet Explorer 10 is released, WebSockets will beavailable in all modern desktop browsers. This technology enables serious realtime communications—the keystone to any non-trivial multiplayer action game. But like a snake in tall grass, bandwidth costs can seemingly come from nowhere. In this article, I want to discuss the oft overlooked cost of network bandwidth and techniques for minimizing it.

The “Hidden” Costs of Network Bandwidth

socket.io is a WebSockets-enabled networking module for node.js I commonly see recommended for its ease of use, robust fallback support, and integrated publish-subscribe pattern. Here is a snippet of server code that demonstrates this.

In just a few short lines, you have a WebSockets implementation that will fallback gracefully into a number of transports at runtime, on a per-client basis. To see the publish-subscribe pattern in action, let’s look at a sample of client code.

The event system used here is familiar to most people, as it is actually EventEmitter found in node.js. All these things are great, so what’s the issue here and what can this small example reveal about why Steve’s bandwidth bill is so high?

JSON: Strengths and Weaknesses

JSON is a way of representing structured data that has enjoyed native implementations of encoding and decoding in all modern browsers. For many reasons, JSON has picked up acceptance on the web for data serialization. If we examine socket.io source, we see that our calls to emit eventually serialize to JSON. Then, supposing we inspect the WebSocket frames, we might see the following.

Physics Engines Comparison

In this article we will take a look at three popular Javascript physics libraries and one that is currently in development: box2dweb, Ammo.js, JigLibJS, and Cannon.js. For each one, a quick introduction will be given and then the library will be rated based on ease of use, performance, and feature set.

Though it is possible to run any of these libraries without a visual representation, that isn’t much fun, so we will set up a small environment to see the results as the simulation runs. I’ll use Three.js and its CanvasRenderer for this due to its popularity and how simple it is to use. Besides showing how the objects are interacting, this will also demonstrate how to extract scene information from each library. The scene will consist of two ramps leading down to a floor; balls will drop down onto the ramps from random locations above the scene, roll down the ramps, and land onto the floor.

Setup

Our base scene that will be used in each example has two ramps which lead down to the ground. Balls will be dropped from random points above the ramps, rolling down to and then off of the ground plane. This simple scene will highlight the similarities and differences between the four libraries.

box2dweb is a port of the C++ box2d project and is unique on our list of libraries in that it is designed to only simulate two-dimensional scenes. All of its classes are namespaced which can make the code a little hard to read, so it is recommended that you create your own local variables for any objects you commonly use. Don’t be fooled into thinking box2dweb is a weak library because it only performs 2D simulations; within its simple API is a ton of power. box2dweb has a full constraint system (which it calls joints), continuous collision detection for more accurate fast-moving bodies, and lots of configuration options both for the whole scene and for individual objects.

Collision detection with box2dweb is easy to do by using the b2ContactListener object. You can have separate event handlers for each of the four collision states: BeginContactEndContactPreSolve, and PostSolve. You can also detect collisions by iterating over the world’s contact list after each step.