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

Introduction

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

Introduction

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

Introduction

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()"
  end
end

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

Introduction

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
  end

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

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

Read the rest of this story…

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

Introduction

In Part 1 we explored EC nomenclature to set the stage for this part: learning how to work with entities, components and systems using an Entity Manager. (And if you are finding this post via Google or another entry, you can find the index to the full series in Part 1.)

As you’ll recall, your game-world “things” (Entities) are not traditional OO classes. EC Entities are skinny beings that exist merely to have a unique ID. Only after the Components are “attached” to an entity does it attain any personality.

Read the rest of this story…

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

Introduction

In this series of posts I’ll show you how to use JRuby and Entity-Component architecture to build a working game. Entity-Component Systems are a fairly new alternative programming methodology. They are prominent in the game-programming community and solve many of the problems that OOP cannot solve.

If you’re a Rails programmer you’re already familiar with the mantra “composition over inheritance.” Entity-Component Systems are probably the highest form of composition over inheritance that you will encounter.

“Pure” EC is what I’ll work with in this blog series. There are also hybrid systems and alternative methodologies. EC is a young enough architecture that even in the “pure” space there are still disagreements about certain implementation details. I’ll give you the solid foundation; the mechanism I’ll discuss in these posts will be adaptable by you to embrace these subtle shifts as you see fit.

Series Index

Read the rest of this story…

Introducing AlwaysNRST for iPad and iPhone

I’m pleased to report that Apple has approved my new aviation app, AlwaysNRST.

AlwaysNRST constantly displays airports near you, with Direct-To info to the nearest color-coded by glide-ability in the event of an engine-out. I think you’ll enjoy it. I put it through bona fide flight testing and it works as advertised, and its database of 34,000+ airports includes facilities worldwide.

Check it out now in the App Store!

Do you always know your nearest airport? You should! AlwaysNRST can help improve your situational awareness. Designed as a training aid for students and instructors alike, this utility will help keep your “ADM” (aeronautical decision making) skills sharp by continuously telling you the location of the nearest airport to yourself.

AlwaysNRST uses your device’s GPS to provide a realtime display of fixed-wing airports in your vicinity, along with continuously-updated Direct-To routing to the closest one. Input your aircraft’s glide ratio and AlwaysNRST will color-code the course line to indicate your probability of reaching that field in the event of an engine failure.

AlwaysNRST requires no network connection to operate – it has thousands of airports in its database, and can perform its functionality offline.

Features:
+ Nearly 34,000 WORLDWIDE fixed-wing airports included in the app
+ Realtime calculation of Direct-To routing to closest airport to you
+ Native iPhone AND iPad interfaces (universal app)
+ Color-coded course line indicates probability of reaching airport without power
+ “North Up” and “Heading Up” modes
+ No network required for airport display and direct-to calculation
+ Compatible with external GPS receivers like the Dual XGPS150
+ iOS 6 and iPhone 5 (large-display) compatible