In one sense, canon applies only to fictional storytelling, not design:
Canon, in the context of a fictional universe, comprises those novels, stories, films, etc., that are considered to be genuine or officially sanctioned, and those events, characters, settings, etc., that are considered to have existence within the fictional universe. In order for a setting to appear coherent, especially in fictions that contain multiple parts, both creators and audiences sometimes find it useful to define what has and has not "actually happened" in that universe.
But canon can also be used to apply to design such as films or literature:
Film canon is the limited group of movies that serve as the measuring stick for the highest quality in the genre of film....
The Western canon is a term used to denote a canon of books, and, more widely, music and art, that has been the most influential in shaping Western culture.
The former is the definition that's used to limit guaranteed inclusion of articles in the wiki, which is what we were discussing. Don't try and screw around with word definitions and intentionally use them out of context - I haven't got any patience for that.
Are you saying that design techniques shouldn't take into account technical improvements which reduce limitations?
Volition's technical capabilities (especially when creating FreeSpace 2) exceeded design capabilities, so limitations were imposed to ensure quality. The goal was ensuring thorough testing, and supported by the design theory that simpler is often better. Volition deliberately limited mission designers, but not becasue of technical limitations. So I don't necessarily see the ability to create bigger Battle of Endor missions as a "technical improvement." The SCP's technical improvements are impressive, but now the designers have some need to impose their own self-restraint -- which is why I'm concerned about preserving the BoE warning.
The ability to create bigger Battle of Endor missions isn't really a technical issue anyway, so just because you don't see it as a technical improvement doesn't mean it isn't an improvement.
:V: 's limitations were those of a company working on a deadline, creating a game for mass consumption by gamers on a wide variety of computer systems. They also had a responsibility to make the game work evenly across those systems, so that a wider group of players could play the game. "Simpler is better" in that case, because it's easier to test a simple mission multiple times, and it's also less likely to break a simple mission if you make modifications to the engine.
There are a couple missions in the main Freespace 2 campaign involving the Colossus, "High Noon" and "Their Finest Hour" that people have postulated that :V: would have done differently, and made more fun, if they had been able to. "High Noon" is unusually devoid of any ships except the Colossus and the Sathanas besides a single wing of fighters launched from the Sathanas. In "Their Finest Hour", the Colossus has a complex set of waypoint paths that wasn't removed.
In those cases, "simpler is better" does mean that those missions were playable and (generally) proceed as planned, but it's raised a lot of questions - like why the Colossus hollers about melting down its beam cannons and taking hull damage when the Sathanas can't do a thing to defend itself. Or why the Colossus claims it's making a heroic sacrifice when it's disabled anyway.
There are many bugs and hardcoded limitations in the game that just would've been plain better if they were fixed or made dynamic. But they weren't. :V: was a company working on a deadline - designing overly complex missions would've caused issues further down the line when rebalancing made certain missions too hard or too easy because of tweaking damage values. There's many points in the code where a comment says something like "If you need to bump this, talk to Frank". I've never seen a comment that read "There can only be 130 ships in ships.tbl because anything more would be more likely to cause bad mission design." Current ship limits have more to do with inefficient collision code than anything else.
It's not false logic to attack arguments as circumstantial so long as the person making the argument has not shown proof that there is a clear link between cause and effect.
Perhaps you're misunderstanding logical inferences made in analyzing circumstantial evidence, the inductive process of analogies, and the entirely separate method of establishing causal proof.
I'm also not going to tolerate ignoring my arguments to suggest that I'm ignorant. If you can't refute my arguments directly, I'm not going to buy an
ad hominem abusive either.
Basically, I believe in the objective reality of design that can be taught, demonstrated and proven. WMCoolmon doesn't, prefering a more subjectivist approach that design isn't separate from the "fun" or a determination of what is "good." For example, I think we can objectively prove and achieve a consenus that it isn't good design to put in 12 separate wings of 5 fighters when the capability exists to have 3 wings of fighters with 4 waves each. We can disagree about whether it's more "fun" to have 15 fighters or 60 fighters in play all at the same time, but I'm confident 15 fighters x 4 waves is generally the better design.
One question I always ask myself is why the people in the Freespace universe are so stupid to only send four fighters at once. Observe a typical mission:
Light fighters jump in and are identified as a scouting wing. Alpha wing destroys them.
4 Heavy fighters jump in.
4 Heavy fighters jump in.
4 Heavy fighters jump in.
4 Heavy fighters jump in.
Command or a wingmate reports all hostiles have been destroyed.
I've always wondered why people in the Freespace universe are so stupid to send fighters in piecemeal, where they'll be obviously overwhelmed by the defending forces. And worse yet, they keep doing it - mission after mission! They already sent a scouting wing, they know exactly how many fighters are on patrol and can probably give a good estimate on how long what the defenders are doing is going to take. Why not simply wait until the first two or three wings are ready, and jump in with numerical superiority? Not only is it less suicidal for the pilots and the enemy forces' longevity, as they'll take less casualties that way, they also have a much better chance of victory and will still have at least one wing in reserve that can jump in as soon as its ready and outflank the defenders (Or disable/destroy what they're escorting while they're distracted).
Having fighters jump in like that is one of the biggest weaknesses of the Freespace design mantra. It makes the Shivans much less scary when they're polite enough to only send just enough fighters for Alpha wing to destroy, and they even wait to send the next wing until Alpha one has finished killing the first one. What manners!
So, no, you can't do the same thing with waves of fighters all the time. It gets obvious, it gets repetitive, and it does take away form the suspension of disbelief.
Re: your comments regarding what you think my views are, putting words in my mouth doesn't make me any more receptive to your arguments. Especially when I've described what I would generally consider, using objective terms, to be a good mission.
In terms of coding, we can achieve the same result with 5 lines of code or 50 lines. But I'm confident competent programmers would generally agree that the 5 lines of code is better design, and 50 lines should be used only when necessary. Why would mission design be any different?
Speaking as a competent programmer, one reason might be that you want to avoid code obfuscation. Another might be that you need 45 lines of comments to explain what you're doing in those five lines - unlikely, but still a possibility. Another possibility might be that it's actually faster to do it with 50 lines of code than 5 lines of code - eg a tree search versus a brute force algorithm. Still another might be that the tools required to do it in five lines are inappropriate to the project - eg you'd have to use proprietary code to do it that way. Yet another might be that it's more forward-thinking to do it with 50 lines than with 5 - observe my comments about limits above. Another might be that the design specifications for the project force you to do it in 50 lines "just because".
Each would have the same result. And I'm using result here in a programming context - the function or program would return with the same value(s). But there are many side effects to doing things a different way, much like there are different results.
Whether we ultimately agree about mission design being objective or subjective, I'd like to see some arguments in the wiki about why Battle of Endor missions are "good" -- whether in terms of design or otherwise. Battle of Endor missions can't be considered "good" if no one is able to defend them except by saying "they exist."
If you can't even defend your arguments properly on the forums then your opinion doesn't deserve to be endorsed by the wiki. As you said, "some opinions can be proven better than others". Where I've offered relevant counterpoints and counterexamples to your evidence, you've more often responded with personal attacks.