Fire in buildings???

[Magpie_Oz]

I think this would be an oversimplification of things. Just the conversion from borg spotting to relative spotting would make keeping the same file formats very impractical.

Sure, but I am suggesting that the "rules" of the game are more or less fixed. Revisions of the game engine would only be to model things not previously included but the modules are structured in such a way that changes to the game engine do not affect them.

In essence the base game is the processing part and the modules are more or less just databases ?

So if you decide to add fire to the game you can do so by revising the game engine but the modules will still work the same.

[Lt Belenko]

It has always irked me a bit that I can have a single program for work (AutoCAD) that lasts for in excess of 20 years and a file from 1990 I can open today with the 2010 version but the games industry is very much "disposable".

AutoCad $3995 CM $50 to $70 (s&h) Wow! I could get 57 games/modules of CM while still using that 20 year old version of AutoCad.

As for compatibility between modules I'd like to see "US - Remagan to the Elbe" compatible with "USSR - Seelow Heights to the Reich Chancellery" so that Patton could meet Zhukov.

[stikkypixie]

Sure, but I am suggesting that the "rules" of the game are more or less fixed. Revisions of the game engine would only be to model things not previously included but the modules are structured in such a way that changes to the game engine do not affect them.

In essence the base game is the processing part and the modules are more or less just databases ?

So if you decide to add fire to the game you can do so by revising the game engine but the modules will still work the same.

Not always. Say for example that they implement tank riders for the war in Russia. To do this properly all tank models need to have locations on the polygon designated where the little guys can sit.

If you limit this only to the East front game, you only have to do this for the Russian tanks and whatever the Germans had at the time. If you keep the base game with unlimited add-ons, you would have to do this for all the tanks before as well. Maybe to pull off a convincing animation of getting on and off of tanks you would need more joints in the soldier models. This would create a lot of additional work, especially if the features come in later modules and without any gain to BFC (and for some reason that's important ).

Keeping things compatible can be a major pain. Comparing it with CAD files or text files is not accurate I feel.

[poesel]

It has always irked me a bit that I can have a single program for work (AutoCAD) that lasts for in excess of 20 years and a file from 1990 I can open today with the 2010 version but the games industry is very much "disposable".

To use your analogy: CMx2 is to CMx1 is what Inventor is to AutoCAD (same company, better graphics). Inventor can not open dxf files (well, you can but it is as useful as importing screenshots from CMBO into CMBN).

IMHO this comparison of yours is not valid.

[sburke]

To use your analogy: CMx2 is to CMx1 is what Inventor is to AutoCAD (same company, better graphics). Inventor can not open dxf files (well, you can but it is as useful as importing screenshots from CMBO into CMBN).

IMHO this comparison of yours is not valid.

CAD fight! CAD fight!!

Sorry I just couldn't resist.

[Mord]

So for Battlefront that would mean we would pay $60 at the start and maybe $5 - 6 each year for the upgrades.

Sounds like a good way to go out of business...fast.

Mord.

[dan/california]

I have said several times that they should just go to a monthly subscription model at what ever price makes their end work out. Steve seemed less than fond of the idea as it happenns. They are quite wedded to their business model, and as long as they keep turning out product I will keep buying it.

While we are trying to run their business for them, I would like to reiterate my plea for them to merge with the "Theater of War" guys. They already have some sort of relationship obviously. That would allow them too start turning things out two or three times more quickly. I am not holding my breadth on that one either though.

[Aldaros]

From a coding perspective, breaking the releases apart is a huge plus. Whenever BFC gets to a new release, they are completely free to change whatever they want. I think any software programmer would agree that, with hindsight, they would always have designed/written some part of their code differently. By periodically breaking backwards compatibility, BFC can make major changes much faster.

[Aldaros]

(Fair warning, here coming a long-winded example of why this is true; please feel free to skip to the last paragraph, or the next post, if you just don't care.)

BFC has mentioned are already limitations due to the relationship between squads and teams in the game. So let's say that, as an imaginary future CM programmer, I decide I want to modify the squad/team/soldier objects for version 2; maybe we want a unified squad to spread out a lot more, not be bunched up all the time (sidebar, I've only played the CM:SF dome briefly, so this example is more from a CMx1 perspective of command). Anyway, as part of this change, we now want three levels of being "in command;" near an officer, near an NCO, and completely out of command (the old were near an officer or out of command). So I decide that, while storing leader info in the squad used to be a good idea, that just won't work any more, since one squad may have a different leader status per member. I really want to manage it for each soldier individually, but I don't have the CPU cycles to constantly update that data for everyone, so I'll just store it with every team, and share that between team members. It's a lot faster, and it's still better than what we had in version 1. Now, to handle old saves, I have to include some extra logic that says, if this is version one, get leader data from the squad section in the save file; version two, just get it from the team section with everything else.

Now, a few years later, I finally get those CPU cycles, and by God I'm going to model it properly in the new version 3. So I move leader info into every soldier. If I don't have to support old saves, I'm done; maybe I'll go ahead and start working on aircraft physics, so we can draw them and fire AA at them.

But if I support everything since the beginning, I now have to handle three possibilities whenever I load a file. And then what if Bob changed the squad object entirely two years ago in version 2.5, for some other improvement, say ad-hoc squads? Maybe we don't distinguish between squads and teams anymore, since we're doing so much processing at the level of the individual soldier now (things we just couldn't afford to do back then, even though we wanted to). So I have to keep track of what the original squad looked like (along with any intermediate versions), and be prepared to build a new set of units out of the appropriate old unit type, for any old saves I run across. And of course I have to test this for all possible combinations of save files, because I don't want to break things for some poor guy with an ancient save file or scenario he loves replaying. And that's not even worrying about things like making sure I never accidentally use an old squad in place of a newer one, or vice versa (say in my compatibility code).

Again, completely hypothetical example, but that's the sort of stuff BFC would have to deal with. It's entirely solvable, but it's not fun, it cuts into time spent on interesting new features, and whenever something new changes, the extra work load increases (sometimes exponentially). The question comes down to, which is worth more; major new features, or being able to load old files? Autodesk and Microsoft can afford to pay for both, BFC probably can't, even if they wanted to.

Anyway, that's my 2 cents (or 4 cents, as the case may be).

[Magpie_Oz]

Sounds like a good way to go out of business...fast.

I disagree because at the moment BFC gets $60 out of me every 10 years, under a subscription model they would get money of of me every year AND I am pretty much bound to them for my investment.

I am also not necessarily saying we need to have total backwards compatibility what I am asking is that is it possible from not only a coding perspective but also a business perspective to have the product undergo a series of evolutions rather than total replacement every 10 years.

My thought is that if the upgrading and addition of new features is done bit by bit over many years you more or less have the total game all of the time but its functionality is growing and expanding as new features are added. So if you add the aeroplane bit then each of your modules gets an upgrade as well. I for one would be more than happy to pay for an on going system that grows over time, especially if it means some of the less popular armies and theatres can be modelled.

[stikkypixie]

I disagree because at the moment BFC gets $60 out of me every 10 years, under a subscription model they would get money of of me every year AND I am pretty much bound to them for my investment.

I am also not necessarily saying we need to have total backwards compatibility what I am asking is that is it possible from not only a coding perspective but also a business perspective to have the product undergo a series of evolutions rather than total replacement every 10 years.

My thought is that if the upgrading and addition of new features is done bit by bit over many years you more or less have the total game all of the time but its functionality is growing and expanding as new features are added. So if you add the aeroplane bit then each of your modules gets an upgrade as well. I for one would be more than happy to pay for an on going system that grows over time, especially if it means some of the less popular armies and theatres can be modelled.

How are you going to achieve this if things are not made backwards compatible?

[Magpie_Oz]

How are you going to achieve this if things are not made backwards compatible?

I have no idea, I am not a programmer but what I am suggesting that each new thing that gets introduced into the game set is incrementally upgraded across the modules.

As you are not making major changes each time I am thinking that such a progressive upgrading should be possible.

So once you have the complete set, in 5 years time for example, further releases will upgrade each module and the base to incorporate the new features.

[stikkypixie]

I have no idea, I am not a programmer but what I am suggesting that each new thing that gets introduced into the game set is incrementally upgraded across the modules.

As you are not making major changes each time I am thinking that such a progressive upgrading should be possible.

So once you have the complete set, in 5 years time for example, further releases will upgrade each module and the base to incorporate the new features.

Even incremental features need to made available to older modules otherwise they will not work together or only the features they have in common will work together (even that is questionable). Older modules don't know what is available in the modules, units defined in the older modules may not have the information/attributes required to function with new features. It doesn't matter if the change is incremental or with leaps and bounds, you still have to go back and change all the older modules.

[Magpie_Oz]

Even incremental features need to made available to older modules otherwise they will not work together or only the features they have in common will work together (even that is questionable). Older modules don't know what is available in the modules, units defined in the older modules may not have the information/attributes required to function with new features. It doesn't matter if the change is incremental or with leaps and bounds, you still have to go back and change all the older modules.

Which is what "the game set is incrementally upgraded across the modules" means.

[stikkypixie]

Which is what "the game set is incrementally upgraded across the modules" means.

True . Still very impracticable no matter how you want to call it.

[Cymru]

My experience, in other programming circumstances, is that incremental changes get increasingly complex and buggy. Eventually the better solution is a complete break, even if it means lack of backward compatibility.

[Wodin]

I'd never pay a subscription fee for any game period...don't care how good it was...they'd lose my business instantly...

Also those who don't have bank accounts\credit cards are screwed...and don't say eberyone has these days as it's not true..I've only just got a bank account and a debit card...before that I had a Post Office account and you don't get a direct debit facility nor a debit\credit card...my prevoius online pruchses where done by a family member who i gave the money to...

Subscription sucks big time...worse idea I've heard of on here ...thank god BF make modules...

Merging with the ToW lot would be bad news aswell...nothing in those games comes close to CMSF style of play...I really dislike them...really don't think they need anyon...more like others developers would need their expertise.

BF are happy with their business model and it works...they managed to keep going for three or so years through CMSF which will be no hwere near as popular as WW2 games...

As for the poster saying they will throw all the games away to once CMx3 comes out by the time that happens you'd have well had your moneys worth. CMx3 is probably at least 10 years away....and anyway that happens with most games doesn't it? No1 gets played and then 2 comes out and No1 stop being played.