Longshanks Desires Peace?
(Fondly Dedicated to Mike VanFlandern)
May 24th 1995, I remember it well because it was the day Braveheart opened in movie theatres. It was just a couple months after the successful launch of DirectX at the Computer Game Developers Conference. I was suffering from an extreme case of frustration because despite the success of DirectX among game developers in truth it was a very tiny project with a handful of engineers and a loose coalition of support from engineers scattered across the company embedded in an extremely competitive and volatile corporate environment. Great, we’d sold everybody on a platform Microsoft wasn’t really committed to and now we had to deliver. Of course almost immediately after the launch of DirectX things started to unravel.
It started with DirectInput. During the course of the first attempt to port Doom to Windows, I had asked Craig Eisler, who we had conspired to get embedded on the Windows multimedia team, to fix the Windows joystick API’s for me so they worked reliably enough to support games. In theory it should have been a pretty minor fix. Of course Craig doesn’t do anything half-assed, so he undertook the rewrite the driver API to work really well. His solution was simple, versatile and elegant. No biggie, the quicker he got it done the faster he could get back to focusing on the far more important graphics issues we faced. Of course being an Evangelist and having very little of substance to pitch to game developers as a reason for making Windows 95 games prior to DirectX, I made a big deal out of our improved support for game input devices, which resulted in press, which resulted in hither-to unheard of other teams at Microsoft “popping up” with an interest in what we were doing. In the case of DirectInput it was the Windows Mouse team, who, as it turned out, had a secret project to create a Microsoft branded joystick. They had their own team making a joystick API for their own internal use.
Now we had a classic Microsoft political problem. If it happened to be the case that Craig Eisler working alone for a couple weeks had cranked out a fantastic joystick API and shipped it with Windows 95… what would the point be of employing a team of six over in the mouse group to make another one? Clearly the only rationale for their continued existence must be;
1) Whatever hypothetical API they are planning to deliver at some unspecified point in the future must be “superior” in some way to the solution Craig finished last week.
2) That the API THEY are developing is so strategic to Microsoft’s product interests that they should own specifying the input API’s for everybody!
Now the truth was, we needed all the engineering help we could get on DirectX, so if I could turn the mouse teams joystick API guys into the DirectInput team, so much the better! Score +6 engineers! I was happy to make heroes out of those guys if they wanted to join the team. So I met with their product lead, a guy named Mike VanFlandern (to whom this blog is dedicated) and we agreed that they could be responsible for producing the next version of DirectInput and that we would only ship Craigs API with the Beta of DirectX to give Mike VanFlandern time to deliver his “vastly superior” Input API. From my point of view, Mike’s API was another example of Microsoftian, giant, convoluted, over generalized, incomprehensible API mess making…. but… I was used to that from Microsoft engineers and despite their tendency to like to make big API messes when left to their own devices in a vacuum, they often had good intentions. If I exposed them to some real customers early and made them work closely with some real developers who actually had to deliver a real working product based on their API’s, they would do the right thing and tighten up their act. Unfortunately this uncharacteristic optimism on my part was not always positively rewarded.
Mike’s team wasn’t able to deliver a beta build of their API in time for the DirectX Beta, or as it appeared likely, even in time for the launch of Windows 95. I had diligently invited Mike to DirectX design reviews, connected him with live developers and encouraged them to use his API in their products. All of this was manageable however, because we had Craig’s finished input API to fall back on. I was looking forward to one of those rare occasions when I could point to another product team I had helped make successful without first having to beat some sense and customer focus into them. As always it seemed, this was not to be. Mike could take all the time he wanted to fiddle with his convoluted API as far as I was concerned provided he did not commit two unforgivable sins.
1) Cause the delay of any games slated for release with Windows 95
2) Piss off or endanger Microsoft’s relationship with an important developer
Mike VanFlandern was of course enjoying the attention and interaction with real game developers which was good, but it was also clear that his API was NOT getting done in time and he was pushing some of my developers who were scheduled to ship for Christmas 1995 to adopt it. Recalling my experience with Chris Hecker and WinG I did not want to find myself in another situation where I had to sit on him to get his product done on time or face dozens of angry game developers. Perhaps one of the great problems with human nature is that people seldom appreciate when you’re trying to do them a favor. I told Mike to reign back on pushing his API for games on the Windows 95 bombing run. Mike didn’t take this polite request to heart, in fact, he staged a secret meeting with Origin, our earliest DirectX adopter to push adoption of his API for all of their games without coordinating it with me. I was furious, but contrary to my reputation, I didn’t WANT to come down on him, as with Hecker and WinG, I really wanted to help him be successful and make him a hero. I believed (and still do) that one of the healthiest things that good evangelists did for Microsoft was take development teams who were ordinarily very cloistered and cut off from the real-world and consequently tended to produce very “abstract” over designed products and connected them with real demanding customers whose livelihood depended on delivering a product on a schedule. I found that product teams that successfully adopted a “customercentric” view of their roles found it extremely difficult but rewarding to be on the front line of shipping products and to be the responsive heroes to struggling developers who were dependent on them to deliver functionality they needed to earn a living. Some of the early folks who helped out with DirectX before it was a real product, like Todd Laney, Raymond Chen, Matt Wilson, Bob Heddle and many others were absolutely adored by the Game Developers they worked with because it was so unusual for a giant company to pay such close attention to what they needed.
Mike VanFlandern, however, was destined for a rougher path to “enlightenment”. It was the afternoon of May 24th 1995 that Eric, Craig and I decided to take break to see the much lauded Braveheart movie. Obviously it was one of the greatest movies ever made and it influenced me profoundly. In retrospect I suspect that I was probably one of the few people in the audience rooting for Longshanks but on that afternoon in that frame of mind, Mike VanFlandern was reminding me a lot of Longshanks incompetent son. Eric, Craig and I left the movie very pumped up and I had decided that the “right thing to do” in this situation was to burn Mike’s product team out of the sky before they got the opportunity to drag me into a WinG like debacle on the eve of Windows 95 launch. That evening Eric, Craig and I fired all our guns at VanFlandern.I arranged for the highly respected and influential Todd Laney to write an email critiquing the quality of the Joystick teams API and its convoluted nature. I complained far and wide that Mike was jeopardizing the launch of many much anticipated Windows 95 games. I orchestrated a company wide smear of the broken, late, ill conceived, joystick team API. I contacted my game developers and apologized to them that the DirectInput API would not be finished in time for Windows 95 and that they should fall back to Craig’s API for their Christmas titles. Within 48 hours it was all over, the joystick team was officially relegated back to making a proprietary API for their own future joystick product and nothing else. If I felt any guilt for my harsh measures it was salved by memories of the WinG debacle.
Surprisingly Mike’s place in the DirectX history books did not end here. Two years later DirectX was re-orged under Deborah Black and Eric, Craig and I were “re-deployed” on the task of crushing Netscape. The Joystick team shipped the Microsoft SideWinder joystick with Mike’s joystick API’s and Jay Torborg (creator of Talisman) made Mike’s API the next version of DirectInput. By this time I had a whole team of evangelists including one dedicated to DirectInput who was also working with developers to use the new API. Below is a classic piece of email from Tim Sweeney, the founder of Epic, on the subject of the SideWinder API. Of course the API was so popular… that Microsoft made it the standard input API for the Xbox as well and it went on to become the natural successor to DirectInput… in the absence of anybody else at Microsoft working on it I suspect…
From: Alex St. John
Sent: Wednesday, May 21, 1997 10:50 AM
To: Trudy Culbreth
Cc: Jason Robar
Subject: FW: DirectInput force feedback support [resend]
“Feedback” from Tim Sweeney from Unreal. Pretty serious, it sounds like the brilliant joystick group handed you another fat joystick API. What’s the story?
From: Tim Sweeney [SMTP:[email protected]]
Sent: Wednesday, May 21, 1997 5:30 AM
To: Jason Robar; Alex St. John
Subject: DirectInput force feedback support [resend]
[resend – sorry, my previous attempt at sending was cut off]
Jason & Alex,
I’ll keep it simple: The DirectInput force feedback API’s are high level and
don’t provide the “direct” low-level support I need in order to support
force feedback in my app. I have your prototype SideWinder FF, it’s
*awesome*, and I’d like to support it but I need a simple way of setting the
What I need is something like this:
// Set the force feedback axis values for the specified joystick.
// nJoy = Number of the joystick you’re referring to.
// cAxes = Number of axes whose forces you’re setting, i.e. 2.
// fForces = Axis forces, from -1.0 to 1.0. 0.0 means none.
joySetForce( int nJoy, int cAxes, float fForces );
I have already set up a wide variety of support for force feedback in the
Unreal engine, based on the assumption that I would access the joystick
forces directly: ambient forces, specific impulses, and specific responses.
This would make for some very cool feedback cues (imaging walking over a
cobblestone floor, and feeling the bumps, properly magnitude- and
frequency-shifting according to movement).
However, DirectInput only provides access to to FF through the
IDirectInputEffect abstraction for playing predefined forces and possibly
creating new forces which may or may not be supported on the hardware. This
is limiting, complex, and, well, not very direct. With the FF API’s as they
are, there is a 0% chance of FF support in time for showing at E3, and
probably 25% chance that it will make it into the final product. The FF API,
like Direct3D, deals with a lot of interrelated objects, so the amount of
programming work needed to support FF well in Unreal is prohibitive.
With direct access to the forces, support would only take a day or two to
implement, and I’d probably have a 50% chance of supporting it in time for
E3, but definitely 100% for shipping with it.
I think adding a very simple low-level function like joySetForce is easily
justifiable: it’s simple, it enables developers to do more custom effects,
and it enables developers to support FF far more easily, an important point
given that so many top games are produced by small teams for whom supporting
(or not supporting) an API is often a decision made based on simplicity and
development time, rather than business strategy. I am also assuming that
DirectInput uses something like “joySetForce” internally, and all that’s
needed is to expose that functionality.
Overall, I was kind of surprised to see the huge set of FF API’s instead of
a simple force-related function and some caps info. One would think that
DirectInput’s purpose is to expose hardware functionality and let the app
define specific stuff to do with it: to me, seeing things like
GUID_SawtoothDown in DirectInput is like seeing a function call like
IDirect3D:Draw3DModelOfACow(int nUtters): it might be useful to certain
developers, but it’s app-specific rather than “Direct” hardware functionality.
Tim Sweeney, Epic MegaGames Inc.
Years later I apologized to Mike for bulldozing him and we made up. Like so many Microsoft engineers, Mike was very talented, hardworking and well intentioned. He was hardly equipped to know what he was getting himself into when he signed on to the DirectX bandwagon in that era. Mike even became friends with Eric Engstrom and joined one of his product teams many years later.
For completeness I have included links to the original DirectInput spec as written by Craig Eisler and the DirectInput 3 spec as contributed by the Windows Mouse team two DirectX generations later.