The problem is that finalizing any sort of decent interface for the game can be risky, in my opinion, if there's so much content left to be done. After all, it's hard to design an interface if you don't know half of what you're designing it for, and it would take a lot of extra effort if he had to gut the whole thing again later.
Leaving the UI of a game until the end is a really really bad idea. The UI is not just something that is tacked onto a program; the UI is the only connection between the player and the engine, and thus it has as large of a role in how the game is played and enjoyed as the engine does. The reason above ground structures aren't very common, for example, is in part because the UI for building them is so inconvenient.
There are a number of aspects of DF that I'm simply not sure a good UI could ever be designed for. Which means that something about the way the user interacts with these features will have to change, which means that something about the way the game is played will have to change. And that's not the sort of thing that should be left to the end. Let me give some examples:
Job assignment:
Currently the UI for determining which jobs a dwarf does is an embarrassing mess. To turn on or off a job you have to scroll through a huge unordered list. Because the list is not in alphabetical order (or some other logical order) turning on or off a job essentially means reading through every page of that list again and again until you end up memorizing the positions of certain common jobs. Would ordering the list make for a better UI? Yes, but there would still be problems. The sheer length of the list is an issue, even if it were ordered and could be manipulated with the mouse. One way to get around the list is job profiles. Instead of changing what a dwarf does by changing their individual jobs the player could instead select a job profile for them (out of a much smaller number). Having to mess with the full list could become an issue only when editing a job profile, which would be much less frequent. Or, alternatively, the job list could be broken up into groups (such as stoneworking, woodworking, food preparation, etc). The list of these groups could be a manageable length. The player would then have the option to turn on or off all jobs within the groups, or to go into the group and make changes to some of the jobs.
Both UI solutions change how the game is played. In both solutions it would be rare to have a dwarf with just one job. It would also be common for some jobs to always be found together (such as fishing and fish cleaning). Thus a more sensible treatment of job priorities would be required. Time sensitive tasks, like trading and butchering, would have to be preferred over others. Additionally, there would have to be some preference for job rotation, lest all the fisher/masons (to pick an arbitrary example) spend all their time fishing and none of their time making cabinets. That's one example of how a sensible UI can lead to changes in how the game is played.
Mining:
Mining is another good example of how the UI has an impact on how the game is played. In this case the relevant UI decision is the top-down method of display. This encourages horizontal construction because it is easier to visualize how everything on that level fits together. Furthermore it is easy to designate passages in a horizontal direction for digging. In contrast vertical shafts are more difficult to designate, and it is hard to keep track of where rooms are in the level above and below. Together this encourages building fortresses that have a minimum level of vertical connectedness, and which have their major rooms on only a few levels. This is not a problem so much as an illustration of how the UI can have an impact on how the game is played. If the UI encouraged creating vertical fortresses then the extremely shallow depth limit would be a problem; currently it's not because of the UI. Again, a late change in the UI to make building vertical fortresses easier could mandate raising the depth limit significantly, which might in turn would require a better way of storing the map data than in a giant 3-dimensional array (which is a memory waster, given that most tiles stored in it have nothing interesting going on in them). So that's another example of how the UI can affect how the game is played, which can in turn affect how the engine is designed.
Concluding remarks:
Because the UI is the only thing the user is interacting with (i.e they don't interact with the engine itself, no matter how nice), and because it has a large effect on how the game is played, the UI should be considered to be just as important as the game engine. (Note: UI, not graphics.) Thus the UI should be developed alongside the game, not tacked on at the end as an afterthought.
Author
Topic: Re: DF Eternal Suggestion Voting (Read 2524 times)