I think that no real programmer who gets to use some piece of software enough to form any kind of attachment or opinion about that software does not stop to think about the internals and how he or she would implement it. Especially if that person loves programming and does it with a passion.
If I were implementing my own DF inspired game, which I am not (wink wink nudge nudge
) I would focus on the following:
- User interface and accessibility
One of the biggest hurdles one has to overcome in order to enjoy DF is the steep learning curve that is not helped in any way by the way the interface is designed. I would make this my primary focus.
Graphics don't mean that much without gameplay, but they sure help. Having graphics that mean something even for the uninitiated is a huge benefit.
Take a few elements that you want to have in common, and implement them. Then test responsibly. Then balance them. Then think about it. See how much effort it was, if you want to continue and if you are heading in the right direction. I would not go wild and add dozens of barely functional semi features so I can say that my game is as complex as the competition.
As good as you might be there is always the chance that someone more creative is out there. Give them the means to create content for your game if they wish. Make it as easy as possible. Do not make them learn some semi programming language that only you use. Do not make them edit some weird text files.
This is only a short list of items and some of you might consider most of these unimportant. But keep in mind: there is already someone out there who is striving to make the most impressive and strangely entertaining piece of simulation (I am talking about DF). So other people can focus on other parts if they wish so. Arguments like "Toady does not care about graphics because he is busy creating a deep simulation" do not work here. Maybe you do care about such things. I need to check out Goblin Camp more and see how it differentiates itself from DF.