Joel Billings
Posts: 32265
Joined: 9/20/2000 From: Santa Rosa, CA Status: offline
|
Well I came back from vacation to see a nice discussion taking place here re ZOCs. In some ways I will respond to this in the same way I responded to the discussion about stacking. There are at least three major areas I think about when considering pushing for code changes: 1) Time/resources required to make and maintain the change, and likelihood of the change causing other code issues that can lead to a cascading time/resource suck. 2) Impact on the way the game plays out. Will it move us in a direction that fixes something that doesn't appear right about the game. How hard will it be to balance that impact to get the desired results vs. causing side effects that will push balance out of whack in other parts of the game. 3) Impact on the game interface. How will the player "see" the situation by looking at the map. Will the interface need changes that will make the game easier to play or comprehend? Will the change add to micromanagement that the interface won't keep up with. Remember that starting out, the design for War in the East was inspired by the early boardgames on the subject (like SPI's War in the East). There was a conscious decision to make the game play like a boardgame, and to follow boardgame constructs. Both to keep the game simple (relatively speaking) and to keep the game "familiar" to the audience that would be interested in this game. I find it interesting to find a post saying that if only the design team had more boardgame experience we would know about some of these issues and possible rules. Gary and I grew up in the 60s and 70s playing boardgames, and continued playing them even after we started making computer games. Pavel came along 20 years later but also has a big history with boardgames. We may not know all the various rules that have come along, but we know a lot of them (or most of them). As stated, we started off with WitE1 being more a homage to the games of the 70s. Again, this made things simpler for us on the interface side of things, and simpler on the gameplay, and I think that's one reason WitE did so well given that fundamentally the game is massive and not to be picked up by the faint of heart. There were some sacrifices made in terms of realism, but there were gains that came from this approach (at least in terms of 1 and 3 above). Now that we are where we're at, any changes being made have to be looked at through the lens of the 3 categories I listed above. I agree that stacking is not ideal, but where is it really impacting the game, and what change can we make that won't add unreasonable dev time and won't cause interface issues that negate much of the benefits to be had. I agree that in an ideal world the composition of the forces in a hex should impact the delays imposed by the ZOCs. However, again, one must look at the alternatives with those 3 categories in mind. The game, any game, is nothing but a series of abstractions that taken together either work or don't work. Arguing the realism of any one item in the abstract is like a straw man argument. Easy to make, sometimes very convincing, but not entirely intellectually honest (sorry, not trying to offend anyone's honesty with my limited ability at analogies, I know you guys all want to make a better game, or a better game in the way you enjoy it). One more thing. With WitE I very much wanted to have a game that was like a boardgame. One where the rules weren't so complicated that a player couldn't actually calculate out MP costs and have an ability to plan out a move. Clearly as the game developed, and complexity was added (along with FOW), that simplicity was mostly lost and the game became one that has to be played more intuitively. This is true in combat where looking at CVs alone doesn't work, so good players get a feel for what it takes to win a combat (but you never know for sure). Same goes for movement, where costs going through ZOCs and rivers and bad weather make knowing MP costs virtually impossible except when you mouse over a particular hex with a particular unit selected and see what you will have left if you make the move. Players have to become more intuitive about how far they can push their units through an enemy line. Gary prefers this in his designs and is happy to see players get a little less info and be faced with having to make more intuitive decisions, and where the game is less deterministic. I can say now that after WitE/WitW/Torch, I have reached the point of acceptance that this system is not a boardgame, and that the players don't have to know everything. So if we do come up with some variation in ZOCs, we might not even have to show this on the map, especially if by looking at CV values and/or unit types a player could get a sense for how likely a hex is to be more costly to move through than another. This doesn't mean though that we'll make a change. Items 1 and 2 above might argue against it, but we will consider it, as we have considered many changes since WitE1. It would be nice to make carpets less effective, but if/how we do this has to account for the issues above. Speaking of changes since WitE1, we have two already, one of which has come up in this thread a few times already. One, we've added movement delay costs associated with combat in a hex. This is in WitW already. When a combat takes place, based on whether a hasty or deliberate attack and the final odds, some amount of movement delay is added to the hex. This delay does adds to the cost to leave the combat hex. So it's not harder to get into the hex (I know, I know, it can be hard to get into a hex), but it makes it harder to move out of the hex. This accounts for the time it takes to fight and win the battle, and the fact that this gives exploiting units less time remaining in the week to move through the combat area. Yes, another abstraction, but it does what we want it to do in adding some time delay based on the amount of resistance. Second, WitE2 has a rule that causes units to lose MPs in their next movement phase when they are attacked. Again, it is based on the odds. This makes it more advantageous to launch spoiling attacks. As for stacking, knowing what we know re the difficulty of changing the 3/hex limit makes a change problematic. Pavel has considered allowing player's to create a special unit in some hexes that contains other combat units, and acts like a combat unit. This would be mostly (or entirely) for urban and port hexes, where high unit density was achieved. In most other cases, doctrine prevented dense concentrations (I say most cases as I acknowledge situations where you should be able to stack higher, especially when you're dealing with smaller units). However, no change will be easy, and again, with limited programming resources, we may decide that this falls low on the list and fails to make the cut. We like the basic idea, but we have no magic wand that would allow us to implement the change quickly. The dev team does enjoy reading active discussions with suggestions for improvements, so please continue to discuss these things (just please be civil).
_____________________________
All understanding comes after the fact. -- Soren Kierkegaard
|