Except I'm not programming illiterate.
RPG maker seems to be the rough equivalent of the map editor.
By default, item you make don't interrelate with other parts of the game. Looking over what it seems to be doing, the game mechanics are linear or affine. Things are collections of (relatively sparse) properties.
In comparison, a unit in civ has a huge collection of properties which change how it behaves in game, and how it relates to other parts of the game. And this is in the default game, well before you go and do custom mods (like FfH).
About the only way to make a relatively easy to use thing like that work would be to go with an inheritance object model for units -- so a Warrior would be a COMBAT_UNIT, ANCIENT_UNIT, BUILDABLE_UNIT, RESOURCE_FREE_UNIT and LAND_UNIT, would inherit properties from all three (which would vary from default values, to "virtual must-implement in child" properties), and then you'd go off and set the fixed properties that the above collection of templates would require.
That kind of design could slow down game development, or speed it up, depending. It would make the unit loading engine much more complex (as it involves building, validating and using an entire class heirachy, instead of individual stand-alone classes). This could slow down game loading and game play (there is some hope it would speed up game loading).
It definitely makes the engine code more complex and introduces bugs there, and it might reduce bugs in the game design side. But game designer XML-monkeys are cheap, and game programmers code-monkeys are not (and the programming task involved is not a trivial one, while XML typos are trivial ones -- so you can use cheap XML-monkeys on the game design bugs, but cannot throw cheap code-monkeys at the programming problem).
A really basic GUI editor that they couldn't use (because it couldn't generate the base templates) would be relatively easy to write with the above system. That kind of editor, if kept simple, wouldn't be at all useful for actual initial game design -- just for adding new components. A more complex version would end up being a monster of a design problem, and would easily be the kind of thing that would be jetted to keep a project delivered on time. Designers who are working full-time on Civ5 who did the editing "manually" at the XML level would end up being faster at it than those that used the GUI in any case. (easy to use GUIs mainly help the inexperienced, they end up slowing the experienced down in most problem domains)
Meanwhile, the modable XML work is all stuff that would be useful in-house to get the core game out the door.
---
In Civ4, they didn't release the XML parsing code. Probably won't do it in Civ5 either. If they did, one could implement an inheritance based game-object system that would then admit an "easy to use" GUI for trivial tasks like creating a new unit.
There remains the cliff between that GUI and actually editing XML. I don't see an easy way to lead the GUI users gradually into XML editing, and without that step those people are pretty useless to the rest of us.
Maybe we could cripple the engine and have it generate XML code in a copy/paste buffer, and require that the end-user place it in the file themselves? That would get them used to looking at it (the XML stuff that defines a unit, say), and they might (gasp) believe they can manually edit fields. Because if they remain stuck in the GUI, they'll be limited by what hard-coded options the GUI designers picked for them.
RPG maker seems to be the rough equivalent of the map editor.
By default, item you make don't interrelate with other parts of the game. Looking over what it seems to be doing, the game mechanics are linear or affine. Things are collections of (relatively sparse) properties.
In comparison, a unit in civ has a huge collection of properties which change how it behaves in game, and how it relates to other parts of the game. And this is in the default game, well before you go and do custom mods (like FfH).
About the only way to make a relatively easy to use thing like that work would be to go with an inheritance object model for units -- so a Warrior would be a COMBAT_UNIT, ANCIENT_UNIT, BUILDABLE_UNIT, RESOURCE_FREE_UNIT and LAND_UNIT, would inherit properties from all three (which would vary from default values, to "virtual must-implement in child" properties), and then you'd go off and set the fixed properties that the above collection of templates would require.
That kind of design could slow down game development, or speed it up, depending. It would make the unit loading engine much more complex (as it involves building, validating and using an entire class heirachy, instead of individual stand-alone classes). This could slow down game loading and game play (there is some hope it would speed up game loading).
It definitely makes the engine code more complex and introduces bugs there, and it might reduce bugs in the game design side. But game designer XML-monkeys are cheap, and game programmers code-monkeys are not (and the programming task involved is not a trivial one, while XML typos are trivial ones -- so you can use cheap XML-monkeys on the game design bugs, but cannot throw cheap code-monkeys at the programming problem).
A really basic GUI editor that they couldn't use (because it couldn't generate the base templates) would be relatively easy to write with the above system. That kind of editor, if kept simple, wouldn't be at all useful for actual initial game design -- just for adding new components. A more complex version would end up being a monster of a design problem, and would easily be the kind of thing that would be jetted to keep a project delivered on time. Designers who are working full-time on Civ5 who did the editing "manually" at the XML level would end up being faster at it than those that used the GUI in any case. (easy to use GUIs mainly help the inexperienced, they end up slowing the experienced down in most problem domains)
Meanwhile, the modable XML work is all stuff that would be useful in-house to get the core game out the door.
---
In Civ4, they didn't release the XML parsing code. Probably won't do it in Civ5 either. If they did, one could implement an inheritance based game-object system that would then admit an "easy to use" GUI for trivial tasks like creating a new unit.
There remains the cliff between that GUI and actually editing XML. I don't see an easy way to lead the GUI users gradually into XML editing, and without that step those people are pretty useless to the rest of us.
Maybe we could cripple the engine and have it generate XML code in a copy/paste buffer, and require that the end-user place it in the file themselves? That would get them used to looking at it (the XML stuff that defines a unit, say), and they might (gasp) believe they can manually edit fields. Because if they remain stuck in the GUI, they'll be limited by what hard-coded options the GUI designers picked for them.
