Middleware Postmortem: IDV Inc's SpeedTreeRT

We know we're not the first people in the game development industry who think they've stumbled onto a good idea. We get approached all the time by colleagues who have created some cool water effects, a better way to create sky effects, or a new physics algorithm. So, this postmortem is written for the next aspiring middleware developer, as well as for game developers curious about where tools come from, and anyone else who likes stories about humble products created by small companies that overcome various problems (including the occasional flood) and end up making it through.

Unlike the game developers we sell to, we did not start working on SpeedTreeRT with a grand, visionary idea. Instead, the foliage-creation middleware that is now integrated into titles by companies like Mythic, NCsoft, Big Huge Games and Monte Cristo started out as an element in a golf simulation.

But from the moment we first began thinking about a better way to render truly 3D trees in large amounts, SpeedTree began evolving, first as an in-house offline tool, then as a plug-in to 3DS Max, and finally as a full-blown, real-time SDK.

But before we tell you what we did right and wrong, here's a quick overview of the SpeedTree product line and history:

A suite of three products, SpeedTree is founded on SpeedTreeCAD, a Windows-based tool for tree and plant creation that facilitates the detailed design of vegetation. SpeedTreeCAD is not offered as a stand-alone tool, but is an essential part of SpeedTreeRT, our real-time foliage creation SDK, and SpeedTreeMAX, our 3DS Max plug-in.

SpeedTree was hatched by Interactive Data Visualization (IDV), which also creates 3D technologies for military and industrial clients, when we were asked to develop a real-time golf simulation. Because of the importance of trees to a virtual golf course, we looked long and hard for a tree rendering solution that featured compelling wind effects, allowed flexibility in tree creation and ran efficiently.

After a fruitless search, we decided to make our own trees and developed a small in-house package where some of our most notable features were born, including the overall procedural geometry generation algorithm, our first pass at SpeedTreeCAD, and the overall lighting and wind effect approaches. Before the golf simulation ever saw the light of day, unfortunately, its backing dried up and our fledgling tree software got shelved.

Four or five months later, however, an architectural firm contacted IDV and asked for an animated rendering of a proposed 25-acre residential and commercial development, complete with almost 1,000 trees, each one to be detailed and wind blown. Fearing that our in-house tree creation system wasn't up to the project, we again sought to outsource, pursuing tree plug-ins for 3DS Max.

However, we again had no luck. Many of the products we looked at did not have wind algorithms, while others offered only one extremely detailed version of each tree, which would have made large collections of trees inadvisable. Some, to put it nicely, just didn't meet the aesthetic standards our customer required.

So our in-house tree software was dusted off, refined and, to our surprise, performed adequately. The resulting animation, which still gets plenty of play at local civic events and business meetings, brought to life a large residential and commercial development planned for our hometown of Columbia, S.C. Lush, animated trees line the streets, fill a park and stand along the river, helping flesh out the architect's vision.

With this project under its belt, IDV decided to move forward, to invest the time required to fully develop and market the SpeedTree software. Of course, we knew there was still a big difference between an in-house tool and a viable commercial product. Fred Brooks estimated in The Mythical Man-Month [Addison-Wesley Publishing Co., 1995 (first publishing 1975)] that if it takes an hour to create a software tool for your own use, it will take on average 10 hours to make the tool usable for others. This principle has been borne out on many projects undertaken by IDV, and we expected a similar development burden for SpeedTree as we began our first effort, creating a commercial plug-in to 3D Studio Max.

Six months and many developer hours later, our plug-in was done. SpeedTreeMAX began selling exclusively at Digimation in the winter of 2002. And in December 2002, after many more 'hours' and some twists and turns described below, we made our first sales of SpeedTreeRT, our real-time foliage/tree middleware SDK, which allows automatic levels of foliage detail, real-time wind effects, and multiple complex lighting options over hundreds or even thousands of trees.

______________________________________________________

What Went Right

1. Right Place, Right Time. Just before the launching of SpeedTreeMAX, we posted an article on OpenGL.org introducing some of our fellow developers to SpeedTree technology in general and gauging interest in a real-time incarnation of the software. The article included a link to a demo version of SpeedTreeCAD that would allow developers to get a feel for what SpeedTree might be like in a real-time setting. Luckily, Sebastien Domine of NVIDIA noticed the article, downloaded the demo, and contacted us. Intrigued by the technology, NVIDIA asked us for a SpeedTree-featuring demo to help them promote their new hardware technology.

We agreed, seeing the demo as a way to research interest in real-time tree creation among game developers, and NVIDIA ended up being an excellent partner to help us get our message out. The demo, showing a mechanized fighting machine launching and dodging missiles amidst breeze-blown trees, was put online, and over the next three months, more than 40,000 people downloaded the demo. Many of those early fans of SpeedTree later became customers, and we continue to be grateful to NVIDIA for their help at the start.

2. Focus. In this case, 'focus' really encompasses two separate areas -- marketing focus, and product focus. As IDV and SpeedTree have grown, our response has consistently been that we don't need -- or even want - broad exposure. Instead, we need exposure among that very small, select group of people who can actually understand the value of what we're selling. Our experience at E3 2003 bears out this belief: One small mention on a Dark Age of Camelot player site generated thousands of hits to IDV's website and lots of positive posts to the message boards read by game developers, while a prominent mention in The Wall Street Journal generated exactly one phone call -- from a local accounting firm soliciting business.

A second element of focus has been sticking to foliage. We've been asked by customers to do sand, rocks, dirt, rain, lakes, waves and snow. Again, tempting, but we resisted. Instead, we have focused on and rapidly evolved our foliage tool, releasing five versions in 18 months with dramatically expanded control over tree and root structure, wind effects, levels of detail, etc. At the same time, our definition of foliage has grown increasingly broad, even encompassing undersea life such as kelp, fan coral, sea urchins, and other underwater species.

3. Acting on Feedback. From the start, we set up an active evaluation system, permitting potential customers to download a fully-functional but time-limited copy of the SDK from an FTP server for free. The positives were legion. Potential customers got to play with our software (and get hooked on it) while we got not just our foot but most of our leg in the door. But the benefits went beyond just getting closer to a single sale. We often thought of ourselves as "selling diamonds to jewelers," purveying a high-end product to exacting and extremely knowledgeable customers. If there was a flaw, they would tell us immediately. If there was room for improvement, we were sure to hear about it.

To our relief, there was both acceptance and quite a bit of constructive input. As soon as they were signed up, our evaluators began firing questions, ideas and suggestions at us about the SDK, and the product began improving far more rapidly than if it were just us working on it. Every new user became a member of IDV's virtual development team, and the input, insights and requests they provided have led to many important changes to the software.

In fact, some important features of SpeedTree weren't our idea at all. Instead, they were given to us -- for free -- by those using and evaluating the SDK. The only price we had to pay for their invaluable advice was listening -- and admitting that perhaps their way was better than ours. Early on, for example, one important change prompted by a customer was the addition of texture twisting and random texture offsets for adding better variety to the branch geometry. In hindsight, this was an obvious suggestion that has greatly increased the realism of our trees, but who knows how long it would have taken us to come up with it ourselves?

4. Support. IDV has always tried to make support a priority when it comes to SpeedTree. Any question, whether from a customer or just someone trying out the software, was handed off to one of the system's developers and handled promptly. Our thinking was that these are, after all, the people who are paying us or willing to consider paying us. We also knew that support meant, ultimately, better looking trees and a better looking game -- and a successful game would be a stronger selling point than any demo or brochure we could put together. In terms of the contracts we've ended up winning for a number of different games, it seems that our continued support (even within the previously mentioned active evaluation system) has really helped people step up and make the decision to buy the product.

5. Making SpeedTreeRT a Versatile Numerical Engine. At the outset, we planned to make SpeedTree a rendering engine, but we reluctantly abandoned that idea on the advice of an industry partner. Instead, SpeedTreeRT is a numerical engine that doesn't depend directly on any specific graphics API. The SDK is also hardware independent and does not make use of any system-specific calls. And these all turned out to be sound decisions, ensuring SpeedTreeRT's versatility and broad usability in an industry that employs a wide variety of technologies, much of it in-house. In particular, creating SpeedTree as a numerical engine has made it possible to easily integrate the SDK into dozens of engines on a variety of platforms, compared with a rendering engine, which might not play well with existing rendering engines within the product being integrated into.

______________________________________________________

What Went Wrong

1. Graphic Artist Not On Board. For the first few months of SpeedTree's life, we had no help from a graphic artist. The earliest versions of the trees, demonstration and tutorials were all created by our software engineers. In particular, our initial tree library was woefully inadequate, as we later learned. We launched SpeedTree with just a few dozen tree and bush species, assuming that our customers would prefer to bypass the library and develop their own plants. But once our first licensees started sending us screen shots and demos, we were surprised to see many of our original trees in them, little changed from those we had provided in that first small library. Since then, we've gotten to where we should have been to start with, adding full-time and part-time art staff and almost a dozen college interns to expand our tree library (now at 150 species & more than 200 MB worth), to help with demos, and to design marketing materials. But investing in art staff up front would have made SpeedTreeRT a stronger product out the gate, and would have freed up programmers to do what they do best, meaning the software would likely have been released earlier and started earning money sooner.

2. Flood. In August of 2002, the very month we began signing up our first SpeedTreeRT evaluators, a contractor working on the city's water system hooked up the wrong water pipe, sent tens of thousands of gallons to the roof of our office building and flooded every one of the 10 floors here. In our sixth floor suites, the water was more than an inch deep, and everything was soaked -- computers, books, furniture, files -- even the first SpeedTreeRT evaluation form we ever received, which still bears the wrinkles and water stains of a good dousing.

Fortunately, we kept backups of our software and some of our computers were salvageable. But we had to scramble to buy or borrow replacement furniture and computers. To add insult to injury, it took almost 20 months to be reimbursed by the city's insurance company for our losses. If we'd ever bothered to get a simple property insurance policy, we would have been compensated within weeks. But instead, because we let business overhead concerns take a back seat to our obsession with programming, we had to absorb substantial losses for more than a year. What might we have done with the money? We probably would have hired an artist sooner and found a way to get our ongoing improvements to SpeedTreeRT out the door more quickly.

3. A Vision Unshared. Early in its development, some of those with major input into company projects advised that SpeedTree was a horrible idea. We were told the trees created with the system looked terrible, that game developers were a high-ego crowd that liked to do everything themselves and didn't see the value of middleware, especially something as specialized as SpeedTree, and that if we did offer it, we'd have to have renderers written for every possible platform and engine combination. The negative input almost killed the project, but we persevered and the naysayers have since left or have bought into the vision.

4. Legal Fees. As the size of the firms we're licensing SpeedTreeRT to has increased over the last two years, the length of time it takes to negotiate the average contract has grown as well. Sections we thought were innocuous have become the subject of complex, multi-continent email exchanges and lengthy conference calls, sometimes conducted late at night to accommodate our customer's Asian time zones. And there have been weeks where almost every evening ended with a conversation with our lawyer about that day's legal issues -- and he bills by the hour. Bottom line, selling to larger firms has meant an increase in cost of sales but without -- because the biggest firms tend to be very sensitive to publicity -- an increase in our exposure as a licensor to top game developers. Which brings us to the next item:

5. Not Enough Publicity. A critical selling point for middleware is what games it's already being used in. The software might be fantastic and cheap, and the evaluation goes swimmingly. But like a new college graduate, a new middleware app faces that Catch 22 of getting business only by already having business. Fortunately, we found developers ready to take a chance on us early on, and we got into some great projects, even in the first few months after launch. Unfortunately, some of those great projects are with extremely secretive firms, and we won't be able to tell anyone about them for as much as another couple of years.

6. Reseller Issues. In the months after launch of SpeedTreeRT, we spent literally weeks worth of time negotiating contracts with resellers around the world, granting commissions of up to a third of our license fee and exclusive rights over large swaths of Asia and Europe. How much middleware did our resellers move? Not much. Of course, we also didn't have to part with a painful chunk of our money on lots of commissioned sales. But in hindsight, it would have been better if we'd stuck to a no-reseller policy from the start. After all, middleware is not something you just buy off the shelf. For SpeedTreeRT, the technical questions typically start before the evaluation's even underway. Good, competent answers have been a key to closing deals for us, and no reseller is going to be able to answer technical questions even remotely as well as the developers themselves. Also, the game development community is still pretty small and tight-knit, so if a good app gets out there, people will know soon enough, and take a look without having to hear from a software vendor in their nation. Korea, a worldwide hub of online gaming, has been an excellent market for us lately, with many sales accomplished without any help from a Korean rep. Get a review in a couple of industry magazines or websites, and make sure your site comes out on top when the right key words are punched, and the time and expense of reseller relationships become unnecessary.

Taking Root

Where to from here? SpeedTree middleware, unlike the packaged and released games more often featured in these postmortems, is a living product that will continue to evolve, likely with new version releases, and possibly with an expansion pack or two. We often get asked, for example, if our trees can be burned, knocked down, blown up or shot. Of course, since we sell the source code, we always say yes, and NCsoft's Auto Assault picks up on this ability of our trees nicely. But it would be great if we could provide customers with a quick short cut to that functionality.

Given the number of titles licensing SpeedTreeRT since the start of 2004, and the wide variety of firms and genres going with us, we like to imagine that our foliage middleware has set a new standard for the real-time outdoors, something that you might be surprised to find marketable as a piece of middleware. But as long as game development remains one of the world's hottest industries, we expect to have to run to keep up with game technologies, the expectations of our customers and, most importantly, the insatiable demands of the game players themselves.

______________________________________________________