Collectible Card Game Headquarters

hi, i'd like to change the trunk (svn/src) (not my branch) in the following ways:

• refactoring direct references to static fields in the following classes, making the fields private, with public, protected, or package level methods for getting, setting, or incrementing the values:
  
  • forge.AllZone (e.g., AllZone.getHumanPlayer() instead of AllZone.HumanPlayer)
  • forge.ComputerUtil_Block2
  • forge.Phase
  i won't move the fields, just filter access to them with methods. it's going to subtly change many lines of code, but the new references will have identical obviousness. this is going to make it much, much easier for me to keep the game state/AI code up to date with the latest fixes and features, since i've already performed a similar (and necessary) refactoring there.
  
• removing SimultaneousEntry and SimultaneousEntryCounter fields from forge.PlayerZone_ComesIntoPlay. they just aren't being used (read).
• seeing if i can change CardFactory to load cards on an as-needed basis, instead of all at once. this should improve startup time of the game and the unit tests i'm writing. i'll have to make sure it doesn't break the deck editor, however, which will still need to load all the cards. i think.
• formally update the eclipse project file and build.xml to java 1.6. (i was encountering some compilation problems until i changed this setting.) the code is already 1.6 specific, as evidenced by our use of java.io.File.getFreeSpace and java.awt.Font.DIALOG.

what say all of ye?

I will release the next beta today and get that out of the way before the changes are made.

Over the last couple of years some people reported that a version of forge was not compatible with the java 5 on the computer they were using. Some people are able to play forge at work, school or the library and these computers could not be easily updated to java 6.

We also have a lot of people with Apple Macintosh computers using forge. Older models of Macs were built using the Power PC chip and these computers can not be updated to java 6 and are limited to java 5. Apple switched over to the Intel line of processors several years ago and the Intel based Macs can be updated to java 6.

We have tried supporting the computers that are limited to java 5 the last several years but I think that we will have to eventually require java 6.

Sounds good to me, though I thought we were *trying* to keep compatibility with older java, what with some string shenanigans a while ago. (Actually, that was a long while ago... I don't mind either way.) (NOT-REALLY-EDIT: Yeah, what Chris said)

I'm gonna have to keep an eye on the svn updates so I don't keep going by the old ways

Hehe, It is early morning where I live and I am working on my second cup of coffee.

If the code is using that DIALOG constant and File.getFreeSpace, it has already crossed into Java 6. I would suggest changing those references if you want to maintain compatibility with Java 5. Perhaps you could look at prior revisions using your revision control software?

nevermind, i just saw the beta announcement from an hour ago. [strikethrough]chris - where do you announce the betas?[/strikethrough]

i'll see if there are other references to non java 5 api items. if they are few, maybe i should revert them to use java 5. i get to use svn blame! i mean, svn praise!

Braids wrote:nevermind, i just saw the beta announcement from an hour ago. [strikethrough]chris - where do you announce the betas?[/strikethrough]

i'll see if there are other references to non java 5 api items. if they are few, maybe i should revert them to use java 5. i get to use svn blame! i mean, svn praise!

`
The Beta announcements are made on the main CCGH Forum for Forge: Forge. Today's beta announcement can be found at Forge Beta: 06-24-2011 ver 1.0.14 SVN rev 10003.

For a number of months we have tried to release a new beta every 2 weeks. New betas tend to be released on either Friday or the following Monday.

You will notice that we devs at times mention holding off of a SVN merge until after the next beta is released. Some of the biggest changes that we make are merged into the SVN right after a beta is released. This will give us time to shake out a few bugs before the following beta release.

We all try work together with some co-ordination and so far it has worked out fairly well. If someone mentions that they have a big merge planned and that it may be disruptive of the SVN then I will respond by getting the beta out quickly.

as they say, a version control system is no substitute for communication between developers.

maybe you can play this for its madness cost, but isn't it hard to debug a beta right after its codebase just got turned upside down?

oh, and if my ideas caused you to move with celerity, thank you.

Braids,
We don't exactly have a "New Developer starter guide" for pits and traps that they should watch out for before they start messing with our codebase. While we had been "trying" to keep things 1.5 Compatible, it appears things have switched over in the last few months. Since noone on the forums reported any issues with it, it will probably just be easier to add Java 1.6 as a Requirement.

As far as your suggested changes, I'll be the first (if I'm not sleeping) to approve removal of dead code. The accessors to the Global structures is reasonable.

I'm looking forward to the lazy load in CardFactory. I think speeding up the initial launch of Forge will be very useful, especially for people who want to get right in and play.

Braids, welcome to the fray....

All those static references confuse me anyway... good riddance, I say. I had been doing some work in Constant.java, attempting to add dynamically loaded lists of card types. I jumped through quite a lot of hoops to get a static reference to an ArrayList which I could modify at runtime, but be accessible by all other modules.

We tend to simply comment out dead code and leave it there for a few releases, then if nothing serious breaks because of it, remove it entirely.

Sol, do you think you could rework the python scripts to deal with adding Oracle text so at the very least deck editors will operate without CardFactory?

Rob Cashwalker wrote:Sol, do you think you could rework the python scripts to deal with adding Oracle text so at the very least deck editors will operate without CardFactory?

Sure I can take a look, I may even have a local file that had started this a while back. Will have to see if that's the case.

friarsol wrote:I'm looking forward to the lazy load in CardFactory. I think speeding up the initial launch of Forge will be very useful, especially for people who want to get right in and play.

the first draft is in r10095! i had to rewrite most of CardFactory and ReadCard, but i did it. it works fastest in constructed or constructed random. as soon as you try to generate a new random deck (instead of picking a random one from the list), edit a deck, or visit the store, forge delays while it loads all the cards. this is probably a bad thing for users, but the code is out there now for comments.

Hehe, found a somewhat amusing bug. The Mana Pool gets CardID 1 and overwrites whichever card in your deck *also* got CardID 1.If that card comes into play tapped you can actually succeed in tapping your manapool...Well, *I* thought it was amusing.

Hellfish wrote:Hehe, found a somewhat amusing bug. The Mana Pool gets CardID 1 and overwrites whichever card in your deck *also* got CardID 1.If that card comes into play tapped you can actually succeed in tapping your manapool...Well, *I* thought it was amusing.

Maybe this is the dreaded unplayable card in your hand bug?