Behavior is the abstraction that we use to differentiate among objects, and it should be the only criterion that we use to establish our taxonomy. Using any other criteria will make our taxonomy more complicated at a minimum and erroneous at worst. In the real world, errors such as racism and sexism can be seen as characteristic-based rather than behavioral-based taxonomies — with the obvious negative consequences.

That was excerpted from a book called Object Thinking. Its author speaks of software development, but here he quickly mentions real life manifestations that a faulty world view bring about.

Consider two scenarios.

Scenario 1: An individual knocks on your door. You open the door. The individual before you demands 50% of your money. The individual is wearing a ski mask and brandishing a gun.

Scenario 2: An individual knocks on your door. You open the door. The individual before you demands 50% of your money. The individual is wearing a badge that says “IRS” and is brandishing a legal document that authorizes him to collect this money.

An individual trained to view the world in terms of characteristics would likely resist in scenario 1, and is unlikely to resist in scenario 2.

An individual trained to view the world in terms of behaviors would likely resist in both scenarios.

So, why are there so few true object-oriented programmers? For the same reasons there are so few true libertarians.

I won’t argue beyond what I have already set forth in this post’s title. Instead I will direct my readers to Google.

I will say this, however, because it’s for years been on my mind and I think the only time I’ve expressed it is in passing to individuals who were already in agreement:

Object-oriented programming is not a technology. It’s not a syntax. It’s a mode of thought. It sucks that West’s book is so terse, but it’s a damn good read. That said, Object Thinking is a fucking masterpiece.

Sorry this post is so weak; I’m tired as hell. Night world.

Oh, wait, one more thing. I see a lot of web developers placing too much emphasis on the database. Stop it. The database is an implementation detail. Let your ORM handle that for you; that’s why it’s there. You, being the intelligent programmer you are, should be focusing on your problem domain.

Databases are old-hat. They’re tired. They’re a solved problem. They are boring.


Rails::Initializer.run do |config|
...
config.action_mailer.delivery_method = :sendmail # add this line
end


Only tested in Rails 2.3.5 on OS X (10.6) (I don’t imagine this working by default on Windows), but I imagine it’ll work for any 2.x app. I dunno about Rails 3.x or 1.x. If you have more information, drop me a line in the comments.

The general idea is to arrange your data in such a way that you can access any point on a two-dimensional plane as a single number and vice versa. For example, given a plane 10 pixels wide by 5 pixels tall, the point (6, 2) will represent 6 + (2 * 10) = 26, or the 26th element of your array. The value stored at this index can be whatever you want; I chose true to mean solid (collision) and false to mean empty (no collision).

To illustrate this, picture your plane as a grid, but instead of using points (x, y pairs) to denote location, you use a single number. Read the grid like you read a book: left-to-right, top-to-bottom. So say you have a 10×5 plane, you’d read it like this…

These numbers map perfectly as indices to an array whose values are true or false (solid or empty). This way, it doesn’t matter how big your grid/plane/level is, the time required to access element 5 is identical to the time it takes to access element 5,000,000.

Here are some benchmarks in Ruby to show how fast array index lookup is. Each array was accessed 1,000 times with a hard-coded number:

                         user     system      total        real
10,000 elements      0.000000   0.000000   0.000000 (  0.000393)
2,500,000 elements   0.000000   0.000000   0.000000 (  0.000307)

As you can see, even if you perform this operation hundreds of times per second (as you might in a video game) the performance remains good.

I did all this in Ruby and Gosu, but I imagine it’ll work for any language. The basic formula I used to generate the indices looks like this:

rows.each do |row|
  row.each do |col|
    pixels[col + (row * map.width)] = true/false
  end
end

The rest of your game can maintain the traditional (x, y) coordinate system. However, when you want to check for collisions, you must convert that point into its numerical representation. This is identical to the index-calculation I showed you earlier:

x + (y * map.width) # x is col and y is row

If you’re generating tiles of a specific size (e.g. 16×16) from a text file (as in Gosu’s Captain Ruby example), you’re going to have to perform some extra manipulation to create the full range of pixels.

Imagine a text file containing 50 rows of text. Each row contains 100 characters. Each character represents a 16×16 tile in your level. If you perform the array index creation based on the number of characters in your file, you will get 50 * 100 = 5000 pixels instead of the actual (16 * 100) * (16 * 50) = 1,280,000 pixels in your level. Quite the difference.