This sort of above commentary by Bluddy is exactly why I like to keep track of the immutable design goals. Because it really helps us to evaluate commentary like that in light of the core thing we're going for here. Nowhere in our list of immutable design goals does it ever say "there will be a strategy game grafted in here, and citybuilding too." Or that the strategic parts will be turn-based. What it actually says is this:
6. AVWW should have some form of "macro game" to it, which provides longer-term goals and choices, and lets the player guide their whole civilization to a degree, rather than just one individual.
...
12. AVWW will be a platform for having multiple gameplay modes (and even genres), with more being able to be added at later times through free DLC, expansions, or otherwise. Each of these modes should tie into the central action-adventure gameplay in some fashion, and consequences throughout the world should be as cohesive as possible, but progress in any of the modes should not be penalized if the player ignores them for a while. In other words, no "crop withering" or anything close. Players should be able to sit down and feel like Environ is an interesting place to go to do a variety of interesting things, and when they choose to go to Environ their first question is "what do I feel like doing today?" They should be able to play any subset of the game to match their mood, while the other subsets of the game remain safely in stasis until they feel interested in them again.
And our interpretation of the above, for first implementation, has been a strategy game plus citybuilding, plus a combat model for the macrogame that we've not yet revealed but nonetheless is a third genre. Sometimes it's good to take a few steps back from the current implementation, though, which is what we seem to be doing a lot of this week.
When it comes to the macro-game, it seems like the turn-based aspects of that are giving some folks heartburn. On the other hand, I don't want to be rushing around like Din's Curse (awesome game or no) trying to put out fires constantly.
At core, in all aspects of the game, I want to see some goal, figure out how to achieve that goal, and then set about it until I succeed or give up. Then on to the next. That's the flow that I'm personally interested in.
And it's true, I do have a lot of fondness for TBS games, and would like to build one. But, this isn't the last project we'll ever do, so perhaps it's worthwhile to think about if those aspects really need to be in this game. Keith's combat model for the macro game is really interesting and I think the thing he is most excited about. And the turn-based strategy game was one way to go about making those sorts of encounters happen. The enemies advance on you, you advance on the enemies, etc, etc.
But perhaps having the enemies aggressively move on you in a turn-based fashion when you're able to just circumvent the turns and run around at will just isn't compatible with the game. Maybe it needs to be that the enemies NEVER aggressively move on you unless you stir them up in some fashion, and then they aggressively move on you based on some form of counter. And likewise, when you want to send out your forces to deal with the enemies, there's nothing to stop those sorts of encounters from being initiated without the larger TBS strategy game framework.
Of course, that would royally screw with the scouting model that we have, which I'm not thrilled about losing. And I'm sure that it would monkey with other plan's of Keith's, too.
But in the interest of brainstorming, it's an interesting thought experiment at least: if the TBS bits don't graft in as well, is there a way to accomplish the other bits connected to them that doesn't rely on the TBS framework, which still makes Keith happy and interested in his part of the design?
And Keith, for that matter, since you're so much MORE interested in some of the other bits (pathos and conflict as you put it) of the macrogame, is there basically a way we can crop out a lot of the bits you're less interested in -- putting them on a less-involved framework, for instance -- so that you can spend a lot more percentage of your time working on the bits you think of as most desirable? That's another way in which rethinking or removing some of the TBS bits might let you work on the bits you're actually more excited about. Or it could just wreck everything.