Code GPL Modus Operandi

Rman: "OSS" Dev. & "MODs" to

 * Many have only known "MOD" here because that is all that was possible till recently.


 * "OSS" is a different MO.


 * Here's how I percieve the diffs: Heurisms *


 * Adding FUNCTIONALITY to the Code Base


 * Adding New Play Content to the Game


 * BOTH are desirable.


 * In OOS Dev Structure & Protocol that distinction is made & accomodated.


 * The BerliOS repository & apparatus will make it a whole lot easier to make distinctions & accomodate all foward progress without the need for a managed hierarchical team org. with all it's inherent pitfalls of turf & power.

Rman: The Diff That Makes A Diff in MOs

 * Different Mind-sets Intergrated


 * These are the differences in POV or Mind-sets that are directly manifest in Modus-Operandi that range from dysfunctional to functional.


 * They also result in collective experience that feels positive & progressive OR frustrating & futile.


 * Personally my vantage is to take the long-view, try not to lose sight of the forest just cause I'm so focused on a couple trees that I especially like.


 * The approach thru "BerliOS" will be a boon for the whole Wz community - not just now but for years to come.


 * That is the diff that makes the diff to longevity & progress through a process that is integral, inclusive & generative.


 * Here are some key distinctions & possibly the basis of protocols:


 * 1.) "Lego" Modularization, externalizing as much as possible from the core engine & doing so to not only facilitate diversity of "MODs" but also "PORTABILITY".


 * 2.) "Pumpkin" Patch MO


 * 3.) "Base Functionality"


 * # 1 is LONG-Range Goal


 * # 2 is SHORT-Term MO based on # 3


 * #3 NEEDS to be THOROUGHLY defined & cataloged.

* # 1 - # 3 are components of an inclusive OSS Development worth articulating for a better, clearer, grasp of both short-term & longer-term aspirations.


 * It is about taking the WHY ? of consensus & translating that into a vessel of HOW ? that affords the widest concievable range for WHAT ?


 * Metaphorically it is like taking an original "Fresco" painting..... Re-creating it in "Oil" & saying....


 * "You like to paint - here is something you can work with, paint over, whatever.


 * Also - there will be 10, 000 other peeps doing the same over the next couple years...


 * Oh, & by the way, preserving the essence of the original "Fresco" is something that matters to everyone..."

Rman on POVs

 * BSR = Before Source Release


 * ASR = After Source Release


 * These are "Worlds" or "World Views".


 * They are NOT the same.


 * "BSR" = Tiny world - insular.


 * "ASR" = The sky's the limit - potential audience cannot be pre-quantified or pre-judged.


 * But what can be anticipated & reflected in the present MO is:


 * Afford the greatest diversity of "Content" without pre-defining anything but the base for "infintite variety" and easy upgrading of technological benchmarks accross multiple hardware platforms.


 * In the "ASR" world - we from the "BSR" world must respect the possibilities that will draw those to WarZone for the first time this year, next year... And on & on....


 * That is the main reason, IMO, to distinguish "MODs" from "Base Code Functionality ReDev"........ as much as possible.


 * To assume that we from "BSR" are able to anticipate all "ASR" WZ RTS tastes forevermore is an omniscience we need not & should not assume beyond the base that will support diversity.

Troman on Code-base POV

 * Kage, answering to you post, it's impossible to implement gates without changing the source. The gates are in a wdg file (ie a MOD) but gate functionality had to be added to the source.


 * This enables any other modder to add his own gates (another model etc), using the functionality since it is separated from the gate itself.

Kage on Code-base POV

 * what i was saying was along these lines. i am wholly against anything that would force something into "warzone 2100" the game - for example, adding gates that are available to build whether you want them to or not.


 * i am aware that there is currently nothing in the engine which supports new functionality of that sort through scripting, and i agree that you'd need to touch the source to do it.


 * from what i read so far, it seems you took the best approach - that is, adding functionality to warzone, but not enabling gates by default - someone would have to package the models and change some of the data files to enable gate structures.


 * i'll summarize the above.


 * if you, for example, added support for multiple weapons on a unit, but hardcoded it in so that if you played the original campaign, and were able to add multiple weapons to each vehicle, then it would go against what i believe in, not to mention it'd break one of the dev team's cardinal rules.


 * however, if you added multiple weapon functionality by modifying the source to the point where someone could add multiple weapon support by just changing some data files inside a wdg, without giving all existing gameplay multiple weapons by default, then it would be perfectly acceptable according to dev team rules.

Chojun on Code-base POV

 * ........we seek to preserve existing gameplay, while improving it by re-developing its internal source code.


 * To clarify:


 * We won't be adding nukes or time-travel machines into the game;


 * we will instead make it possible for 3rd party developers to add these to the game as external mods.


 * We, as RTS.net development group, will try to make it possible for such mods to be created.

More Kage on Code-base Functionality

 * ...we know that the current warzone campaign and game as a whole works very well in 1.10 - i haven't heard many complaints with balancing or gameplay.


 * if we were to add a whole bunch of stuff with the new patch, it might fall out from under us, and be unpopular, which is something we couldn't take.


 * that's the sort of thing that happened with 1.11 - a lot of stuff was put in that just didn't come out all too well.


 * thus we should code in functionality for any possible anything someone would want to throw in the game, but make so that those functionalities may only be explored in the form of a mod.


 * same goes for gates - put all the code that will make it functional in the source, then just make it so you can change the structure info to add a gate to be available for construction.


 * if gates don't fly well with the public, no prob, they can just delete the mod, otherwise, people will keep the mod, same with any mod.