Posted: 15 Aug 2011, 11:00
Zini wrote: 1a. One of the TES-CS's few strengths (some may argue its only strength) is its beginner-friendliness. Except for a few (very) rough edges, a beginner can start doing simply things in the editor without reading much documentation.
That is an important point and we should always keep it in the back of our heads during the entire development. To be successful in the modding-community, our Editor must be beginner friendly, though not necessarily with the same means as the TES-CS and certainly without the rough edges.
1b. ... but the main target audience are people who work on a TC-class project, who are by definition not beginners. These would include actual TCs (Total Conversions) and something like TR.
With OpenMW the attractiveness of creating a completely new game with this technology should increase substantially and if we are successful with our project, I expect to see a notable increase of MW-based TCs.
For us this means we always have to keep the scalability in mind. For each feature and GUI element we should ask ourself how does this scale with increasing quantities and complexity.
1c. We should work on the assumption, that the TES-CS did it wrong. I can tell you from my experience with working on a TC-class project, it did (with a very small number of exceptions).
Therefore when we end up with a GUI element or a feature, that is similar to what is found in the TES-CS, our fist thought should be that we made a mistake. At this point we should take a step back and do a review again.
1d. For now we only need to provide all the editing capacity that comes with the TES-CS (and we should make sure to do that).
But we should keep in mind, that we might want to do more with it post 1.0.
There are some tools out there to manipulate ESM/ESP files interactively (e.g. TESAME). In the long run we should integrate their functionality into the editor.
Also we probably want to use the editor as a debugger front-end for OpenMW content development (scripts and other stuff).