Collectible Card Game Headquarters

Headrock wrote:

marek14 wrote:I was thinking about these systems in the past. Some of my ideas were:

For idea 1, yes, that could be employed. But it still leaves the question of what happens when two armies with the same properties meet.

Well, basically, if creature A can block creature B and vice versa, then they block each other movement. If only one can block the other, it blocks its movement, but it's free to leave itself. If neither can block the other, they can move past each other.

On your points #2 and #3, I'm not sure exactly what you are referring to. Are you talking about having rampaging monsters who are a single creature, but turn into a full deck when in combat? I... I don't get it, please elaborate on what you mean.

Well, my idea was that each "wild" creature has a deck of its own that "represents it" and fight between you and a creature or between two creatures is a Magic battle -- like it was in Shandalar.

marek14 wrote:Well, my idea was that each "wild" creature has a deck of its own that "represents it" and fight between you and a creature or between two creatures is a Magic battle -- like it was in Shandalar.

Well, I was going to handle "wild" creatures as decks from the get go, they don't really need special rules, they just need to be thematically compliant with the region capital they spawned from (or wherever the source was). There's no reason they should be functionally different than proper enemy armies - aside from their objectives, perhaps.

drdev wrote:Subclipse isn't necessary. I use Tortoise SVN myself and that works fine for me.

I used to use Tortoise on XP64, I hope it works on Win7. But doesn't the Forge project need all that subclipse and maven and whatever all that stuff is? I must admit, it all sounds like dark sorcery to me, I just tried to follow the instructions given here on the forums and found myself at a dead end. *Sigh*, MSVC++ was so much simpler

Headrock wrote:
I used to use Tortoise on XP64, I hope it works on Win7. But doesn't the Forge project need all that subclipse and maven and whatever all that stuff is? I must admit, it all sounds like dark sorcery to me, I just tried to follow the instructions given here on the forums and found myself at a dead end. *Sigh*, MSVC++ was so much simpler

I use Tortoise on both Win7 and Win8. It should be fine. Subclipse is just for integrated SVN capabilities. It's not required.

You should be able to use Eclipse (or your IDE of choice, I use IntelliJ) to import the project. Maven is just what's used for builds, but most developers use IDEs for debugging/compiling just like you would use Visual Studio.

Ah, that's good to hear. Then I hope I can get it to work when I get home from work today.

I still think some stuff should be simplified. To be constructive i'm going into the details:

Upkeep costs

In the previous chapter I explained how the Mana that is collected from lands and capitals determines the maximum size and composition of the armies under your control. Remember, the total casting cost of your deployed forces (including all cards added into the deck of all commanders you have) cannot at any time exceed the amount of Mana produced by your lands and capitals.

However, I also mentioned that these lands and capitals produce Mana on a per-turn basis, and that was no mistake. Each turn, the player accumulates all Mana that was not spent on maintaining armies. In other words, you can imagine that each turn you spend an upkeep on each card in each army deck that is exactly equal to the Casting Cost of that card, but you get to keep every Mana point you did not spend this way.

For example, in the previous chapter we were generating 36 Black Mana, 7 Green, and 6 Blue. Lets say that our commander's army, meaning all cards added to the commander's deck, have a combined casting cost of 35B, 7G, and 4U. This is the upkeep we need to spend every turn in order to maintain said army, which leaves us with 1B and 2U to spare. This is a mana surplus, which is accumulates in our mana pool from turn to turn. Therefore, at the start of the second turn we will have 1B, 2U in the pool. At the start of the third turn, we will have 2B, 4U, and so on.

Note that whenever cards are pulled out of a commander's deck, they no longer require an upkeep - but there will be another mechanism to ensure that players cannot simply alter a deck as they see fit to exploit this.

I don't think linking upkeep costs to the cards in decks is a good idea, because:
1. This does punish playing with cards with a higher converted mana cost. Is there any reason for this?
Imagine i've found a cool new Ghoultree that i want to play with, but i won't because it eats up my ressources.
In general, this forces people to play with aggro decks, even though they would have prefered playing control, midrange, ramp or combo.
2. It would be very frustrating to temporarily loose some territory and beeing forced to completely drop a combo deck, because it doesn't work with different (cheaper) cards.


Solution:
The upkeep cost is tied to the general (commander). A black general would require black mana for upkeep and his deck can only contain black and colorless cards. After gaining some experience (by winning battles) he can be upgraded to a better black general (better vanguard ability) or a blue black general (or another color) who can have up to 10 blue cards (and more with the next upgrade) and also costs some blue mana for upkeep.

Tortoise installed fine as expected, and I've checked out the trunk into some folder, but now my problem is with Eclipse itself (or rather, working with Java projects, I suppose), since I can't figure out how to import the whole thing as a single project. I've managed to import the projects separately, but obviously most of them refuse to run at all (amusingly, forge-m-desktop does run and shows a splash screen. Nice work, drdev, your code works even for dummies ).

I'm going to attempt some more combinations of import/new project/whatnot, but would very much help if someone could lend a hand on this.

EDIT: Managed to import as a complete set by using File->New->Java Project, and then entering the folder path of the source code. However, I cannot actually run this project, I get a "Selection does not contain a main type" error... :/

I don't remember how Eclipse tries things, but for me when I edit my Run Configurations my main class is: forge.view.Main, my Working Directory is: <forgeParentDirectory>\forge\forge-gui and my active classpath module is forge-gui. We should probably move all this chatter of setting up Forge to a more appropriate thread, so it's not spamming the conversation of Campaign Mode.

Posted my issues at the "How to get started" thread.

Back on topic, then.

Sloth wrote:I don't think linking upkeep costs to the cards in decks is a good idea, because:
1. This does punish playing with cards with a higher converted mana cost. Is there any reason for this?

You're absolutely right, there isn't. And the idea to have upkeep costs for generals rather than cards in the deck is interesting, and I'll be sure to keep that as a fallback in case there's no better method.

However, my point with upkeep was to ensure that the STRENGTH of your decks will have to comply with your overall power, so that players will have to juggle between fielding strong armies and accumulating surplus mana for improvements and "overland" spellcasting, and I don't know if upkeeps for the general would represent that very well. I do really like the idea that you would need a multi-color general in order to have a deck with multiple colors in it, or upgrade a low-level general to enable him to have more colors in his deck. That does solve one problem properly, but again, I would still be on the lookout for a system that also governs how strong his deck can be. Perhaps put a cap on Common/Uncommon/Rare, that can be increased with the general's level? Does that sound like a good idea?

Maybe it would be better to charge mana upkeep based on RARITY, rather than the card's mana cost. I.E., a common black card would cost 1B, an uncommon one would cold 3B, and a rare one 6B, so somesuch. That way, deck strength and color are more accurately represented, AND it solves the problem of having to spend colorless mana on upkeep (though... colorless cards and multi-color cards may still require a solution, like the slider bars I mentioned earlier).

I don't know if this solution is better than your upkeep-per-general idea, honestly. I suppose both systems still have their flaws. I would of course like to hear your opinion on that, and will keep thinking about it in the meanwhile.

2. It would be very frustrating to temporarily loose some territory and beeing forced to completely drop a combo deck, because it doesn't work with different (cheaper) cards.

Actually that is something I would actually like to see - a very strict combo deck IS supposed to be vulnerable to sudden changes in availability, so wizards who wish to rely on one would have to be suitably prepared to keep the deck viable in such situations. Yes, there would be a greater imperative to work with more "malleable" decks, and the challenge of being able to run a combo deck would make the game more interesting, I hope. Of course, I'm sure some would disagree.

Headrock wrote:Perhaps put a cap on Common/Uncommon/Rare, that can be increased with the general's level? Does that sound like a good idea?

Yes, that sounds much better. A level one general could have a restriction of say 0M 1R 5U while a level 10 general could have 1M 4R 15U for example. That would have a great effect on the power level of their decks.

Headrock wrote:Maybe it would be better to charge mana upkeep based on RARITY, rather than the card's mana cost. I.E., a common black card would cost 1B, an uncommon one would cold 3B, and a rare one 6B, so somesuch. That way, deck strength and color are more accurately represented, AND it solves the problem of having to spend colorless mana on upkeep (though... colorless cards and multi-color cards may still require a solution, like the slider bars I mentioned earlier).

I don't know if this solution is better than your upkeep-per-general idea, honestly. I suppose both systems still have their flaws. I would of course like to hear your opinion on that, and will keep thinking about it in the meanwhile.

I think there are lots of problems with charging upkeep based on the deck:
1. Upkeep for colorless cards and multi-color cards as you've mentioned yourself (sliders are a deadly sin in game design ).
2. There would still be the problem of "feeling bad" when designing your deck the way you like it, because you want to test the cool new rare. This is completely different from designing under restrictions, which is much easier to grog for players.
3. Changing the deck to all basic lands whenever there is no chance for a battle and powering up when needed. That loophole would have to be fixed somehow.
4. Having lots of generals with only basic lands, to run around as errants.
5. Lot more micro-management in general.

What flaws do you see with upkeep-per-general?

Headrock wrote:

2. It would be very frustrating to temporarily loose some territory and beeing forced to completely drop a combo deck, because it doesn't work with different (cheaper) cards.

Actually that is something I would actually like to see - a very strict combo deck IS supposed to be vulnerable to sudden changes in availability, so wizards who wish to rely on one would have to be suitably prepared to keep the deck viable in such situations. Yes, there would be a greater imperative to work with more "malleable" decks, and the challenge of being able to run a combo deck would make the game more interesting, I hope. Of course, I'm sure some would disagree.

My experience with Shandalar, the quest mode of Forge or similar games is that you always end up building good stuff decks and you already need a lot of dedication to build combo or even synergy decks. I don't see the need to make it even harder.

If a combo deck does arise that is too easy to aquire, there is always the possibility to add opponents that are hard to beat with that combo.

sloth wrote:Yes, that sounds much better. A level one general could have a restriction of say 0M 1R 5U while a level 10 general could have 1M 4R 15U for example. That would have a great effect on the power level of their decks.

I would like the highest generals to have no cap, though. Would kind of suck to have developed a deck based only on rares or somesuch and not be able to use it - especially when you've collected all the necessary cards

Sloth wrote:sliders are a deadly sin in game design.

Oh dear no, they are not a sin, just something you should avoid if you don't know how to design them well. But even with upkeep-per-general, would it make sense not to have colorless generals?

Sloth wrote:This is completely different from designing under restrictions, which is much easier to grog for players.

How are mana-based restrictions different from arbitrary restrictions? If we go by rarity-based-upkeep, then you can add as much as you can pay for with your mana - whereas putting a rarity cap on a commander makes an immutable boundary that the player can't cross no matter how much mana he has to spare, no?

Sloth wrote:Changing the deck to all basic lands whenever there is no chance for a battle and powering up when needed

That is not a loophole, that is the point. If you don't need an army, you could completely disable that army and remove all the upkeep - only to reactivate it when needed. Upkeep is only paid when your army is active. In fact I would even consider having a button to do it for you (activate/deactivate an entire army deck with one click).

Sloth wrote: Having lots of generals with only basic lands, to run around as errants.

I'm assuming that some commanders will actually be hired solely for this purpose. They would be extremely vulnerable, of course, if you don't actually give them a deck. Imagine you send your errant somewhere and he runs into some hidden random encounter fight - even the most harmless fight will result in his immediate defeat. Instead, such "runners" would be outfitted with a small, cheap army made up of your leftover cards - just in case.

Also, I think I mentioned this earlier, but I'll mention it again - we could also charge mana (from the surplus, not on a turn-by-turn basis) for altering any army deck. Every card you put into a deck costs a certain amount of mana (again, basing the cost on rarity could work well here just as it would for upkeep). This is one way to ensure that players willing to micromanage don't find exploits by constantly changing their decks.

Sloth wrote:What flaws do you see with upkeep-per-general?

For one, as mentioned, that the size and strength of your deck does not depend on your progress (though this might be solved with rarity caps, but introduces another problem of strong bias against rare card decks even after all the meticulous collection of cards is done with).

Secondly, if a general can only lead troops of his own color (or any limited set of colors), then the availability of generals would limit your color selection. I haven't decided on which system to use for recruiting, but in any system generals should overall be pretty rare and costly (even without upkeep), and their appearance tied to some factors of random chance - so until you get the general you want, you'd be screwed, and there is no guarantee you'll ever get him. On the one hand, that's Magic - there's no guarantee to get the rare card you want in a booster pack - but if your strategy is severely handicapped due to bad luck, then that's a problem with the game. If you can't get a general who will support the cards you have, you're screwed! This becomes even more crucial if we want to allow generals to be killed, in one way or another (though my current design does not).

I'm not saying general upkeep is the worse method, though - it certainly is a good idea, but not without its own flaws. I'm just hoping we'll be able to reconcile the flaws, or find a different system that does work. Like I said, I'm keeping the options open on this and still want to hear opinions.

Headrock wrote:Also, I think I mentioned this earlier, but I'll mention it again - we could also charge mana (from the surplus, not on a turn-by-turn basis) for altering any army deck. Every card you put into a deck costs a certain amount of mana (again, basing the cost on rarity could work well here just as it would for upkeep). This is one way to ensure that players willing to micromanage don't find exploits by constantly changing their decks.

In this case, would cards that were just acquired be free to be added into your deck? And "pre-sideboarding" many cards you've already owned in your collection be the only thing that actually costs some type of resource?

friarsol wrote:In this case, would cards that were just acquired be free to be added into your deck?

Not necessarily, that's more of a balancing issue. I suppose the first cards you're given when starting the campaign would have to be free, since you don't have any mana surplus yet. But there's no absolute reason to allow additional cards into your decks without first paying mana for them - nor is there any reason why you SHOULD pay mana for them. That's purely a rules decision, and could even be made optional...

friarsol wrote:And "pre-sideboarding" many cards you've already owned in your collection be the only thing that actually costs some type of resource?

I'm not sure I understand what you mean.

@ Moomarc:

While we're waiting to see whether I'll be able to compile any code at all, maybe you'd like to make some attempts to generate some graphics for the game? The #1 item to make would be regional capital icons, to replace the ugly ones I made for the demonstration in the opening post.

It doesn't matter where or how you make them, I basically either drew them by hand or took MTG cards as templates and drew over them.

Cool, I'll look at some icons when I have free time between jobs. I just need some kind of idea what pixel size we're looking at per cell.

moomarc wrote:Cool, I'll look at some icons when I have free time between jobs. I just need some kind of idea what pixel size we're looking at per cell.

If all goes well, the map should be zoomable - so I'd say aim towards for at least 50x50. But at the moment the point is just to see what kind of styles you can come up with.