Jump to content

Mad Mike

Members
  • Posts

    350
  • Joined

  • Last visited

Everything posted by Mad Mike

  1. Hi poesel, I can confirm that your campaign crashes CMBN . I will have a look and see if I can provide any help. The concept could be quite interesting, maybe if we get it to work, we could test it with a very small force to assess its feasibility? Cheers, Mike
  2. JonS is right, the campaign script is not part of the .cam file in its original form. It is just a set of instructions for the campaign generation process of CMx2's scenario editor how to create a campaign. Thankfully, the important information will be written into the .cam file in directly readable format, i.e. it is not encrypted.
  3. I don't know, it is quite uncommon, for games at least, to have a specific download charge applied to them. The cost for providing an infrastructure is certainly included in the full price for the license, i.e. it is hidden, but it will have been calculated. I guess what BFC must have calculated is the cost for them for the expected number of customers downloading the installer 10 times. I know for sure I only downloaded CMBN and CMFI exactly one time, so I paid for 18 downloads (and the associated bandwidth) which I never used. I would be more than happy to share these with anybody whose download expired. I would also bet that I'm not the only one never used all the downloads. Just something to take into consideration when talking about numbers and cost.
  4. From what I understand from Schrullenhafts post, the $5 fee is to cover download costs, which is fair enough. But you don't purchase such a thing as a "download license". You purchase a license to use the program called CMBN, how it arrives on your computer is quite secondary to this purchase. The limitation introduced by Battlefront is purely there due to cost issues since they are not in the mass download provider market. But in theory it should be ok to share an install image of CMBN since without a valid license key it would be unuseable. This is of course assuming that the license/activation scheme used has not been compromised.
  5. Artofwar, you could use the tool I created, see my signature for links to BFCs repository and GreenAsJades Mod website. It will extract all individual battles from the campaigns and will tell you the settings for each battle (basically what the campaign script does, which a campaign writer has to create when the campaign is produced - see CMBNs manual for details). This would allow tweaking of single battles and, if you wanted and had some time, rebuilding of these changed scenarios in a new campaign. V2.0 should have no impact on the tool, since I think no camaigns have been updated for V2.0 and the tool seems to function with scenarios created under V2.0. Cheers, Mike
  6. One final comment (hopefully, I can already hear people groaning ). I cut you slack for bugs, they do happen. But I would never go so far as saying that I'm not unsatisfied by them being in the product. Also, after reflecting what has been written here over the past days, this discussion for me is not about comparisons and what other companies, which sometimes make shiploads of money, do equally bad, but what you - Battlefront - could do better. I understand now, as a result of this discussion, that you don't see any way of expanding your automated testing. This is due to constraints in resources/budget and a perceived return on investment which is too small. But pointing to others as examples for bad practices and things gone wrong to paint own mistakes in a better light is not really a constructive way of thinking. That's why I tried not to compare and rather speak about general principles. I can see that this seems like preaching about theory, but it is the only starting point really. In my opinion, it is fair enough to say: "In principle, automated unit testing helps the developer to create cleaner code and enables him to implement and check changes reliably and quicker, especially for unintended side effects in the code unit behaviour. Due to the special nature of the software project under development and a resource/budget constraint, we made the decision to not do this and try to ensure overall quality by other measures". It is not fair enough to say: "Since NASA uses automated testing and they still had bugs, this whole automated testing stuff can not be worth much and we should therefore not do it." It is simply a wrong argument since it completely neglects that the automated testing has probably caught thousands of smaller and bigger bugs and errors in this NASA project and the "metric and English values" anecdote is rooted in faulty application of specifications. After reading the wikipedia entry about this example, automated testing could have picked this up - but was probably not implemented correctly. Still, this discussion has been worthwhile and educational for me, since I now understand your way of working a little bit better. I still don't agree with the automated testing part of it, but it's of course not really my concern.
  7. Automated testing, especially for games, is not superior in any way to testing by users. If you interpreted my comments in this way, I can only clarify that automated testing can complement the testing by the users already in place, ensuring that certain bugs will not reach those users so that they may concentrate on testing the integrated product. I hope this is an understandable way of approaching software testing - testing from small chunks or individual parts towards more complex, user driven testing of the whole game. I wouldn't say my dissatisfaction is petty. I just don't agree with the "release it now, fix it later" mentality from a customer point of view, which is hopefully quite natural. Wholesale subscription to this approach as a customer, no matter which game developer does it (and they all do in these days), I would describe as "gullible".
  8. Steve, thanks for the reply. For the sake of letting you get back to work instead of arguing with me, I can only say that I have to remain one of your unreasonable customers. I hope you can agree that this is certainly not the worst imaginable outcome of this small debate.
  9. Sorry for the double reply, but if I may be allowed to try to summarise your point of view on this, I would say that: You are quite happy with the stability and bug-to-feature ratio of the game. All bugs, should they occur, are collateral damage which can not be avoided in any way given the constraints and even if they could be avoided, it doesn't matter since the customer actually accepts this state of affairs and any further modification of the way you're testing is therefore not necessary. I would not agree with this as there are always measures for improvement, a defined set of "test points" or (even selective) automated unit testing being two of them. If my summary is incorrect, I would like to know where I misinterpreted what has been said.
  10. That would not be good enough for me, but of course I'm not going to tell you how you should run things. I can only tell you that I'm not really satisfied with the final result with regards to stability and fatal, game-preventing bugs. That would be an interesting survey. I am not sure one way or the other. But I would definetely like to see some survey like this.
  11. I actually did not try to be ironic. I really believe that something like this would cripple your ability. So there is no argument here. Things are the way they are, especially real constraints like time and resources. But style follows needs and resources, surely. And statements like " I am telling you, emphatically, that automated testing is NOT DONE." are not mine (also, admittedly, not yours). But we can only discuss things which are being stated, so maybe some care should go into these statements. Sure, as I'm the customer and not involved in your development. The bugs which remain are all I have to go by in my judgement. As such, I'm not satisfied with the bugs which are in the game. Nothing more, nothing less. But those bugs I mentioned should have been caught, especially since they are in areas which are common in a lot of typical games of CMx2. Start a QB via PBEM and check if everything works. Create a map with every terrain feature and placeable object (mines etc.) and check if everything works, in play. I apologise for the quoted "QA", it was indeed a cheap shot on my part. I'm interested, does your QA have a catalogue or list of points and functional areas (user workflow) of the game which have to be checked before the game or a patch is released?
  12. Should not make a difference .. are you sure you both are using the same versions of the game? What you're describing sounds like a version mismatch.
  13. You're in the software engineering business as well, which is quite universal in its principles. The basic failure or bug causing reasons are the same for every piece of software, no matter what it is programmed to do. I also think you don't have a clue about programming or software engineering, but of course you have huge experience as a game designer, which I'm obviously not questioning. I know more about software engineering than you, without a doubt. About game development, not really .. but in the end it is all software development which follows universal principles. Just because it is a game doesn't make it so special - that's just a chip on your shoulder. Nope, still quite the opposite, while Phil's response was quite balanced even with the admission that some automated testing seems to be done already, yours is still trying to paint everything in black and white with the justification that your software product is a game - which doesn't really matter.
  14. I can believe that it would cripple your ability. I didn't make any assumption on any specific bug being caught be automated testing. But it will catch bugs, including some which will have an impact on the overall stability or gameplay. So you do test automatically after all .. why is that, if it doesn't suit your development style? Yeah, but in your special case the "QA" is just not working so well - barbed wire crashes, quick battle crashes, wandering crewman .. not a track record show case advocating the QAs effectiveness.
  15. 100% agree with you. Steve doesn't know what he's talking about here, and it's actually embarassingly obvious and painful to read - for every software engineer with some experience who has ever worked on big projects in the real world. Mind baffling response by Battlefront, really. :eek:
  16. I agree, cases can be constructed ad infinitum to argue for or against automatic behaviour like the one I described. So I'm not really expecting this behaviour to change. Yeah, but real human beings would try to kill the TC (if they perceive a good opportunity) and then try to stay alive. They wouldn't be thinking "Oh, I will be staying here no matter that there is a tank 100m away which now knows, with high probability, where I am. If it should proceed to shoot me, well then, that's fair enough..". But basically I still agree with you, I don't think we will see this kind of sophisticated Tac AI behaviour in CM for some time, if ever. I don't agree that the current controls are an adequate solution to the general problem though. But, after all, it's just an (imperfect) game.
  17. The shooting part is not so bad, but as soon as the result has been achieved - either a killed TC or buttoned-up tank - the infantry should change its place .. automatically. If they are in a house, get out of it (behind it). At least that would make it more realistic. And the player can not always intervene when stuff like this happens early in a turn (assuming WeGo PBEM, for example).
  18. So then you switch off your brain too when you're playing against the AI? Seems to me that's the biggest cheat available to us. But seeing some of the posts on this forum I have no difficulty believing that some people never cheat against the AI.
  19. I'm quite sure it is. Imagine, a snow white field during the night .. suddenly, a flare lights up the scene and you discover that all which is left of your three man scout team is a trail of blood. This would be epic.
  20. To a small degree I do sympathise with the thread originator. CMFI is a rather small leap forward in my opinion. After 5 years since the first release of a CMx2 game (CMSF), we are still playing in the summer season, basically in the same two kinds of terrain set (mid-eastern arid and european summer). It seems that is much more difficult / time consuming to move to different seasons / weather / ground conditions than has been originally envisioned. So this alone gives CMFI the feel of "Same old, same old". Another thing which is still missing is fire, which has been in the CMx1 titles. So, the evolution of the engine is going far too slow, in my opinion. I wouldn't be surprised if the next "family game" would be the Eastern Front 1944 (Bagration), which, you've guessed it, is in summer again . Anyway, just wanted to give some support to the poor guy, since I can understand his feelings about this.
  21. If there are two different sets of "aim accuracy", then this could also explain the very accurate tank crews with their pistols. Since (pure guess here) CMx2 could still treat the crew as a vehicle, they could have different aiming accuracy than normal infantry. Anyway, pure guessing since I don't know the internal algorithms. But the test of the HMG against infantry and then a vehicle is certainly interesting.
  22. GaJ, I've raised a bug report (96_gkbj22cc), the log info is attached to it. Cheers, Mike
  23. Hi GaJ, great stuff, I usually only have opponents who use dropbox, but in a current battle, my opponent only uses EMail, so I tried the EMail support. Sending seems to work ok, but when H2HH tries to check the mailbox for new files, I always get this error: IOError: [Errno 9] Bad file descriptor Is there anythin I can do to make this work?
  24. You will have to re-pick. What usually helps is to check the battle type "Axis Attack", "Axis Probe" etc. before setting up the QB in the Scenario Editor. Then set "Human pick" in the map selection and choose an appropriate map. I think what mostly does not work is putting the Germans on the attacking side of a QB (and the Allies on the defending side) when that QB is an "Allied Attack" or "Allied Assault" etc. This can be avoided if you select the map manually. Other than that, I don't know of any workaround.
×
×
  • Create New...