Here's what ought to happen with small scale:
- Fewer creatures per player;
- Smaller maps;
- Less UI;
- More micromanagement (yes, it's present in DK);
- (code)less pressure for performance;
- (code)less worries about memory management;
- (code)less worries about where information is stored;
- (code)no need for threading (usage of multiple cores).
...and here's what happens with large scale:
- More creatures per player;
- Larger maps;
- More UI (especially in the management department);
- Less micromanagement (can still be present, though);
- (code)more pressure for performance;
- (code)a need for additional algorithms (flocking, for example);
- (code)more worries about where information is stored;
- (code)threading might be a good option (usage of multiple cores).
All this might seem insignificant now, but this decision needs to be made. Otherwise code is being produced without a clear direction and results might be undesirable.
Large scale vs small scale also tends to change what's needed for game-play.
So, what is needed to know:
- Maximum number of creatures and traps possible;
- Maximum size of the map and if it has multiple floors (how many at most) or just one;
- To what degree the engine and user interface can be influenced by scripting.
Making decisions like these early on makes sure the coders know what is needed. This helps with the development pace.
Also, is there a wiki around where documentation on what the current thinking is on this game is stored? This wiki could host documentation on the design decisions made (to prevent recurring discussions). NOTE: this is not the same as a design document.