Time-pressured software developers (which is to say, software developers) tend to implement features in the most straightforward way possible. ‘Straightforward’, in this context, means that features are implemented in whatever way requires the least time and mental effort.

Unfortunately, what requires the least time and mental effort for a developer, often demands the greatest time and mental effort for an end-user. Succinctly, ‘easy to program = hard to use.’ The corollary being, ‘hard to program = easy to use.’

The reason for these correlations stems from the following fact: a feature is a mere (usually scant) description of a chunk of functionality, and that functionality can be provided for in so many ways, the odds of the ‘best’ way corresponding to the way that is easiest to code are abysmally small. In fact, the best way to provide that functionality is usually far from the easiest (but also far from the hardest).

Most open source software is written in the spare time of developers. When a feature is implemented, either as part of a request by a user, or as an attempt to duplicate a similar feature in a commercial application, it’s often implemented in the way that’s easiest for the developer. In a lot of cases (but certainly not all), this leads to applications that are difficult to install, difficult to configure, or difficult to use.

With commercial software, there is motivation to provide features that someone is actually willing to pay money for. This provides an incentive for features that are, if not easy to use, at least easier to use than whatever the potential customers are currently using. In a not incompetently run company, this incentive trickles down to the developers, who are then granted (or urged to spend) more time implementing features in a way that might not be easy to code, but is easy to use.

If a developer could spend 10 hours coding something that would save a single user 10 seconds, is the feature worth it? For sake of analysis, we might imagine that a developer’s time is as valuable as a user’s time, in which case, the 10 hours of developer time is well spent as long as there are at least 3600 users. A company selling a product has an incentive to do this analysis and choose the most efficient outcome (implement the feature or not, depending on the size of the user base). An individual developer in an open source project has little incentive to do the analysis, no obvious means of doing the analysis, and only a small motivation to prefer one outcome over another.

What’s the outcome of all this? For me, it means the top applications I use are mostly commercial. Some don’t cost very much; others cost a great deal. But all of them share this distinguishing characteristic: they save me enough time (versus their open source equivalents) that they pay for themselves many times over. They’re more stable, and were designed for ease-of-use instead of ease-of-development.

That said, there are a dozen or more open source applications I use on a regular basis (but not enough to justify purchasing their commercial equivalents). And there are other open source applications that defy the odds and best even commercial offerings in ease-of-use (Firefox comes to mind).

Sure — in utopia, all software would be free and it would be great. But this is the real world, and until someone can figure out how to consistently solve the above problems with open source software, a lot of software will be free, but the greatest software will cost money.

Computer geeks tend to fall into one of two camps regarding free and commercial software: the socialist-leaning, open source devotees, who despise paying for software and pride themselves on running open source software whenever possible; and the capitalist-leaning, closed source devotees, who freely buy software that does what they want it to, and rely on open source only when either (a) it really is the best solution for the problem, or (b) they can’t afford the best solution.

I usually find myself in the closed source camp. Not surprisingly, then, I’ve spent more than a few hours either designing ways to protect commercial software from piracy, or thinking about the problem in the abstract. It is that latter pastime that has inspired me to dream about pirate-proof technology. One result of these dreams is a technology I have dubbed the Pirate-Proof CPU, which is based on principles as old as the field of encryption.

For those without a background in encryption, a few words of introduction are in order. A common form of encryption involves two closely related ‘keys’, which are randomly generated numbers that have a high probability of being unique. The first key is called a public key, and can be used to encode a piece of information (but not decode it). The other key is called a private key, and can be used to decode information that was encoded with its corresponding public key. If you want to securly communicate with someone, you just give them your public key: they use it to encode their messages, and send the encoded messages to you. Since only you have the private key, only you can decode their messages.

The Pirate-Proof CPU is designed with a built-in public key/private key. The CPU provides external access to its public key, but not to its private key. The CPU can only run software that has been encrypted with its public key. It runs this software in a special mode that prevents programs from tampering with or examining unencrypted code (as an added benefit, this behavior would prevent most security breaches).

When a user buys a software program online, the public key of the CPU is transmitted to the software distributor. The distributor then uses the public key to create a specially encrypted form of the program, which is then sent back to the user. Now that particular user is the only user in the world who can run the software program — and the user can’t tamper with the program, because he or she never has access to the program in its unencrypted form.

There you have it. Piracy-proof computing. If it doesn’t exist already, it soon will.

Twenty years ago, it was common practice in the game industry for all of the code for a given game to be written from scratch, by in-house, staff programmers. In the nineties, we started seeing some consolidation: gaming houses began extracting from games engines, which contained the core functionality of the game, and could be reused for other titles of a very similar nature (from that same gaming house).

Jump forward to 2006. The industry has seen a proliferation of powerful, commercial game engines with immense feature sets. And while game engines are still regularly developed in-house, those same engines are also frequently licensed to other game companies, and used by technically skilled fans (modders) to create entirely new games.

What’s happening here, and what does it mean for the future of the professional game programmer?

Before answering that question, I think it’s useful to look at the economics of the situation. My contention is that writing a game from scratch just doesn’t make economic sense, because the functional overlap from one game to another in a similar or identical genre is very large. All first person shooters, for example, need to be able to display large indoor and outdoor environments from the first person perspective, populating those virtual worlds with game characters directed by artificial intelligence. So it makes sense that all first person shooters, even if developed by entirely different companies, are going to end up duplicating a lot of code.

Code duplication inevitably leads to demand for third-party libraries that provide the relevant functionalty. Sometimes that demand is satisfied by the open source community (Apache Software Foundation); other times, it’s satisfied by the commercial sector, or more commonly, by a combination of open source and closed source (mySQL, Oracle RDBM). The impetus for these solutions is that by using them, you can save a lot of time and money, as well as end up with a superior product, built on powerful, robust, proven technology.

Consider two fictional game companies. One writes everything from scratch, and the other one writes its games using time-tested, feature-packed code licensed for a fraction of the amount of money it took to develop that code. All other things being equal, which one do you think will be able to produce better games for less money?

The answer to that question is why the industry as a whole is moving away from proprietary code bases to third-party solutions. But perhaps the more interesting question is why is it happening now—why did it take so long to happen?

I think there are probably a handful of answers to that question:

1. Game programmers typically like writing game code, and often shun the thought of using third-party engines.
2. The game industry as a whole evolves much slower than other industries, due in part because of a higher-than-average burnout rate (which is to be expected in any industry where the workers actually like what they do enough to be exploited doing it).
3. Finally, and most importantly, the rise of the general-purpose game engine is intimately tied with advancing CPU power and the popularization of the graphics accelerator.

Writing a general-purpose game engine for computers of yesteryear would have been mostly an academic exercise, because the features of a general-purpose game engine, such as the ability to display any kind of environment (older games were written specifically for indoor or outdoor environments) and the ability to run arbitrary scripts in real-time that control the game world, require a powerful CPU—one that isn’t tied up by the demands of graphics processing. So general-purpose game engines require the hardware we have today. They couldn’t have existed twenty years ago, even though they would have been much more efficient than the alternative. This is the reason they now dominate: becaue they are technically possible.

I doubt the trend will stop anytime soon. As computers become faster, further consolidation can occur, and because it is efficient, I believe it will occur. Game engines will move to encompass every aspect of a game’s functionality. Gaming houses will employ more scripters than programmers. Eventually, some years down the road, scripters will be replaced by “directors” and “set designers”, who will operate using much higher level tools than text-based scripting languages. Gaming houses will have no more need for programmers than do movie studios: both will buy tools that enable them to get the job done much more efficiently.

Of course, the world will always need programmers to write the game engines (”game engine programmers”). But those positions will be few and far between, the market dominated by a few heavyweights. Think about other areas of software design. If you want to work on word processors, for example, your options are severely limited. You have three or four choices, and that’s it. The same will happen to game engines.

There will be a last (professional) game programmer, yet.

It’s becoming harder to hide. Satellite imagery can spot a house in a desert well enough to discern details as small as 1 square meter, while an increasing percentage of the population carries cell phones capable of taking pictures and even recording full motion video. Security cameras are no longer limited to the local 7-11, either—most stores have them, as do many office places. Welcome to the age of surveillance.

Nothing is more responsible for this phenomenon than the rapid pace of technological progress. Digital cameras cost pocket change to make. You can sign up for free e-mail accounts that come with enough space to store the entire human genome. And, to paraphrase, Feynmann, there’s a lot more room at the bottom.

These advances seem to be heading, inevitably, toward omnipresent, continuous surveillance technologies. I can imagine a relatively near future where even the walls have eyes—where nearly every structure that humans create can be gifted with the ability to sense, to record, and to wirelessly transmit data to cheap, plentiful storage centers whose contents may persist for hundreds or even thousands of years. A future where the world is filled with miniature flying and crawling devices that exist solely to record data (stationary devices marketed to voyeurs already enjoy high market demand, not surprisingly). A future where even the poorest receives as much camera time as the richest and most famous.

By itself, universal surveillance doesn’t imply a great loss of privacy. Sure, while you’re strolling through your neighborhood, you might be observed by a thousand different cameras (or people, for that matter, which you can think of as cameras with very fallible memories). But each one only sees you for a few seconds. This implies both that such surveillance is not a very great threat to your privacy, nor is it very useful to others. Who wants to see 10 seconds clips of random strangers passing by a storefront?

In order to pose a real threat to privacy, or to be useful to anyone, universal surveillance must be paired with something more. As the Internet has shown, the mere existence of a great deal of information is not intrinsically valuable. Many sites contain useful content, but they’re not useful to you unless you can find them. Similarly, universal surveillance is impotent unless paired with centralized organization and powerful querying tools.

So if surveillance is to become both a privacy concern, and worth enough to justify its cost, there must exist entities that collect numerous video feeds (perhaps paying the providers a percentage of the fees earned, or perhaps merely granting them access to other feeds in exchange for sharing) and enable users to query them for specific information. Imagine a service like Google, but for video, where you can find video feeds of a particular person by uploading their picture. The technological barriers to this scenario are mere years away, not decades.

I’m not so much concerned whether these developments would be a good thing or a bad thing—as with most technology, it is good in some respects, and bad in others; helpful for some people, and hurtful for others. Rather, I’m more concerned with the kinds of implications this would have on society.

I imagine increased demand for enclosed garages and window tinting. I envision the emergence of ‘transfer hubs’ for the rich and famous, which would accept buses and tinted cars carrying passengers who have privacy conerns, and swap them to other buses or cars, to make tracking more difficult. Simultaneously, I would predict a massive decrease in infidelity and many other kinds of crimes. Sure, you may rob a bank with a mask on your face, but before you were at the bank, you were somewhere else—and your path was tracked from that point to the bank, and back even further to wherever it was you first put your mask on.

In such a society, crime work might reduce to a game of deduction with vast amounts of recorded data. Private detectives might never leave the comfort of their offices. The world would be a different place, indeed.

Better or worse, that’s for you to decide.