ContentTools:UserDesign:General

From VsWiki
Revision as of 20:22, 15 May 2008 by klauss (talk | contribs) (Initial generalities for user design documents.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.

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: it highlights python syntax. Rather, the editor will 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. 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.