It's future is half-assed patches (quoting BearFlag)
Gee, he's practically a cheerleader. But be sure and carp Matrix about getting Ralph back to work on the next half-assed patch we're all waiting on.
So that's what it comes to Curtis? Snide sarcasm derived from a quote stripped of context? Connecting me, to "half-assed," to
Ralph when I said nothing of the sort. That's low technique and apparently mean-spirited.
That quote was, and was clearly, a prognostication predicated on no less than four conditions, two of which you have expressed yourself. The other two, highly contentious I'm sure, were "risk" (business risk) and "vision" (a creative frontier). In the very next paragraph, please note, I talk of ways to avoid that future. It's not quite so inflammatory and negative in proper context, is it?
You pulled the same trick with "Add some new scenery, some new scenarios and some new equipment and re-release it" which was written, and meant to be, reductionist. The greater context however is found in repeated references (without condemnation) to marketing models - including a forty year old model for which you grope to justify excluding TOAW. The first wargame I can remember that established this precedent was PanzerBlitz (but there may be something older). I didn't invent the model and ToAW is certainly not exempt from it based on 'big changes' which were coincidentally attended by an equipment expansion, a topical subtitle and scenarios to match. We could argue endlessly and fruitlessly over what dividing line separates a "new" game from a new release, re-release or expansion. But such ambiguity doesn't negate the manifest pattern or that that pattern is found very clearly in TOAW releases.
If you don't like what I have to say, that's fine. Make a case against it. But stick to what I said rather than cherry-picking for quick and contextless gotcha's. Have you noticed, Curtis, that the common denominator in two sidebars is you?
It is ironic that you use the word "cheerleader" even while you defend in absentia others. I am not unsympathetic to the fact that you are the chargé d'affaires and yet nearly as much in the dark as the rest of us. But you may want to listen to that "fanbase" you so readily cite. When I joined in, I expected hornets and pitchforks and they have arrived. But the hornets (over a hundred) flew off to sign Klink's petition and the only pitchfork is yours.
I have a theory that you just don't like my screen name because our flag is so much cooler than that Lone Star thing.
=========================back to topic
Michael H raised the heretical idea of an open source project. And Curtis mentioned that TakeTwo owns the game and so the legalities are likely more complex than us mere players can know. Obviously, Matrix will not/cannot release the source though a cooperative development model may still be possible. We are left to speculate on such possibilities from ignorance as the background arrangements remain close-hold.
A long while ago on this or another forum, a player suggested that the TOAW community should band together and buy the game outright. Everything has a price, the only question being what price. In such a case, the game would (probably) become open source and would be managed by the Buyout Foundation's board. A variant of the same idea might be a foundation/Matrix partnership with the same goal with the result being a hybrid commercial/community-owned game. Complicated, but possible with enough fine print? I dunno. But Oberst_Klink demonstrates there's a healthy number of people who care enough to sign a petition. Would they also be willing to offer $25, $50 or $100 to a Buyout Foundation?
One of my basic proposals is that TOAW occupies a unique niche. It's fair to say that a program would not survive 14 years if that was not the case. This signals opportunity and vulnerability. If the program does not evolve to the potential of that niche, it will be replaced. Soon or later. TOAW has survived so long because it is a great game, but also because it has no competition. Such a replacement could hail from the dark basement or, as Michael H hints, from an open source project. I would not get my hopes up on an open source approach though. That development model indeed ~can be~ powerful and yield very impressive, very quick results. But getting past the startup hump is exceedingly difficult.
If we were to define, as exactly as possible, what that niche is then we should see what TOAW presently is in relation to the niche potential. The niche is a game (not just scenario) design system which faithfully preserves classic, operational wargaming covering the modern era. There's more, but that is the brief. From this hypothetical niche we can say a couple of things:
1) there's really no system that fills it
2) TOAW hands-down comes the closest
To me, this strongly suggests the overall direction should be towards "a game design system" with an accompanying empowerment of the 'scenario' designer. I believe the clamorings of scenario designers and players alike have for years been suggesting the same thing. Work on the underlying combat engine is all well and good but how many players really care if a T34 is being virtually pitted against a PzIV - particularly when such details have no direct visibilty? Generally, loss results and the knowledge that reasonable calculations have been made are satisfactory to most. At any rate, a new direction in devlopment doesn't preclude continued refinement of the engine.
Curtis Lemay has rightly pointed out that some of the proposed changes have big price/time tags on them. That means a lot of screen time with Visual C. But the game is getting very little of that time now and ways to improve it without heavy cost to Matrix have been proposed. However, not all such changes are so daunting in their time demand. For example, more exclusion zones have been coveted for a decade. That this relatively simple change has not been added demonstrates to me that development direction has not emphasized those very aspects which place TOAW in a unique niche.
(Exclusion zone is probably stored as a 2-bit element in struct MapHex (or whatever). Changing that part is easy as long as the program is properly handling dynamic allocations. There would then be a couple of dozen points where the presence of EZ is tested for. Those would have to be updated. The editor UI would have to be updated. There are possible ramifications in other parts of the program, for example file storage format and backwards compatibility. Sounds like a lot but given that EZs don't have further complicating attributes, this should not be a big change.)
Who wants 15 non-overlapping exclusion zones or 4 overlapping?? (4-bit)
Or how about 255/8 ?
< Message edited by BearFlag -- 12/21/2012 7:11:48 AM >