Free Allegiance Forums

Well I strongly support some points and strongly disagree with others. Starting off, my first major problem, as said by others, is that you are throwing all these things into the "community core" discussion. It needs its own thread.

Community Core
I *strongly* agree with the idea of a community core, though I will define what I see a community core as. However there is unfortunately a good chance of things going to hell IF the community core is not Noir's. If we get everything set up for a community core and no one chooses to play it, it would just be a waste of time.

Now onto details I feel are necessary for the community core... The core devs of the major cores are polled, asking if they will allow their core to be the community core and agree to some guidelines. Those who agree to those guidelines will have their core's placed into an ASGS poll to be voted on. Whichever core wins will be the new community core. The core dev will remain the lead core dev so long as he follows the guidelines, but a couple others will be selected who have the power to make core changes as necessary.

The core dev agrees that the core no longer belongs to him, but to the Allegiance community. I don't think anyone can really say their core "belongs" to them but it is not fair to take over someone else's core unless he willingly hands it over or goes very inactive/leaves the community. Any member of the community is able to take the community core and use it as a starting point to work on their own unofficial cores. The core dev must collaborate with others. We'd probably need a senate like structure set up again to handle this (but twice as large or so). While we want community involvement, directly involving everyone is not feasible. They will need elected representatives. The senate will discuss what changes need to be made and formulate proposals for updates. If the proposal passes a 2/3 vote, the changes go in. If not, the proposal is tweaked until 2/3 of the members and the core dev approve. The core dev would preferably be the one to finalize proposals, but he must attempt to follow the desires of most of the elected members or be ousted. He could have veto power which would mean the proposal has to be voted on again and if the vote must be 3/4 or so to override the veto.

Stats would ONLY be recorded on the community core and ONLY recorded if autobalance is enabled. However community core ranks will show and work for balancing purposes if desired on other cores.

Squad games will obviously be played on whatever core is decided upon by the squads before they play. Some cores will mostly be left as "squad game cores." @Cadet and ACS should focus on the community core but provide important information about the other cores when necessary.

*Benefits*Training docs and programs can be MUCH more detailed and accurate since they don't need to be aware of multiple coresWe have an official community core which is the work of multiple peopleUpdates can be made more frequentlyEasy place to start if someone wants to work on their own coreNo copyright stuff*Disadvantages*Training docs may need to be updated more frequently (and may need to be rewritten right away)It simply won't work if people don't play on itHiders
Hiders certainly need to stay. But changes to the system would be welcome. Make a boot kick you to the lobby only and any commander has to accept you again to rejoin a game. You could possibly have a time limit between when someone can log out on one callsign and when he can log in with another.

Autobalance
Somewhat stated above. It's just plain silly to allow any games without autobalance on to count. It defeats the whole purpose of the system. Unbalanced games will not produce balanced ranks. Autobalanced games over time will lead to a fairly respectable balancing system.

DN is fine (somehow or other), but the current status is unacceptable (see release dates of 04.45/04.50/04.60a). The whole community is playing every day on a known "broken/inbalanced core" and nobody is there to fix it (eg Carrier rush in general, Giga Pattie/Carrier rush, BIOS GS/Carrier rush, TF nerf, aso).

AEM wrote:QUOTE (AEM @ Jul 3 2007, 04:31 PM) We'd probably need a senate like structure set up again to handle this (but twice as large or so). While we want community involvement, directly involving everyone is not feasible. They will need elected representatives. The senate will discuss what changes need to be made and formulate proposals for updates. If the proposal passes a 2/3 vote, the changes go in. If not, the proposal is tweaked until 2/3 of the members and the core dev approve. The core dev would preferably be the one to finalize proposals, but he must attempt to follow the desires of most of the elected members or be ousted. He could have veto power which would mean the proposal has to be voted on again and if the vote must be 3/4 or so to override the veto.

The Zone Lead has already replaced that suggestion. Either a New ZL position would be appointed by the Admins or Dogbones would appoint (with admin approval) a group (and person in charge) to run the core development. We have an existing structure in place for this. Huge committees are what we just got rid of for valid reasons. I know I can guarantee that however it would happen, that a good cross representation of people would be involved. Again, the core would have it's own forum for ALL to weigh in on issues.


Otherwise good points AEM.

I personally like an idea that was suggested by FlingPu, what if Noir was the Community Core ZL?

He would have to post up if he would like to be considered for it I would think? But willing to work with a group who would have a say in what goes in it too.

If you want to have a core ZL, that is fine. Have a ZL who performs the administrative duties but does not necessarily need to work on the core. He mostly keeps watch on what is going on. Have 2 or so assistant zone leaders capable of modifying the core and also supervising. But have the core dev whose core is used as the starting point to play a prominent role in the decision making, until when and if he is ever deemed an obstacle to the community core's development. The assistants, core dev, and the ZL if knowledgeable about cores can implement the agreed upon changes.

The ZL with recommendations from assistants can make a decent sized group, maybe around 20, to discuss and vote on proposals. The ZL and assistants can gather the feedback from the forum and post ideas to the private forum. They can take a quick vote to see if they are worthy of consideration to be included in the next release. Every month or two these ideas can be brought together and discussed more in depth and statistics since the last release analyzed to see what exactly should be changed in the next update.

The ZL has the power to call for an immediate change if there is a major bug or balance issue after a new update which the rest of the appointed members can discuss and tweak as necessary asap after a fixed core is pushed out. The ZL would technically have the final say in core changes but it is expected that he follow the agreed upon changes and if there is trouble a new ZL would need to be appointed.

With the recent transfer of power from Senate to ZL's, the ZL's were mostly leading that area already. The only leader really capable of becoming the community core ZL from that angle is the core dev whose core is chosen for the community core. But I think that is too much just making one core the official core rather than making a "community core." IMO someone else other than the core dev should watch over the new zone.

Ugh. Large senate groups (anything 8 or more IMO) are a bad idea. It'll take forever to get a decision made. I think a Core Zone group should follow the pattern of how alot of open source software is done (i.e. Java). IMO, there should be a small group (3-5 people) of Core developers who know what they're doing, get along well, and have different approaches towards the core. Anybody/everybody can lobby the small group, but they can discuss internally what is good/bad and also make decisions on their own on the trivial matters. Contentious features/areas/issues should be put up for a vote by the community to determine the general desire of how it should be implemented.

An interesting option is how the Java developers at Sun have a "bug parade" for the community. To extrapolate the same concept for Alleg, a bug/feature tracking system would be set up so that any player can log changes or features they want to see. Players can also vote for particular changes to give the weight to help determine what issues should be addressed first. Changes that few want would be basically ignored. Perhaps it should be made so that only Vets or certain people are allowed to make such votes. Just an idea... probably overkill but it's interesting food for thought.

I'm in favour of a community core but not autobalance

I think we all know that autobalance is just plain wrong. There are vets with zero or 1 and newbs with 21... AB just doesn't work and I do not know what the solution is or what the right ranking solution is either.

End of the day KGJV is spot on that it's about the name of the players you get to know over time.

I mostly say a larger group because inactivity may be a problem. If there is a small group and people aren't active and contribute then things can go bad. With my model, it is up to the ZL and assistants to keep things moving at a swift pace. They will put up items for voting. If people don't vote in a given time frame, they just don't have a say in the matter. I suppose 10 + ZL + 2 AZL + Core Dev would be plenty large enough as long as they remain mostly active.

A Core worked on by the community, for the community! I quite like that idea, It will balance itself, as a single core developer has preferance, everyone does, and this leads to imbalance and "Cheese"

I reccomend that in this core GT loses its Reaserch Station, Nix looses its trans+aslt and can be nanned again.

On the issue of Learning Curves i think we should work on a single player side to the game, for noobies to learn in! Where a player can command/fly against a team of AI bots.