Collectible Card Game Headquarters

@Hellfish, how about this code?

Code: Select all

public enum KeywordType {
 Flying(KwParamType.None, null),
 Equip(KwParamType.Cost, "%s: Attach to target creature you control. Equip only as a sorcery.")
 Annihilator(KwParamType.Number, "Whenever this creature attacks, defending player sacrifices %d permanent(s).");
 // list all KWs

 public KeywordType(KwParamType parameter, String hint) { ... }
}

public class KeywordInstance<T> {
 KeywordType type;
 T parameter;
 boolean isHidden;
 boolean isIntrinsic;
 // more fields if needed
}


Max mtg wrote:@Hellfish, how about this code?

Suspend has both a Cost and a Magnitude (how much to Suspend it and how long it's suspended for). We'd need to be a bit more flexible in the Param Type.

Not a huge problem - add two parameters to KeywordType, overload constructors to accept one, two parameters or none at all.

Thanks for the starting point, Max. I'm gonna pick away at this for a while and where it leads.

Good to know that code was useful.

As a way to avoid adding two generic parameters to kwinstance beacuse of "suspend", it could be a good idea to always declare integer parameter in keyword instance, so there will remain a single parameter (cost or some type).

If kwinstance were there with parameters only and without members used by gamestate (such as intrinsic) it could be added right to cardface in core module... Or there could be kwinstance (just kwtype+parameters) and another class KeywordOnGameCard with reference to the former class instance and variables specific for game state. This seems better structured, but probably more complicated.

Speaking of downsides: custom set scripters won't be able to add new keywords without a private build (with kws added into enum). Objections for downside: (1) there are no successfully implemented custom sets with forge yet (noone needs the new kws this far), (2) let's implement keywords as an enum first and then after we can fully embrace the structure of data, possibly move it to file

Just keep in mind that Suspend isn't the only keyword that has multiple parameters. I was just using that as an example. Reinforce has both a magnitude and a cost. Typecycling has both a type and a cost.

That gives us the following options for things Keywords can have:
Cost
Magnitude
Type

That's even better, Sol.

Code: Select all

public enum KeywordType {
 Flying(false, false, false, null),
 Equip(false, true, false, "{cost}: Attach to target creature you control. Equip only as a sorcery."),
 Suspend(true, true, false, "Rather than cast this card from your hand, you may pay {cost} and exile it with {magnitude} time counters on it. At the beginning of your upkeep, remove a time counter. When the last is removed, cast it without paying its mana cost.{if-creature| It has haste.}"),
 Annihilator(true, false, false, "Whenever this creature attacks, defending player sacrifices {magnitude} permanent(s).");
 // list all KWs

 public KeywordType(boolean hasMagnitude, boolean hasCost, boolean hasType, String hint) { ... }
}

// This is a class for forge-game module. Core does not support costs yet. I would have to keep them unparsed if this were declared in core.
public class KeywordInstance {
 KeywordType type;
 int magnitude;
 Cost cost;
 String type;
 boolean isHidden;
 boolean isIntrinsic;
 // more fields if needed

 public string getHint() {
  string hint = type.getHint();
  if ( hint == null ) return null;
  return type.getHint().replace("{cost}", cost.toString()).replace("{magnitude}", magnitude).replace("{type}", type);
 }
}


To avoid extra complexity, I suggest that these classes are implemented in game module. Will move to core whatever is appropriate later.

My wife and I have decided to buy a home for us to live in at this stage of our life. We will be quite busy for a number of weeks and possibly months until we are finally finished.

I doubt that I will be able to release a new snapshot build each and every day and the Beta builds might not be released as frequently.

Chris H. wrote:My wife and I have decided to buy a home for us to live in at this stage of our life. We will be quite busy for a number of weeks and possibly months until we are finally finished.

I doubt that I will be able to release a new snapshot build each and every day and the Beta builds might not be released as frequently.

Have you chosen a person who is going to make builds while you are busy?

That's exciting news for you guys. Best of luck for the move and in your new home. Will you be a first-time home owner then? Congratulations!

As for Forge builds, I'm sure the snapshot users can get by with even a weekly release, if that's manageable, and a monthly beta release. And if there's features we specifically need tested we can try squeeze out an extra snapshot somewhere. But real life has to come first.

Edit: Or as Max suggests, someone else can maybe do the releases.

Thank you for the kind words.

Yes, this will be our first non-rental home. My wife and I are both 60 years old and it is time to now buy a home. We found a two bedroom one bathroom condo that has been remodeled and updated, looks really nice. With my inheritance we will be able to buy this condo for cash and will not need a mortgage.

I have not yet picked anyone to do the builds while I am busy. This would require a clean copy of SVN repo without any changes. And this would require a way to enter the build and deploy Maven command into a terminal window or a similar approach.

It is possible to create a run configuration as a Maven Build and then the appropriate Maven command would be entered into the Goals text box. When Dave was first setting up the Maven system I attempted to do this and discovered a bug/problem in the FTP tool and this caused a build and deploy failure.

We might be best off with a less frequent build and deploy over the next few months.

Chris H. wrote:My wife and I are both 60 years old and it is time to now buy a home.

That's hard to imagine. I would have never assumed that!


I think any developer is able to set up an environment with a fresh local installation of SVN repository. The main task is to build the package, I suppose. Copying to FTP can be done manually or just by a properly set up batch file.

We might discover a critical failure in a build and have to release a patch soon. Now, when you are the only one who publishes builds this could be problematic. So if you handle the build process to any active developer whoo has spent enough time with Forge (like Sloth, Sol, Agetian, me or Hellfish), the project would be more stable

Max mtg wrote:

Chris H. wrote:My wife and I are both 60 years old and it is time to now buy a home.

That's hard to imagine. I would have never assumed that!

Yea I was thinking the same thing. Kudos Chris. Enjoy your new home.

Max mtg wrote:I think any developer is able to set up an environment with a fresh local installation of SVN repository. The main task is to build the package, I suppose. Copying to FTP can be done manually or just by a properly set up batch file.

We might discover a critical failure in a build and have to release a patch soon. Now, when you are the only one who publishes builds this could be problematic. So if you handle the build process to any active developer whoo has spent enough time with Forge (like Sloth, Sol, Agetian, me or Hellfish), the project would be more stable

 
It is fairly easy to create a second workspace in Eclipse. Then checkout the project and import the modules. Update to the head version and make sure that you can run Forge before you execute the Maven build and deploy command. You also need to set the path to the second workspace.

friarsol wrote:

Max mtg wrote:

Chris H. wrote:My wife and I are both 60 years old and it is time to now buy a home.

That's hard to imagine. I would have never assumed that!

Yea I was thinking the same thing. Kudos Chris. Enjoy your new home.

Oh, I second that! Wish you the best, Chris! Hope your family will be happy in your new home!

- Agetian