Never build upon closed-source frameworks
A poster on tech-artists.org who is using Autodesk’s CAT asks:
The problem I´m having: I can control the ears now manually, after setting up the reactions, but apparently the CAT system isn´t respecting any keyframes I set on the facial controls, neither in setup nor animation mode.
He already hinted at the answer in the same post:
Even though I´ve heard a couple of times not to rely on CAT in production…
So there’s your answer.
Never depend upon closed-source frameworks that aren’t ubiquitous and proven.
It’s true of CAT, it’s true of everything. And in fact it is one reason I’ll never go back to developing with .NET on Windows (the 3rd party ecosystem, not the framework itself). If you don’t have the source for something, you 1) will never fully understand it, and 2) never be able to sustain your use of it. When I was at BioWare Austin, and the Edmonton guys decided to switch to CAT, I was up in arms for exactly this reason. We had an aging framework- PuppetShop- but it worked well enough, we had the source, and acceptable levels of support (Kees, the author, is/was readily available). Instead, they switched to a closed-source product (CAT) from a vendor that has repeatedly showcased its awful support (Autodesk), and headache ensued. Fortunately I never had to deal with it and left some months after that. Without the source, you’re dependent upon someone whose job it is to provide support just good enough so you don’t leave their product (which is difficult since they own everything), and bad enough that you have to hire them to fix problems (they pride themselves on this level of support, which I call extortion).
As for the ubiquitous and proven part: unless this closed source solution is incredibly widespread (think Max, Maya, etc.), and has a lot of involved power users (ie, Biped is widespread but difficult to get good community support for because it attracts so many novices), it means you have to figure out every single workaround because you can’t actually fix the problem because you don’t have source. Imagine working with no Google- that’s what you give up when you use a closed-source framework that isn’t an industry standard.
So don’t do it. Don’t let others do it. If you’re currently doing it, think about getting the source and if you can’t do that, start making a backup plan.
could just say never build on frameworks, although it wouldn’t be very practical ;)
I think open source is not so much the issue here. There’s many open source projects which, in theory, are serviceable by their users, but in practice are just too complex/advanced to do so, unless the problem is superficial or can be pinpointed easily and has few dependencies.
The issue I see here is: how much do you want to depend on 3rd parties?
Pick your frameworks, libraries and core technology carefully. Think it through for all your dependencies. Who maintains it? How long has it been around? How long will it be around? Has the feature changed significantly in the past? Is it an active project? Could you compile / fix it yourself (to what degree?), is there a community of users? Are there alternatives? Anyone else in your company has experience with it? How much functionality of the framework/library do you need? Can you write the required functions yourself? Is it portable (to older/newer versions of another framework/OS/target app)?
Downside: answering all this requires research and time and often we don’t have that. Short term time saving (well you turned to CAT to begin with ;) ) seems often more important than long consequences.
(especially when the fire is burning and they’re calling the tech art firefighters :/ ).
Another excellent essence of experience and wisdom, Rob. Thanks for putting it all together.
BTW I have change the studio couple oа weeks ago, and I’m thinking about your GDC talk about the culture all the time. That was and is really true.
@Dmitry
Heh, sometimes I just forget to check my messages for misspelling =(
While there is some truth to your statement, .NET in particular is proven and sort of comes with a source (there are disassembly tools like ILSpy – the source they give is very good – and the shared source initiative that can get you the original source code).
Ultimately, open/closed source is just another factor to take into consideration when choosing middleware. It is an important factor (in my book), but it is not something that unequivocally determines the winner. I.e. the choice between closed-source FMOD and open-source Audiere usually boils down to licensing/features, not to source availability.
Of course, source availability also affects the price (free open-source libraries / expensive source licenses for otherwise appropriately priced middleware) and the cost (support, etc.) – still, it is a factor, not the factor.
Dmitry: Thanks, my pleasure.
Arseny: I should clarify, there is a difference between “using” and “building upon.” Using a physics or sound library is usually not “building upon.” Using Unreal 3 would be. How much work are you doing that directly deals with and extends the framework (build upon it), and how much of it is just calling library functions and putting your own interface around it (“using” the framework). I have no problem “using” closed-source frameworks, even if they’re a bit unproven but novel, if you can replace it relatively easily. However if you’d basically have to redo all the work done so far to change it (as you would in this example), then my advice holds.
Regarding .NET- closed source DLL’s have given me too much grief and if they’re obfuscated you can’t really get good decompiled results, even for debugging. There were 3rd party controls in HeroEngine, and one of them would create a potentially several MB string each time you queried the text displayed in a control- which meant if you wrote lots of strings to it quickly, you’d get LOH fragmentation and crash! I understand the decisions but, we could certainly have optimized for this case. Lots of examples like that- they’re even worse than the copy-paste controls I used to find people sneak into our codebase! Mostly its the shitty middleware providers on Windows (who provide “enterprise” solutions in the form of awful dlls) that I detest.
Robert: See my statements above. Regarding not having enough time- that’s why I try to set down some hard and fast rules like “never build upon closed source frameworks” :) CAT doesn’t even become an option. Now of course we are free to break the rule but it makes the worst case the expected case so of course you have time to research now.
@Arseny Kapoulkine
sorry for non English: I’m just want to say “Hello” to my ex-college =)
Арсений, привет от бывшего коллеги по Криату =) Это Дима Астапкович. Индустрия такая маленькая =)
Let me see if I understood well about .Net. If I have the source code is fine but if not, switch to something else?
No, not at all. See my comments- .NET is a proven framework, my offhand comment was about the library ecosystem around it. I’m editing the post now since so many seem to have understandably took it to mean more than it said.