ContentTools:UserDesign:General
Back to User Design Documents
Users are not developers
A key principle to have in mind when designing content creation tools is that the end users utilizing them won't be developers. Yes, they will be developing a game. Yes, we can include them in the credits as "content developers". But they're not by far close to the level of understanding of the innards of an engine that the word "developer" entails.
So, by "Users are not developers" we mean that implementation details of the engine must be hidden as much as possible. Every moddable aspect must be exposed in an intuitive, conceptual way. Rather than an editor of "config variables", we need an editor of "configurable behavior". If we cannot avoid using a set of editable variables being exposed, we must provide an easy way to interpret them. Perhaps by graphical visualization of the effects of those variables, perhaps by graphical editing, or perhaps with descriptive documentation. The latter is the least preferred.
Thus, a unit editor will never give us an edit box where the "unit scale" would be input. It would rather give us a slider or other input method to the "size" of the unit, already taking into account the actual dimensions of the unit's 3D mesh (which would be used to derive the scale parameter the engine requires). Because the size is what matters to the user, not the ratio of meters to mesh coordinates.
In the same vein, a mission editor will never give us a text editor where to edit the python scripts that materialize the mission. That would be pointless since average users will not understand that. In fact, I myself, a developer, wouldn't want such a tool - because it doesn't help. Gedit is better suited for that: it highlights python syntax. Rather, the editor would present the script in a conceptual and easy to manage way. No code at all.
In general, where a point & click interface is possible it must be implemented. Many developers prefer keyboard/textual input because it's more natural and quick for them to use. And let's admit, because it's far easier to code. But that's exactly the opposite of what end users want/find natural. In fact, not even every developer would understand textual input, one must know the innards of the underlying system to efficiently use it. Point & click interfaces, on the other hand, are self-explanatory and guide the user.
And we want Users, lots of users, to contribute
We don't want to be user-friendly in our tools to rival Windows. We don't want that to rival commercial games (although that would be cool huh?). We want it because we want users, the entire user base, to help us create content for VS. If we create tools that only developers (furthermore, VS developers) can use, we miss on them. Then VS ends with no content. Cue: sadness, tears.