On the ground at CppCon 2014

I’ve just returned from the week-long CppCon 2014 in Bellevue, Washington. Here’s what I experienced.

I’ve absorbed a great deal from a variety of C++ developer conferences – CppNow, Going Native, C++ And Beyond – but always virtually, via video and webcast. This was an opportunity to jump into the thick of things and participate in person. With community heavyweights like Herb Sutter and Scott Meyers in attendance I knew the content would be stimulating and informative. (Honestly, the speaker list featured nearly every name in the “C++ royalty” that you could imagine. I smiled to myself seeing Bjarne Stroustrup standing in the registration line like he was just another attendee.) So when the conference’s early-bird admission opened in March, I eagerly sent in my hard-earned dollars and blocked off the week of September eighth on my calendar.

Continue reading

Unit test your private methods for great justice

The continuing dissent and confusion about unit testing of private class methods surprises me.

The access specifier is much like your choice of software license: it exists to limit consumers’ actions, not to limit yours. A method’s access specifier is completely irrelevant to testing, and only describes what you want the consumer to use; any code that takes inputs and produces outputs, private or not, should be tested.

The opponents of private-method testing tend to argue in quasi-religious terms: that private methods are mere hidden implementation details; that users of the class will only care about the public API; that testing of private methods breaks encapsulation. A typical unhelpful “solution”: private methods should be put into a different class and made public there.

To argue against granular testing of private methods is to mean well while being thoroughly unhelpful. The purpose of testing is more than just to guarantee the viability of your public interface – it is also to examine the inner machinery and support routines of your class to ensure that they themselves function correctly for a spectrum of inputs and edge cases. The private implementation will contain non-trivial complexities that are more readily and precisely tested directly than via the public API.
Continue reading

Steering Behaviors for Ruby game dev now on Github, Rubygems

I just released my Steering Behaviors package to Github, and an accompanying Gem to Rubygems.

If you’re building a game, you’ll want your game agents and characters to exhibit realistic motion. A standard way of doing this is with ‘steering behaviors’.

The seminal paper by Craig Reynolds established a core set of steering behaviors that could be utilized for a variety of common movement tasks. These include such behaviors as predictive pursuit, fleeing, arrival, and wandering. This Ruby library can accomplish many/most of those tasks for your Ruby / JRuby game.

The basic behaviors can be layered for more complicated and advanced behaviors, such as flocking and crowd movement.

Embellishments and expansions are planned, but this is working software you can use to drive your own game’s characters. (I’m using it in my own game programming.) The Github repo includes working graphical examples, and you can install the Gem for easier and more direct use in your own game.

Pull requests are enthusiastically encouraged.


On Github: my Fuzzy Associative Memory (FAM) package

I’ve just released to Github my working fuzzy logic module, Fuzzy Associative Memory.

A Fuzzy Associative Memory (FAM for short) is a Fuzzy Logic tool for decision making. It uses Fuzzy Sets to establish a set of rules that are linguistic in nature; examples might include:

  • “If the room is a bit warm, turn the fan up a little bit”
  • “If the orc’s hit points are a little low, retreat from the enemy”
  • “If the ship is off course by a little bit, correct just a little to the right”
  • “If the bird is much slower than the flock, speed it up a lot”

As you can see, the rules are deliberately vague and use qualifiers like “a little” and “a lot”. This is the nature of fuzzy sets; they capture such human fuzziness in a way that extracts highly natural behavior from the fuzzy rules.

It has a wide range of applications:

  • Industrial control, such as governing a fan to keep a room at the “just right” temperature
  • Game AI, such as giving human-like behavior capabilities to NPCs
  • Prediction systems


This is working, functional software. It currently supports:

  • Triangular fuzzy sets for input/output
  • Larsen Implication (scaling)
  • Atomic antecedent propositions (if A then Z)

To do:

  • Trapezoidal (and other shapes) for fuzzy sets
  • Hedges (‘very’ and ‘fairly’)
  • Mamdani Implication (clipping)
  • Composite antecedent propositions (if A or B, then Z)
  • Additional examples


The bin directory contains the following examples:

  • hvac_system_example illustrates how a FAM could govern an HVAC fan unit to maintain a constant, comfortable temperature

Get it here!

Entity-Component game programming using JRuby and libGDX – part 8


Our Lunar Lander game is somewhat playable by this point but it still lacks some key features. After all, it would be nice if we could detect collisions and determine if the lander has safely landed on the pad. Let’s see how our flexible Entity-Component system permits us to expand our game with minimal fuss.

Collision Detection

First, a frank disclaimer: the following collision detection algorithm is entirely inefficient. It’s kept simple for our basic teaching purposes here but is probably undesirable in a game of any scale. But that’s OK: E-C will permit you to swap in a much more advanced collision detection system when you’re ready. 🙂

Read the rest of this story…

Entity-Component game programming using JRuby and libGDX – part 7


Entity-Component systems, we’ve learned, are easy to implement and maintain; the elegance is basically “baked in” due to the way components and entities are married in the Entity Manager.

One particularly tidy aspect of an entity-component system is how well it lends itself to data persistence, or in practical terms: saving game state. Let’s take a look.

Where Is State?

In a conventional object oriented design, state is scattered all over the place, embedded in your far-flung object instances. But in E-C everything is neatly gathered together under one roof: the Entity Manager. This manager knows every entity “instance” along with every entity’s components, which are where the entity state data are stored.

Therefore, persist the entity manager to disk and you’ve saved the game in its entirety. Load from disk to memory and you’ve just loaded the game. It really is that easy.

Read the rest of this story…

Entity-Component game programming using JRuby and libGDX – part 6


Now that we have laid the entity-component foundation and introduced some necessary libGDX concepts, we can finally get around to putting together a little game. Let’s make a “Lunar Lander” type game to illustrate all the concepts we’ve learned so far.

Remember that the source code for this Entity-Component Framework and the game we’re writing is all available at Github. The Github version is, of course, the “final version” that includes features I might not have addressed so far in the blog series, but if you’re eager to jump ahead…

Entities and Components

For this exercise let’s begin by defining our entities and some of their relevant components.

What are we going to need for this game?

  • The lunar lander module
  • A platform for it to try to land on
  • Ground to collide with

That seems like a fair assessment of our initial entity needs. Now, moving on to components. What are some of the aspects / behaviors / features that we should provide to our entities?

Read the rest of this story…

Entity-Component game programming using JRuby and libGDX – part 5


In previous installments we learned about Entity-Component theory, and we are almost ready to employ this in a real game. Before we do, however, we need to cover some basic game engine concepts.

The Java world is a fertile place for gaming, and there are numerous game engines available. JOGL and LWJGL are low-level frameworks that ease and abstract certain game-construction duties, whereas high-level frameworks like libGDX and Slick2D provide you with all the tools you need to easily author your game — often for multiple platforms at the same time. Both of those are fine choices, but for this series we’ll leverage libGDX. It has as robust community, excellent documentation, and can be used to target the Windows, Android, Mac and Linux platforms.

This post will not attempt to be a tutorial for installing libGDX nor a configuration guide for its many powerful features. Rather, we’ll walk through basic libGDX usage to get a high-level overview of how it works — often a helpful starting point for a newcomer to the technology. The canonical source for libGDX is its official wiki, with supplemental information found at the libGDX-users wiki.

Note that here we are now embracing one of the key features of JRuby: leveraging Java libraries. libGDX is, after all, a Java framework. But why write your game code in ugly, verbose, old-fashioned Java when you can use your favorite language to do it? The code will certainly be tidier, more readable, and a lot more enjoyable to write and maintain.

Now is an appropriate time to point you to the official Github repository for this blog series’ source code. This repository not only includes all the source code that has been (and will be) discussed in this blog series, but also includes a simplistic but runnable “lunar lander” type game to help cement the concepts with real, working code. I believe you’ll find it very helpful as a learning tool.
Read the rest of this story…

Entity-Component game programming using JRuby and libGDX – part 4


In previous parts we established nomenclature; entites and entity management; and the components that supply entities their data. Now we turn our attention to “systems.” Systems are where we store all logic and algorithms. We have many systems, each responsible for a particular task, and these systems collect data from one or more components in order to act on a given entity.

The System

Here’s a very simple System base class from which all systems will derive:

class System
  def process_one_game_tick
    raise RuntimeError, "systems must override process_one_game_tick()"

Let’s agree that our game runs at a certain number of frames-per-second, and for simplicity’s sake we’ll also agree to update our logic every frame. We don’t know at compile-time what the FPS will be; could be 20 FPS, could be 60 FPS. Regardless, we’ll say that every frame-to-frame transition is a “game tick”. That’s what we’re referring to with “process_one_game_tick”, which is the method every system must implement.

Read the rest of this story…

Entity-Component game programming using JRuby and libGDX – part 3


In part 1 and part 2 we introduced nomenclature and explored the construction of Entities using the EntityManager. Now it’s time to breathe life into your entities with components (for data) and systems (to act upon the data). In this post we’ll discuss components and in the subsequent post, systems.

The Component

Recall that we never store any data or features of any kind inside an entity. (Actually the point is moot: we cannot store anything in an entity since entities aren’t even object instances, they are merely numeric IDs managed in the EntityManager.) This is where we truly depart from OO as a design paradigm. Attributes, aspects, data, behaviors are no longer embedded in the objects but are “bolted on” by attaching component instances to the entities.

Here’s a very basic start to a Component base class from which all components will derive:

class Component
  attr_reader :id

  def initialize
    @id = java.util.UUID.randomUUID().to_s

  def to_s
    "Component {#{id}: #{self.class.name}}"

Every component gets a unique ID for tracking and logging purposes; it is a very basic class.

Read the rest of this story…