In the latest Redmond Developer News, William Zachmann writes "Game programming is fundamental to understanding where software development is headed in the years ahead", which is a position I happen to believe quite strongly myself. And then...

... then he says absolutely nothing at all.

Oh, there's a couple of book recommendations, two paragraphs about how the techniques of game programming mirror the development of the GUI in the 80s and 90s, and since GUIs obviously became important in time, so will game programming. What parts of game programming, you ask? Why, just this list:

Full 3-D modeling, person and vehicle animation, scripting, textures, lighting effects, object physics, particle effects, voice and video creation and streaming, plotting, goal setting and scoring, scenario building, player interaction strategies, lighting effects, heads-up displays (HUDs), object rendering, damage-level maintenance, artificial intelligence (AI) and virtual-reality rendering are just a few of the component technologies that go into game creation and development. Any one of them can be a totally absorbing learning experience all in itself. Mastering game development requires learning about them all -- and more.

Frankly, the whole article was essentially fluff. Zero in the way of logical defense to his argument, and zero in the way of prescriptive advice, aside from "Learn it all, my son, learn it all."

So here's how I think the article should have read:

Only a game? Think Again (the Ted Neward Version)

Developing enterprise software has never been an easy task, and the demands of corporate IT departments in the next decade are only going to get more stringent. Users demand snappier user interfaces, more expressive displays of data and information, higher performance and scalability, much better interaction among the various user- and machine-driven nodes in the network, and more and more "assistance" from the software to get users from "A" to "B" without having to do all the grunt work themselves. (It's a tough job, moving the mouse, clicking it, moving it some more, clicking again and again and again.... And Lord, then you have to type on the keyboard.... It's amazing the average IT knowledge worker doesn't draw hazard pay.)

So where does the enterprise developer find the skills necessary to stand out in the 2010s?

From his free-wheeling high-flying long-haired pizza-snorting DietCoke-mainlining cousin over in the entertainment software industry, of course.

Consider, if you will, the best-selling game World of Warcraft, not from a point of view that describes the domain of the software, but from its non-domain requirements, what some people also refer to as the non-functional requirements:

1. Performance: if the software behaves sluggishly, users will complain and quit using the software, which directly affects their bottom line: they charge access fees on an hourly basis.
2. Security: if users can hack the software to grant themselves higher access or change their data (gaining more gold, items, whatever), users will complain and quit using the software. (This is a huge deal, by the way--an entire economy has sprung up around MMORPGs like WoW, where people will pay real-world money--or other real-world currency--for WoW-world goods and services. If attackers can alter their WoW accounts, that can translate directly into hard real-world cash.
3. Scalability: the more simultaneous users, the more cash in Blizzard's pocket.
4. Concurrency: these users are all interacting in sub-second timeframes with each other and the rest of the system, so accuracy of information exchange is critical.
5. Portability: the more systems the software can run on, the more potential users the software can attract (and, again, the more cash in Blizzard's pocket in return).
6. User Interface: a tremendous amount of information needs to be available to the user at a moment's notice, and a huge variety of options must be quickly and easily selectable/actionable.
7. Extensibility: users will need new and different elements (scenarios/quests, character types, races, worlds, and so on) in order to stay interested in using the software. (This isn't generally a problem with enterprise software, since it's not like you're going to be excited about using the HR system anyway, but extensibility there is still going to look a lot like extensibility here.)
8. Resiliency: In the inevitable event of a crash, data must not be lost, or users will be... miffed... to say the least. Clear distinctions between transient and durable data must be drawn, and must be communicated to the user, so as to manage expectations accordingly. And it goes without saying that if a server (or server farm) goes down, it must come back up or be hot-swapped with another server/farm as quickly as humanly possible.

No doubt hard-core gamers could come up with a variety of other features that would--once the gaming domain is removed from them--be recognizable to the enterprise developer. Naturally, the entertainment industry has other areas that generally a software developer doesn't run into--physics modeling and what-not--but surprisingly a great deal of the modern video game can, and undoubtedly will, make its way into the enterprise software arena. Some thoughts that come to mind:

1. Animation. Apple has certainly been at the forefront of incorporating animation into user interface, but this is just the tip of the iceberg. Particularly for software that will reach out to the general public, first impressions mean a great deal, and a UI that grabs your attention without being overly dramatic will leave users with warm fuzzies and fond memories. This doesn't even begin to consider the more practical applications of animation, such as a travel reservations system providing a map with your trip itinerary graphically plotted, with zoom-in/zoom-out effects as you work with different parts of the trip (zoom out to look at the air routing, zoom in to look at a particular city for the hotel options, and so on).
2. User interface paradigms. The modern video game, particularly those that involve deeper strategic and tactical thought (a la the real-time strategy game like Command & Conquer), make heavy use of the heads-up display, or HUD, to provide a small-real-estate control panel that doesn't distract from the main focus of the user's attention (the map). Microsoft has started to work with this idea some, with the new Office 2007 taking a very different approach to the ubiquitous menubar-across-the-top, going for what they call "ribbon" elements that fly out and fly back, much the same way that the HUD does in C&C. Also something to consider is the map navigation system, where simply moving the mouse to the far edge of the screen starts scrolling in that direction. Consider this before you dismiss the idea: horizontal scrolling is completely verboten in the word processing app, yet we do it all the time (without too much complaint) in the modern RTS. Why? I submit to you that it is because scrolling is so much easier in the RTS than it is in Word/Excel/whatever.
3. Player-to-computer interaction. This is different from UI in that the computer often has to masquerade as a player, and in order to do so in strategy games (a la Civilization IV), the programmers typically limit the interaction to very specific statements. Now consider natural language parsing (an offshoot branch of AI research), which can take English statements, break them down, analyze them and respond according to the content of the statement. How much easier would it be for users to say, "Show me all the unsold merchandise for the Northern California region for the years 2005 to 2006", rather than "SELECT * FROM merchandise WHERE ..." or navigating a complex report form?
4. Speech and sound. Consider the user who is blind, or is missing digits from either or both hands. How useful is a computer then? Now consider the same user who can speak to the machine (a la the natural language point above) or converse with the machine, as blind people do with other people, every day. Not everything has to be presented visually--I eagerly await the interaction of cell phones to Interactive Voice Response systems that are backed by a natural language parser. It's coming, folks.
5. Scripting languages. Most games are built as game engines written by programmers, with scenarios or missions or quests (or whatever) written in some kind of scripting engine and/or scenario editor. This is the epitome of the domain-specific language, and was done to allow the non-technical knowledge worker (the game designer and playtest leads) to be able to adjust the scenarios without requiring complex development steps.
6. Explosions and "ka-boom" sound effects. Well... I suppose you could get one of these when you deleted an employee from the system, but that's just getting a little gratuitous.

The point is, all of these things, and more, could--and I submit, will--radically change how we build business software. And considering that most game development isn't about twiddling assembly instructions but writing in modern high-level languages (native C++ being the most common, with Java and C# bringing up a close-and-rapidly-growing second), complete with high-level abstractions and libraries to handle the ugly details (including lighting effects, object interaction, and more), it's fast becoming reasonable to learn these skills without having to throw away everything the enterprise developer already knows.

As for resources, a trip down to your local computer book store or Amazon will yield a plethora of game-related titles, some of which focus on the details of 3D graphics, others of which focus on game design (the actual modeling of the game domain itself--how many units, hit points, etc). One interesting series to consider picking up is "Game Programming Gems", which are collections of short essays on a huge variety of topics--including the recently-discovered concept of "unit testing" that the entertainment industry has just picked up.

So yes, we have a few things we can contribute to them, as well. *grin*

And besides, it'll finally be nice to explain to your non-technical friends and family what you do for a living. "Well, you see this? I wrote this..." will generate "oohs" and "aahs" rather than "Um... that's just text on a screen, what did that do?"