Mad Mike
-
Posts
350 -
Joined
-
Last visited
Posts posted by Mad Mike
-
-
I ... don't think it is. Although if you knew what you were doing you'd be able to recreate it from the info that MMs tool produces.
No, the script is a simple text file. It isn't edittable within the editor at all - all that has to be done outside the game on Notepad, or something similar. Actually, I'm not even sure the script is included in the .cam file at all. I think the script is used to compile the .cam, but doesn't become part of it (if that makes sense?).
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.
-
Let's assume that you bought a game CD (hardgoods) and played the game for two years, then for whatever reason your dog got into your storage bin and chomped the CD into little pieces. What do you figure the company that sold you the CD two years ago is responsible for?
Note that I'm not referring to BFC specifically. I'm just asking a general question and depending upon your answer I would be curious to know if any company selling software commercially has a policy that matches your expectation.
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.
-
No, it wouldn't. Having a personal, private backup of the files you paid to download is ok, and is authorized (even recommended) but a torrent is creating a public document for the purposes of distribution.
The files are a paid distribution that is the intellectual property of Battlefront, and it would be illegal and unethical to make an unauthorized distribution of the files.
In cases like this, you are actually not purchasing the files, you are purchasing a license to download and use the files. While BF is giving you an non-expiring license for use (playing the game) they are giving you a limited time license of one year for downloading due to the expenses they incur in storage. The $5 for downloading after one year is actually the purchase of a download license extension/renewal, not a repurchase of the files themselves.
Frankly, $5 is cheap, and likely does not fully offset the actual costs of storing and maintaining the files. Pay the guys already!
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.
-
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
-
Puts complaining about a PBEM game bug in a $50 program that will be fixed within about a month into perspective, doesn't it?
I will also remind the critics that NASA plowed a $125m satellite into Mars because one engineering team used Metric and another used English values. If NASA isn't using automated testing good enough to detect that... well, I think maybe we should be cut a little more slack for the barbed wire save bug.
Steve
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.
-
A point of reference: Battlefield 3
Made by DICE and published by EA with a huge development team and even larger budget. I know for a fact that both BFBC2 and BF3 went through "public beta". If automated testing is superior to actual users with a variety of hardware and playing styles, then why would DICE and EA bother with the "public beta" after their "internal beta"? Sure, you could say marketing, and I wouldn't ignore that as one of many reasons, but the fact that their games have all had "bugs" on release should be somewhat revealing as to the pettiness of your dissatisfaction with CM's current state and Steve's assertion that all game releases have bugs (an assertion that holds up in my experience).
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".
-
Yeah, totally off the mark because of that chip on your shoulder. I'll summarize things below...
I agree there is always room for improvement. Sometimes it is even practical. But we do not work in a vacuum with unlimited time and resources. We also know that overall customer expectations of quality and functionality are, in general, unreasonably high. Either from practical or technical standpoints.
Which means we must keep all aspects of software development in mind when we make decisions. We can not make engineering decisions as if the other elements don't exist.
Wrong in the sense that you are mischaracterize our motivations. Let me rework you words instead of writing new ones:
-----
We are generally satisfied with the stability and bug-to-feature ratio of the game. Most bugs, should they occur, are collateral damage which practically can not be avoided in any reasonable way given our constraints. Other bugs, given hindsight, could have been avoided. Where a pattern of weakness emerges we invest in preventing future problems of a similar nature. Reasonable customers actually accepts this state of affairs provided the bugs are not excessive and that the serious ones addressed through free patches in a timely manner. Fundamental modification of the way we're testing is not practical, therefore we do the best we can with what we have to work with.
-----
When I worked for Impressions (Sierra) my job was manage a QA department of 5 people full time. Our ONLY job was to find bugs and other sorts of flaws. That was probably a $300-400k annual expense for the company when you consider direct and indirect overhead. One game we tested almost exclusively every day for the better part of a year. When it shipped there was more than 1000 known bugs in it, ranging from fairly serious to really trivial. And more were found after release we hadn't found before hand. At least one serious one.
Battlefront doesn't have the resources to do such testing. And even if it did, I'm not sure the bug count would be much lower than it is now. I can say that you'd be paying a lot more for your games though.
Steve
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.
-
Then what the heck are you arguing about?
Cherry picking single lines out of context doesn't win you any points in my eye. Why not quote the rest of that paragraph?
So much for your position that I'm in conflict with Phil or that I'm viewing this as Black and White. What's more, even this more expanded quote is out of context of the discussion.
Are you satisfied with the bugs in the operating system you are using? How about the video card in your computer? How about other games? How much did you pay for that stuff and how much does other things you buy and do with them rely upon them?
In theory bugs should not exist in any piece of software or any hardware platform. How well does that theory work in reality?
And how many specific circumstances work as intended? Thousands. Success to failure ratio is definitely relevant to this discussion unless you believe in absolutes only.
In my previous life as a corporate gaming QA Manager we used to have checklists like this. We do not use checklists like that now. Based on my experience I say we have fewer problems without the checklist mentality than we had with ridged sign offs on checklists in my old job. And that was with vastly more simple games.
What we do is have a wide enough array of testers playing the game different ways with some guidance from us what elements should be tested. At times it is general, sometimes it is specific. When we are satisfied with the results we release.
It's the standard rule of diminishing returns. The amount of energy/time/resources we would have to put into hunting for a few extra bugs is not worth the investment. Not for us, not for you. Because all effort put into defensive programming means effort not put into expanding the capabilities of the game. I am sure if we took a survey the vast majority of our customers would agree that having a few bugs, which do get fixed, is an acceptable tradeoff for getting a bunch of new game functionality they would not otherwise get.
As I said earlier, if I was in charge of software development where people's lives were on the line I would have a completely different approach. And I would be charging appropriately for that approach as well.
Steve
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.
-
In my previous life as a corporate gaming QA Manager we used to have checklists like this. We do not use checklists like that now. Based on my experience I say we have fewer problems without the checklist mentality than we had with ridged sign offs on checklists in my old job. And that was with vastly more simple games.
What we do is have a wide enough array of testers playing the game different ways with some guidance from us what elements should be tested. At times it is general, sometimes it is specific. When we are satisfied with the results we release.
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.
I am sure if we took a survey the vast majority of our customers would agree that having a few bugs, which do get fixed, is an acceptable tradeoff for getting a bunch of new game functionality they would not otherwise get.Steve
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.
-
But you're aware of how much effort it would take to retroactively add exhaustive automated testing to a very large code base.
And you know how much development time we have available to us.
So... how would this NOT cripple our ability to turn out features?
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.
Great. No one doubts that. None of the major bugs from the last two years or so would have been caught, though - and *not* caught at what cost?
You must know that when I say "we test automatically at critical junctures" I'm talking about very different levels of testing from what's being discussed in this thread. Defensive automated testing in highly critical / suspicious areas of code is so commonplace I can't believe you'd conflate it with full-on automated testing - unit testing, scripted run-throughs - which is what everyone here has talked about so far.
AND, I didn't say it didn't fit our development "style". I said it didn't fit our needs or resources. Which are very different things.
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.
And the hundreds of bugs they do catch? You're picking exceptions and saying they prove your rule. They *are* exceptions, though. And putting "QA" in quotes isn't helping me see your side of things, Mike. We can have a reasonable discussion about this, but if you're going to pick or prod it's going to end pretty quickly.
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?
-
ok, i have another question. When I send the file to my opponent and he puts it into his incoming folder he cannot see it in the 'saved games' section of the game :confused:
I am using a MAC and he is on a PC. Should this make a difference? (the file is an .ema)
Thanks
Spillen
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.
-
You are correct about one thing... it's not productive. When it comes to the realities of game programming you don't have a clue what you're talking about. When it comes to DoD contract programming... I don't have a clue. The difference is I'm not telling you what your industry is like, but you are telling me what mine is.
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.
How much experience do you have with game development? Just curious because you are saying you know more about it than I do.
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.
Ask any game developer, and I mean any, if they do automated testing and you'll find the same "baffling" response.
Oh, I see Phil just posted. I guess if my response was baffling, his will be downright insane.
Steve
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.
-
I've written tens - if not hundreds - of thousands of automated tests in industries where legal or technical requirements demanded them. I've also fixed hundreds of bugs in CM. I know that automated testing would catch very few of the bugs that really cause us trouble. I also know that retroactively adding significant levels of automated tests to our existing code base would cripple our ability to expand CM, fix big bugs, and add features.
I can believe that it would cripple your ability.
(And, as an aside, if you think issues like the wandering crew member problem are really that easily boxed in, I think perhaps you need to revisit your assumptions. You're looking at dozens of variables, at best, very few of which are captured in saved games after the fact.)
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.
I don't think Steve is calling anyone a "professor". He's saying that not every development technique - regardless of whether various industries view them as best practices - fits our available development time, or development needs. We do code defensively, we test automatically at critical junctures, we do a very good job on a very complex piece of code, but we have very, very little development time. Certainly not enough to plan and code automated testing for every major piece of code.So you do test automatically after all .. why is that, if it doesn't suit your development style?
I can also tell you with certainty that game companies at our staffing levels where I have acquaintances don't do mass automated testing. Even with larger staffs it's a rarity... they may do it for tools, or critical pieces of code, but they leave the rest to their QA. I suspect it's because QA for games is necessarily more holistic and encompassing than in other disciplines, but don't quote me on that.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.
-
This is most unfortunately. The right thing for me to do at this point would be to walk away from this thread. But when my credibility is attacked I'm compelled to respond.
I'm sorry you feel I'm a 'professor'. I'm a seasoned software engineer who has worked for some of the world's best software companies for 20 years. I have code that I wrote which runs on warships in some parts of the world and extensive amounts of business software that runs the biggest corporates in every major country of the world. Its likely you are indirectly using software I wrote without even realizing it.
I *think* I know a little about software engineering and clearly I am not a professor and I think have proven that I can survive in the real world and understand market pressures.
[calming down]
Like I said its unfortunately that you made such a rash assumption. Certainly you don't have to agree with anything posted here. I just felt that I wanted the record straight regarding my background.
I will not respond to the rest of your comments directly nor replying to this thread any longer since it clearly would not be productive.
Stephen.
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:
-
ok, sorry, i wasn't very clear.
All this happens before I get to set up my troops.
1. I select battle
2. I select a map
3. I select a combat force
4. I select a game option (in this case 2 player e-mail)
5. it asks me for a password
6. I then get the 'save e-mail screen' and it offers a file name.
7. I press ok and then i am back to home page.
There is indeed a file in my out going folder.
am i to understand that before setting up troops or even seeing the map i have to send this file?
Thanks
Spillen
Bingo ...
SCNR
-
Automatically? That could be a disaster. Suppose you had them there to prevent an infantry rush and instead a tank blunders by and they shoot the TC then vacate the position. Now suppose the enemy have the rear of the house in LOF, you are now going to vacate right into an ambush. These kinds of scripted responses to limited tactical issues will likely create more headaches for you than the current behavior.
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.
As to TC exposure. If you send your tank into range of enemy infantry unbuttoned, prepare to pay for it. Just a simple fact of the battlefield. I think all of my opponents know I will definitely take the shot despite the risk. The return is just too good. If I suspect the opportunity is going to arise I may give my unit a pause and then try to bug out after 30 seconds or so but those are my orders, not a TAC AI thing.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.
-
To my mind infantry not trying to take out exposed TCs would be a huge error on the part of the AI. Up until the last patch people were complaining about Brit tankers' vulnerability when unbuttoned. You can't have it both ways, either shooting the TC is an effective way the neuter an oncoming tank or it isn't. Of course if you have an infantry squad sitting within LOF of an enemy tank a mere 140m away don't blame the AI if they die, blame your own generalship. Its prudent to have a good deal of intervening terrain between your infantry and a hostile tank.
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).
-
Well, first off, I never called you or anyone else a cheater. However, the tool you wish to implement is in fact a form of cheating. Since the AI doesn't have the ability to do this, and you would use this LOS tool knowing that it gives you an unfair advantage, then yes, I would consider that cheating.
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.
-
Blood trails and Yeti; aye, that's the holdup...
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.
-
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.
-
Great post and good explanation. But: the comparison between shooting at the HQ and shooting at a jeep clearly show that something is wrong. Looks like there are different algorithms behind shooting at truppen and vehicles. Shooting at troops seems to have a different accuracy. That should be fixed. If that has ramifications elsewhere than those should be fixed in place. But not by fuddling with MG accuracy based on target type.
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.
-
Can you send me the H2HH log from after this happens.
Ta!
GaJ
GaJ,
I've raised a bug report (96_gkbj22cc), the log info is attached to it.
Cheers,
Mike
-
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?
-
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.
).
.
Few problems
in Combat Mission Battle for Normandy
Posted
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