Monthly Archives: August 2012

Code Is a Liability: Emotional Detachment From Code

Sometimes a developer or organization will consider their code to be valuable. Is code valuable? I don’t think so. Code is a reusable and disposable resource. It’s also a liability.

A liability?

Yes because when you write code and it solves a problem, it is useful. But once the problem changes, it’s just bytes. And believe me, the problem will change. Then you’ve got more bytes to maintain. Code then is a liability and the longer it sticks around the more drag you’re creating on the future.

What if you spent a non insignificant amount of time writing code only to discover the problem you were solving has changed? Well hopefully if you’re leveraging an agile methodology that time period will be small, but if it’s not you’ve got to be able to throw away your work entirely. It’s easy to get attached to code that you’ve written and want to try and take it along with you like a boat anchor but you must be able to dump your code without a second thought when it’s no longer useful.

Recognize when code is adding value and when it needs to be taken out back of the shed. It’s not your code. It’s the code. Make sure it isn’t a liability.

Steve Jobs: The Lost Interview, Now Available for Pre-order

Remember when I posted a quote from Steve Jobs from his 1995 interview with Robert X. Cringely? It’s been available for rental from iTunes for a while now, but now it’s available for pre-order from Amazon.com. Also included is a 65 minute interview with Andy Hertzfeld, the original systems programmer for the Mac. I strongly encourage you to pick up a copy; It’s a powerful interview with Steve Jobs.

Steve Jobs: The Lost Interview

Game Development: The Engine (Game Loop)

All computer games, when you boil them down to their simplest form, consist of a notion called the ‘game loop’. When you consider what a game really is you realize that it’s just a looping construct thats continuously receiving inputs and drawing outputs. The simplest loop looks like this:

  1. Calculate time elapsed since last loop.
  2. Accept inputs from the user(s).
  3. Decide what to do based upon those inputs, including updating entity positions.
  4. Draw everything to the screen.
  5. Repeat the loop.

I’ve been working on a game in my spare time (ok, so I’m ALWAYS working on a game in my spare time, shutup, let’s get back on topic). I spent a fair amount of time simplifying my game loop so that any developer could come along and immediately understand what it’s doing. As it turns out, this process of simplification is a great way to decouple things into a better design. Here’s what I’ve ended up with so far:

private boolean running;
private long lastLoopTimestamp;
private final Renderer renderer;
private final RateLimiter rateLimiter;

public Engine(Renderer renderer, RateLimiter rateLimiter) {
	this.renderer = renderer;
	this.rateLimiter = rateLimiter;
}

public void run() {
	
	this.running = true;

	while(running) {
		
		long elapsedTimeMillis = 
                  this.calculateLoopElapsedTime();

		this.processInput();
		this.think(elapsedTimeMillis);
		this.drawWorld();

		this.rateLimiter.blockAsNeeded(
                  System.currentTimeMillis());
	}
	
}

private long calculateLoopElapsedTime() {
	
	long now = System.currentTimeMillis();
	long elapsed = now - this.lastLoopTimestamp;
	this.lastLoopTimestamp = now;
	
	return elapsed;

}

The basic idea is that the Engine class here knows nothing about processing input, thinking about the logic, or rendering the world to the screen. It does however orchestrate all of those things (omitted the contents of the orchestration methods for brevity). The only thing the Engine cares about is knowing how to run, and how fast.

I think this is a pretty clean design. I’ll post more later about how I decoupled what’s being rendered to (ultimately a Canvas).