FYI making the player drive the price back down does not make the auction take less time ............ but I understand your point.

True.  On that note, though; if that player doesn't escape the auction before the time runs out, then they are stuck paying for the plot (for presumably more then they would have paid otherwise) leaving them with less money to try the same trick on subsequent auctions.

Likewise, even if they are wasting time pulling the auction back, once it enters reasonable territory again serious bidders can re-enter the auction.  When the tactic no longer guarantees success in denying others the plot, its use will correspondingly drop off.

The auctions then, while not a perfect mechanical match to the original game, are much truer to what I believe to be the original intentions and purpose of the auction.  But that is obviously a bit of subjective hair-splitting, as your next point mentions:

Keep in mind we are in the Feedback and Suggestions forum, not the Gameplay Ideas forum

Sorry, I hadn't noticed the distinction within the sticky: most of us no doubt thought that our Feedback on the Auction issue and Suggestions on how to address it would fit in this category.   

Regardless, I shall henceforth abide the will-of-MOD. 

I believe that both Player events (good and bad) and Player-targeted Production events should be suppressed for the first round.  Anything that happens here is utterly unfair and un-fun.

After that, no, messing with the winning players is completely fair and valid.  Frustrating, sure, if you are first or second, but the Random Number Generator is a harsh master and sometimes demands its due. 

I concur, leave it random. 

Refresh my memory; random events are suppressed for the first round, correct?  In such a case, the only thing first round rank applies to is land selection tie-breaking and auction sale priority.  Not small things by any measure, of course, but with it random sometimes you'll be ahead, sometimes you'll be behind, and it'll work out in the end.

There are many elements of sabotage in this game.  If you don't like sabotage, you don't have to play.

The fundamental sin here is that the other acts of sabotage don't slow the game down nearly as much as the auction exploit tends to.

When 3 plots of land are auctioned, and the same player runs down the clock driving all three up to $5000 just to make sure no one gets any, that tedium is inflicted upon every other player who would just like to get on the with the game, thank you very much.

If you call them on it, they generally just giggle and say that's how the game is played.  Well, okay,  but it isn't doing the game any favours.

Having the top bidder have to walk their bid back down to the starting price before leaving the field really makes the most sense and will improve the game experience dramatically.  What we've got now is tedious, and makes me cringe whenever a land auction comes up, because I know chances are good the round will take twice as long and no one is likely to get anything out of it anyway.

I've thought more about the proposal and, while I understand the desire to rank by percentile, intuitively it isn't the most striaghtforward system for people to understand.  

I think the current system isn't bad... it is understandable enough that #of wins = highest rank, with other metrics for tie-breaking.  I do concur that it is disappointing that coming in second is the same as coming in last.

Personally, if I were designing the thing, this is what I would do... what are your thoughts?

 - Players are ranked by victory points: most points wins.  Victory points are earned by scoring higher in a game then another human player in the game.  So, in a 4 human game, winning gets you 3 points, second gets you 2, and third gets you 1.  In a 2 human, 2 AI game, the winner only gains 1 point.

 - If one wants to further increase the competitiveness at the loss of simplicity, one could add a few tweaks to the above:  Winning might always grant an additional +1 on top of the rest so as to increase the benefit of true victory.  You might also gain an additional point for every player you defeat who was ranked higher then you.  (So the #2 player beating the #1 player gets more benefit then the #1 player beating the #2).  

 - I would never take points away... the complaints to such events would overwhelm these boards without a doubt... though it would be tempting to put some manner of penalty on Abandons.  Again, the potential for complaint is too high, so I would favour leaving such situations out.

The relatively straightforward Victory Point method simplifies greatly any talk of "weighted averages", I think, while still giving people *some* progress from playing a good game but not quite winning.

The one issue is that you do get a situation where one who plays many games marginally can out-rank one who plays now and then but consistently wins.  I can certainly see how people would dislike that aspect.

Whad'ya think, rommager?

Thoughts:

- Does your Number of Games played refer to the number of games Finished (so disregarding Abandoned) or the total joined (Finished + Abandoned)?

- Why is the Number of Games three times more powerful then the Game Ranking; namely, why is the number of games so much more important to determine one's rank then whether one *won* those games?

- Why do we care about Colony Score when determining rank?  Player Score, sure, but Colony Score doesn't really reflect on the player in particular.  It would make higher ranked players loathe to play with beginners, as they would bring their rank down due to poorer overall performance.  Now the Percent of Colony makes sense, as it still reflects overall prowess compared to one's competition.  But if we just use that, correspondingly experienced players would *only* want to play lower ranked, so that they dominate that much more.  I personally would leave Colony Score factors out of the equation.

- Very much approve of factoring in AI player quantity in determining the strength of the win.  

Edited for typos...

I like this idea. 

Being able to sort the names by who is waiting, or sort by rank, would likewise help here.

Ahh, I hadn't noticed the update on the main page.  Thank you Govt Mule, I appreciate being so enlightened. 

I am curious... is there a reason why the "Games Played" statistic appears to actually only show "Games Finished"?  It appears one's "Ratio" can be artificially high by simply abandoning any game you aren't likely to win.

For example, I've seen one profile that has Played: 24, Won: 14, Abandoned: 20, for a ratio of 58%.  From those numbers I would think Played would actually be (24+20)= 40, for a ratio of 35%.

Its certainly not a huge issue, but if this is in fact the criteria expected, re-labeling the field to "Games Finished" would make it more clear, I think.

Again not a big deal, just curious. 

Chalk me up as another guy who would love to be playing but can't due to the 1.2.2 bugs.   

Hmm... I was really hoping JRE 1.6 was all that would be required.  Guess not.

Thanks for testing that, C64!

For reference, my present Mac JRE version is:

1.5.0_19

I am using Mac OS 10.4.11

I see there is a Java 1.6 update, but only for Mac OS 10.5.

Will keep investigating, but it appears unless we upgrade to Snow Leopard, Java 1.5 is best the rest of us can do.

Windows users should try updating to the latest version of Java.  The Mac OS thread dedicated to this topic found similar results, but as the Mac has its own distribution of Java, it may be behind whatever 1.2.2 was compiled under.

So if you have the trouble mentioned above and are in Windows, try updating your Java Runtimes and see if that helps.  And let us know if it does. 

Okay, running the JavaApplicationStub directly let me get a terminal window that did show the exception.

1.2.2 gives the following:

[JavaAppLauncher Error] CallStaticVoidMethod() threw an exception
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:242)
        at apple.launcher.LaunchRunner.loadMainMethod(LaunchRunner.java:55)
        at apple.launcher.LaunchRunner.run(LaunchRunner.java:84)
        at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50)
        at apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)
logout
[Process completed]

Sounds like a version number incompatibility:  1.2.2 was probably compiled under a newer version of the Java Developer Kit then we Mac users have with our Java Runtime Environment.

I've confirmed that my system is completely up to day, System Update-wise.  There is no newer Java runtime available for Mac OS-X.  (Edit:  Not completely correct.  See next post)

I wish it would work.   

For the moment my wish is that they would just roll back to 1.2.1, but yeah, 1.2.3 would be nice too. 

Seriously, the whole issue is wonky... they put out 1.2.2 before the weekend, don't even give it a proper roll-out post on the main page for it, only saying deep in the forum that it has "bug fixes", and end up making the game unplayable for (most) of everyone on an entire OS.

If there is one thing I've learned at work, it is to never roll out any software changes on a Friday.  Doesn't matter how well tested the changes are, reality will conspire to ensure that they will never work.