Collectible Card Game Headquarters

Looks like Forge can not provide the features I'm looking for: multiplayer over internet. By "can not" I mean there's no known amount of time and efforts that should be spent to achieve that.

So I'm going to switch to some research in the field of mtg rules enforcement engine. I have an idea in mind - should try to implement that and see if that can become a multiplayer game core.

I'm also unhappy with current development process:
* versions are released without notice (Wish I could enable ISD *before* the 1.1.4 was built)
* Doublestrike has changed quests serialization and now does not fix the crashes it caused, and everyone considers this is alright.
* The scripting language is too complex - I could not understand that SVar:DB, nor love the code that reads these files (and there are lots and lots of AllZone.getHumanPlayer() that is static references to GameState and its fields)
* That red newgame screen background is awful. (especially when shown after blue splash-screen)

Sorry to see you go...but I must point out that the scripting language is not complex at all. In fact, it is a work of art IMO. Good luck with your new project.

Many thanks for your work on the deck editors and booster generation. Also, best of luck. If you were to consider doing a dev blog or the like, I would love to hear about it!

The bi-weekly betas tend to be released on a Friday in my time zone as this gives the dev team the following weekend to merge into the project major code revisions which may be disruptive in some fashion.

This system gives the devs a couple of weeks to address any major problems before the next bi-weekly beta release.


BTW:

A new nightly build was just built and released and this new update contains the new material that was added to the project over the last 24 hours.

Good luck on your next adventure Max. Of all things the scripting language is one of the best parts of Forge, and has a bunch of documentation on the Wiki. (http://www.slightlymagic.net/wiki/Forge_API)

I can't tell which part you had trouble grasping, but it sounds like it was SubAbilities, where a card needed to Parse multiple, chained Abilities.

Take Timetwister for example:

Code: Select all

A:SP$ ChangeZoneAll | Cost$ 2 U |  ChangeType$ Card | Origin$ Hand | Destination$ Library | Shuffle$ True  | SubAbility$ SVar=DBChangeAll | SpellDescription$ Each player shuffles his or her graveyard and hand into his or her library, then draws seven cards.
SVar:DBChangeAll:DB$ChangeZoneAll | ChangeType$ Card | Origin$ Graveyard | Destination$ Library | SubAbility$ SVar=DBDraw | Shuffle$ True
SVar:DBDraw:DB$Draw | NumCards$ 7 | Defined$ Each | SubAbility$ SVar=DBChange
SVar:DBChange:DB$ChangeZone | Origin$ Stack | Destination$ Graveyard


Since the parser splits abilities on the '|' any SubAbilities need to reference a separate String Variable that's also on the Card object. So each line in turn gets parsed by the AF to create the final ability. After each line is resolved, it calls it's SubAbility or if it doesn't have one, finishes Resolving (moves to the graveyard, releases Triggered Abilities, etc.)

This script does the following:
SP means it's a Spell. Cost is 2 U.
Changes Zone of All Cards from a Player's Hand to that Player's Library. (The Shuffle here is unnecessary.)
Changes Zone of All Cards from a Player's Graveyard to that Player's Library and shuffles that Library.
Each Player Draws 7 Cards.

The last line regarding moving from Stack to Graveyard is actually not needed as the card should do that automatically. (And is technically wrong if somehow this spell had gained Buyback or Flashback or something)

Edit: We also have a thread for Card Scripting Questions if you had any specific questions regarding your issues with the Card Scripting.

I hate the developer turnover rate we've got going on lately....

We still need you Max, with all the changes to the card and deck objects, deck editors and so many other details you've been working on.

As for the issues causing you grief:

Why would anyone be so surprised that an AI game was never designed to support human vs human play?

QuestData is dynamically created. While losing quest progress in your development environment sucks, it's the price of progress.

The new games screen is being replaced soon with something that will be visually appealing with the same styling as the splash screen.

Thank you for your work Max.

I hope you will still drop by now and then (and maybe then you will accept the snail paced wavering progress this project makes).

Thanks for kind words.

Please, let me note that "becoming less active" does not mean leaving once and forever. I still particiate but... well without making that huge changes like switching a good half of the game to different Card classes or changing Zone from string to enum. I'll keep completing simple things like "fix bootser generation for isd" (they have a double-faced card slot) or "deckeditor does not delete the deck from disk). Will answer any questions on the code I've introduced too.

@Rob, I have to conclude that the current AI (as well as rules enforcement code) is designed to support a single game of a single human against a single computer, and this - can it be changed somehow? Does not seem so, unless someone volunteers to pass GameState to each resolve() and canPlayAi() method - to fix tens of thousands lines. (and it looks like I had some wrong expectations about forge). That's the what makes me search for a different project.

I tried to keep the saves between versions (and I'm not happy to see that someone just drops their support, because it turns out that I spent my time to provide compatibility in vane), and the currently reported crashes are about list of battles generation.

@friarsol, I understood the concept of subabilities, but it looks like we're missing a list of that functions (like ChangeZoneAll) with parameters, while the only valid reference for now is the source code. So, once someone wants to script a card, he just does not know which function to pick and which parameters it supports. Can look at similiar cards, but valid parameters list is still unknown since that card may use only a part of them.
That syntax with pipes and dollar signs does not look like any widely spread programming language, seems cryptic and repelling to me (well, it's my personal opinion) I would prefer a different syntax,(xml or something more similiar to java or even php would suit) just to see equal signs instead of dollards and commas in place of pipes. Even if it were possible to change the sysntax parser, not sure if the 9100+ cardname.txt files can be switched.

@Chris, both times I was not aware that a build was about to be made. I wish there was a notice a day in advance at least... while there was no solid schedule for releases. With 1.1.3 I was a few hours late to commit a fix to displaying of cards from sets with multiple arts (would commit earlier if knew that the beta was about to be built). As for 1.1.4 which was about to become an Innistrad prerelease, noone just checked that ISD cards, on which people spent so many hours scripting, were not avaliable for limited and quest mode. Of course, everything was fixed in the nearest nightly build, but it is not the nighly build link that is attached on top of parent forum. So people will download a bugged version, have to patch it by themselves... and maybe have fun at last.

Max mtg wrote:
@Chris, both times I was not aware that a build was about to be made. I wish there was a notice a day in advance at least... while there was no solid schedule for releases. With 1.1.3 I was a few hours late to commit a fix to displaying of cards from sets with multiple arts (would commit earlier if knew that the beta was about to be built). As for 1.1.4 which was about to become an Innistrad prerelease, noone just checked that ISD cards, on which people spent so many hours scripting, were not avaliable for limited and quest mode. Of course, everything was fixed in the nearest nightly build, but it is not the nighly build link that is attached on top of parent forum. So people will download a bugged version, have to patch it by themselves... and maybe have fun at last.

I agree that a slightly more formal process for the release is necessary. Even if Chris posted a "Upcoming 1.1.x Release" thread in Developer's Corner so we could hash out any remaining issues would be very helpful.

Chris H. wrote:The bi-weekly betas tend to be released on a Friday in my time zone as this gives the dev team the following weekend to merge into the project major code revisions which may be disruptive in some fashion.

This system gives the devs a couple of weeks to address any major problems before the next bi-weekly beta release.

I agree that the timing this time wasn't so great. The Innistrad cards were added 9 hours before the beta release. ArsenalNut did a great job preparing the cards, but nearly 200 files is too much for some errors to not slip through.

I found two cards with wrong names, which can cause decks and cardpools created with the beta to not be compatible with the next version.

jendave wrote:I agree that a slightly more formal process for the release is necessary. Even if Chris posted a "Upcoming 1.1.x Release" thread in Developer's Corner so we could hash out any remaining issues would be very helpful.

`
I tried that in the past. I guess that I could try it again for awhile.

Sloth wrote:I agree that the timing this time wasn't so great. The Innistrad cards were added 9 hours before the beta release. ArsenalNut did a great job preparing the cards, but nearly 200 files is too much for some errors to not slip through.

I found two cards with wrong names, which can cause decks and cardpools created with the beta to not be compatible with the next version.

`
I found and fixed the broken Innistrad pic URLs ... after the release. The major rewrite of the card scripting engine also resulted in a number of typos that we had to fix.

Max mtg wrote:That syntax with pipes and dollar signs does not look like any widely spread programming language, seems cryptic and repelling to me (well, it's my personal opinion) I would prefer a different syntax,(xml or something more similiar to java or even php would suit) just to see equal signs instead of dollards and commas in place of pipes. Even if it were possible to change the sysntax parser, not sure if the 9100+ cardname.txt files can be switched.

The card scripting is an example of a Domain-Specific Language. It's purpose-built for our implementation of Magic functions. Using Java in the card files would bring us right back to the bloat that hard-coded cards caused. Delimiters chosen were based on never seeing them in any actual magic text.

If I recall, the DB abilities are the same as the normal abilities. Same syntax is expected. The DrawBacks USED to be limited to a particular list of things like drawing a card, or dealing damage to the player who cast the original spell, etc. Now, you can mix and match more freely.

@all - I've been busy with real life - the sort of work that makes actual money, since the grocery store where I live won't take quest credits, and nobody wants to give me cash for my killer Bird. Anyway now my schedule's clear and I can work this code all week.

Doublestrike has changed quests serialization and now does not fix the crashes it caused...

These bugs are definitely not alright (by definition). Wanted to fix and participate more but didn't have time. Will be more involved this week.

Sloth wrote:

Chris H. wrote:The bi-weekly betas tend to be released on a Friday in my time zone as this gives the dev team the following weekend to merge into the project major code revisions which may be disruptive in some fashion.

This system gives the devs a couple of weeks to address any major problems before the next bi-weekly beta release.

I agree that the timing this time wasn't so great. The Innistrad cards were added 9 hours before the beta release. ArsenalNut did a great job preparing the cards, but nearly 200 files is too much for some errors to not slip through.

I found two cards with wrong names, which can cause decks and cardpools created with the beta to not be compatible with the next version.

For bi-weekly releases that occur close to a set release like Innistrad did, I would suggest that we make it a policy hold off on the beta-release until the major changes for the new set are ready. Since we're doing this for our own enjoyment, I would rather put out a working product than stick to a self-imposed release schedule.

I had most of the cards ready to go several days before I checked them in. I was waiting for magiccards.info to post their Innistrad data so the setInfo script could be run. I think it would have helped if I started checking in cards after the full spoiler was released so the other devs had more time to QA things. Then we could have waited for the updated magiccards.info and mtg-data.txt before making the beta-release.