Saturday, July 4, 2009

The Problem with the Mythical Black Box

In programming, we occasionally make use of something known as a "black box." This Mythical Black Box is any library or chunk of code written by someone else that allows us to abstract a problem so we don't have to understand the details of solving it. For example, if we pass the values 3 and 4 to a "calculator black box", which might be a class library written by another developer, we would expect it to return the value 12 for multiplication. We don't care how it works internally, whether it computes 3+3+3+3 or 4+4+4; all we care is that it returns the correct value. A black box diagram for an encryption algorithm might look something like the following.

Password => { Encryption Black Box } => Encrypted Password

Jeff Atwood of Coding Horror has recently expressed seemingly contrasting views on this topic, both touting and refuting the benefits of abstraction. And for good reason, because it can be a good thing or a bad thing depending on whose library you choose. For one thing, you should never introduce code into your project if you aren't 100% certain it will fulfill its promise. Many developers (myself included) prefer the "roll your own" method for most tasks simply because you know you can trust your own code (not that it will be error-free, just that it won't be malicious). But sometimes it makes sense to use a well-tested library from another developer, such as the ever-popular JQuery library for Javascript development. In such cases I suggest ensuring you trust the developer (e.g. they're well known, such as Microsoft, and would be ridiculed if the library failed) or that you have full access to the source code. Many open source projects are reviewed by large numbers of people such that bugs are caught and fixed quickly.

Unfortunately, even if you take my suggestions your black box may someday fail. The whole reason I bring this up is that I faced this exact problem with my SkyCop demo. I developed it using the Common Files Framework presented in Engel's Beginning Direct3D Game Programming, 2nd Edition and provided in a specific version of the Microsoft DirectX SDK. When I ugraded to the most recent build of the SDK, my demo suddently stopped working and I started getting reports of others not being able to run it either. I ran into numerous problems trying to get it to work with the latest DirectX SDK and believe the Common Files Framework was removed altogether in the latest version. Having relied too heavily on that framework, I wasn't sure how to resolve the compilation errors and feared I would have to scrap the project altogether.

Fortunately, in his Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach, Frank Luna fully describes a working game framework instead of glossing over it and providing another black box. I was able to essentially rip out the core of my SkyCop demo, converting it to use the new framework, and am pleased to have an updated demo below that should work on any DirectX 9 (or newer) version, but let me know if you still have any trouble running it.

SkyCop v1.1 Demo Download

Black boxes can be a good thing when they're well-written by a trusted developer, but it's also a good idea to review the code (if possible) and at least have a basic understanding of how it works. In my case, as a learning newbie, I was happy to avoid the initial complexity and that later bit me from behind. One thing to keep in mind, though, is that black boxes come in many shapes and sizes. My black box was a game framework but the concept could also apply to a game engine, a single portion (Renderer, Physics, Sound, etc.) of a game engine, or some other game components I'm not even aware of yet.

Do you know what's going on under the hood of your game framework/engine? What black boxes are you relying on to develop your games?


  1. SkyCop_1_1.exe - Unable to Locate Component
    "The application has failed to start because d3dx9d_41.dll was not found. Re-installing the application may fix this problem."

    Followed by the standard "SkyCop_1_1.exe has stopped working" with the Close Program button. I'm running Vista x64. SkyCop 1.0 works fine.

    Now on the topic of BBs (Black Boxes).
    In Flash development, the Flash compiler and IDE is a huge BB to me. I've got some vague ideas of how it works, but nothing solid.
    Box2D (physics engine) is also another BB.

    I'm comfortable using these BBs because they've got pretty good documentation. Flash has some quirks, but nothing a quick Google won't turn up. Adobe is highly reputable, and the Box2D physics engine has a substantial following with many applications using it (in addition to being open source.)

    Technically though, most languages themselves are a BB. Even the computer circuits themselves can be considered a BB. Programmers have been building on top of each other's Black Boxes for years and years now.

    That's why we've all started to specialize into different areas. You would be incredibly valuable if you could understand every aspect of a computer's programming from the electronics to the operating system, but how many people know all of that?

  2. There is a talk from PyCon where Alex Martelli discusses "Abstractions as Leverage" . Key points include: know your level of abstraction and a few layers below; all abstractions leak "Spolsky's Law" ,know when to use an abstraction and when to break it.

  3. @Quest:
    Thanks for pointing out the SkyCop error; I just noticed this on my new laptop with Vista and will fix it ASAP. As for BBs, I guess I meant to limit scope to code/libraries from another developer you add or link into your codebase. I'm not as concerned with the abstractions of circuitry and compilers; they're a given thanks to the hard work of the smart folks who have already overcome those challenges. Box2D is more along the lines of what I was thinking. In my case I would have to wonder when my game performs in an unintended manner, "Did I introduce this bug or is it a problem with Box2D?" Nine times out of ten it would be my own mistake, but that one time where Box2D has an unexpected quirk could be very frustrating. And not knowing how to fix the problem is worse -- I nearly scrapped SkyCop because I didn't understand how to fix the underlying framework.

    Thanks for the link, I'll definitely check it out!

  4. @Quest:
    I found a solution to your problem with the SkyCop demo -- you need the DirectX 9.0c runtime currently available here. This was the problem on my new PC and I suspect the same for you.