Free Allegiance Forums

CC had nothing to do with removing the control of a core from any one person but rather providing a way forwards when that person went inactive for a large amount of time. Change doesn't equal balance but if we accept the assumption that genuine balance is virtually impossible in Allegiance (due to the complexity of the game and dynamics of command decisions and community fashion) then change becomes essential to guard against stagnation.

Personally I'd happily go back to A+ given the choice but I accept that it's not been in development and is outdated and more unbalanced now than it was then.

Let's talk process than Spunk.

What can we collect that you feel might give us some relevant base line. TAG appears to pool a hugh amount of data. The file is a little hard for me to get a clear picutre of exactly what is in it. I need to spenmd more tie looking at it. I assume TE parse that into a data base. I could pull those files into a sql data base for parsing as well.

Your thoughts...

Just a model I cooked up right now, probably could use a lot of improvement, and I'm not sure if it'd be meaningful at all.

*Random rock distribution is a problem per game, but not a problem over the long term, since the game attempts to screw over everyone equally.
*Game settings/maps are a problem, because morons don't screw themselves over randomly but in rather consistent patterns
*Team balance is a problem, but we should be able to get some signal out of the data if we close our eyes and chant "trueskill works, and commander rankings are accurate". Big assumption, but hey, otherwise you'll have to scrap the whole idea as stacking is definitely not random.
*Balancing also needs to include tech choices, so these pieces of information are important:
-Which tech did the team first get?
-Was that tech upgraded before a second tech was purchased?
-Was the second tech upgraded? If so did the game last sufficiently long after the upgrade?
These questions should answer if the team was tacspansion, pure exp, supyard etc.

So you collect this data, apply some arbitrary weighing factors for team balance and game settings, and get enough samples to reach a high enough confidence interval given the std. dev..... eh you may be able to claim the data has some validity.

Now.. assuming cores are released frequently (frequent releases and incremental development is a good idea) how do you get enough samples between releases? Don't see that happening. Then the next core changes something you are trying to measure, poof... back to square one.

Hi Cable,

I believe that RT had a tool called core2xml that you could use to move a core into an XML format that you should then be able to import into a database. (Maybe that was core2text?) I know I've seen it mentioned around on the forums, maybe that could help?

I used part of TE's stuff from TEK to make my core mapper, it uses the core file directly (no database).

ACSS will have the type of statistical data that Spunky is looking for, including a complete track of every event in the game that TAG picks up. I believe that the current FAZDB contains this info as well, but getting access to that data would be something that TE would have to setup for you to get analysis from.

Just to throw this out there, it would be very cool to track data such as how much money each team made, and how they made it.

Adept wrote:QUOTE (Adept @ Feb 4 2011, 04:09 PM) Just to throw this out there, it would be very cool to track data such as how much money each team made, and how they made it.

That would require constant connectivity to TAG, or really detailed records, would it not?

It could be possible to record the income, not how it was made though.

For more detail you would need to do Datamining like that guy Datamine did.

HSharp wrote:QUOTE (HSharp @ Feb 4 2011, 04:24 PM) It could be possible to record the income, not how it was made though.

For more detail you would need to do Datamining like that guy Datamine did.

I'm pretty sure Imago was writing a really detailed stat collection utility that recorded every event sent to the server. So theoretically we could collect all of this info if it was implemented.

As an aside... It's actually possible to uncover a lot of issues by simply looking at the core. For example, it doesn't take a genius to realize when TF ships have a big acceleration bonus and a lot less mass, there is probably a problem there. Then you remember Veg designed this when the acceleration bug esisted, and there is your a-ha! moment. Since Allegiance DOES have a norm for pretty much everything, any deviaton from the norm must have a corresponding penalty elsewhere to keep things in balance. If one side of that equation is missing, then there is cause to investigate.

Conversely, a lot of players who have never looked at the core have no idea some of these issues exist, just like some issues are visible to the commander but not to the non-commander. Your average player sees the Dreg 25% price hike, for example. He doesn't necessarily understand the 35% yield bonus - and that's relatively a very obvious issue.

RealPandemonium wrote:QUOTE (RealPandemonium @ Feb 5 2011, 01:30 AM) I'm pretty sure Imago was writing a really detailed stat collection utility that recorded every event sent to the server. So theoretically we could collect all of this info if it was implemented.

I think you're right, that's probably what I was thinking.