ZOOMIE1980
Posts: 1284
Joined: 4/9/2004 Status: offline
|
quote:
ORIGINAL: Joel Billings I don't know if Mike Wood has posted in this thread as I haven't been able to keep up with the volume of posts here. I just wanted to give you my take on this discussion. I think that the model is probably lacking in dealing with daylight engagements against totally unprotected convoys. Once you bring in night and/or any escort of more than token size, I think the model works pretty well. There is so much going on under the hood with detection levels of the TFs (pre-combat and post combat) as well as working within the limited abstraction of the naval combat system that for most situations the I feel the game comes out with reasonable results. One thing that seems odd to me is that TFs docked (unloading/loading) don't get hit any harder when attacked. Part of that is based on the assumption that in many of these cases, the ships would have some warning of the approaching enemy TF and would have pulled up anchor. This is even assumed at some level when dealing with airstrikes against docked TFs, although I've forgotten by now exactly how the model deals with these situations. Of course, there is always the chance that the TF would be caught by surprise and should be sitting ducks. So fundamentally I agree with those that think the realism of the combat model could stand to be improved in the situations I mentioned. Having said that, I also don't find the weakness in these areas to be so important to greatly impact the overall game. Of course, that's just my opinion and I can understand those that disagree. From my point of view, this issue is not a bug that requires immediate attention. Mike is still trying to get rid of things like disappearing units (which is a bug), and combat formula changes have to take a back seat unless they are getting in the way of playing the game. Once the important bugs have been fixed, then we can move on to trying to improve things that aren't broken but just aren't quite working as well as we think they should. Now, assuming we agree that a change is desirable (and I do), and we have the time to look at it (after the bugs are fixed), we get to the difficult part of figuring out just how to make that change without making the game worse instead of better. The bad news here is that I'm guessing that it will be very difficult for Mike or Gary to adjust the code to get the desired results without throwing another part of the surface combat system out of whack. I bet that with some investment in time, they could find a few formulas to tweak, but that they will be guessing at the impact of the changes and won't know for sure what other parts of the game they will be affecting. I've been down this path before and can tell you that the combat formulas in this game are multistep formulas that impact many different areas. They are not the simple formulas I was used to dealing with back in the days of the Apple II (anyone remember Warship). During development I was always amazed whenever I asked Gary about a formula, only to find out from Gary that what I expected to be 2 or 3 lines of code was actually more like 20, with the interrelationships of the variables being very hard to figure out. I can't say that this area is going to be like that, but I'd bet good money it is. So when they go to look at this to try to make a change, it's likely that either the simple change will impact more than we want, or a much more complex, case specific change will have to be made. This probably can be done, but will take more time and won't necessarily get the desired effect. At that point testing will have to be done to see if it worked on the test saves, but there's always the risk it will break something else which won't get noticed in test. For me, the first question I ask if I'm trying to decide whether to look into changing something is "just how important is getting this right to my enjoyment of the game" or said another way, "if I get this to work just right, will my enjoyment of the game been taken to a new level". Given the chance of making things worse, the answers usually had better be that it's pretty important and yes, it would make the game much more enjoyable. Does this issue pass the test? On this issue, I'd say that as it is not a bug, it should wait until the bugs are done. Once the important bugs are fixed, it's worth looking at to see if there is a simple fix, or reasonably simple fix in those areas that seem to be the biggest problem (daytime, small/no escort, unloading). If yes, it will get addressed. If the answer is no, than a decision will get made as to whether it's worth the time and risk at that point. The decision won't get made until the programmer makes that initial evaluation, so any comment now would be premature, other than to say that it will get looked at. This is true on many issues that are not really bugs, but things in the game that people understandably would like to see improved. I hope this helps you understand the situation better. Mike and the testers are working through bugs and user posts as quickly as they can. As you all know by now, this game is massive, which means that testing any change is a very difficult undertaking that takes time. Think of WitP as a battleship steaming along at 30 knots. Getting the ship to change direction takes time. It's not a PT boat. UV was a PT boat compared to WitP. But then PT boats is an altogether different surface combat issue, isn't it. I think I can agree with almost everything here. This whole thread is a nitpick. In a properly played game we should see only the tiny handful of these types engagements, anyway. But what gets me is always the logic imposed to make the points for and against. Mogami leads us to believe the code modelling surface combat is ENORMOUSLY complex and not abstracted at all, taking into account specific yardage ranges of shots fired, and down to where a shot is landing on a ship. I can't imaging why you guys would bother with such minutia is a STRATEGIC level game. A broad, generalized, highly abstracted combat resolution would seem to more than suffice. And if found out of whack a bit, such a thing would be much easier to tweek than a complex, tedious implementation would.
|