The issue was never the Hypnotic Specter, it was the Dark Ritual. In early Magic, there was a card called Hypnotic Specter, or as it was (not so) affectionately known – “Hippie.” It cost 3, was a flying 2/2 and if it dealt damage you had to discard a card at random. People thought at the time that it was busted, because it had a terrible habit of coming into play on the very first turn of the game, in spite of the fact that it cost 3. Arguments were made that it should be banned, because “random” meant that there was a chance that the Hippie just stole the land (resources) right out of your hand.
The issue was never the Hypnotic Specter, it was the Dark Ritual. The card that nobody thought anything about, was the Dark Ritual, a card that turned 1 mana into 3 mana one time. I mean, if it only did it once, how good was it really? But that’s not really what it did. What it did was give you the ability to do something on turn 1, that you were not supposed to be able to do until turn 3. Things like, well. play a Hypnotic Specter.
The issue was never the Lightning Strike, it was the Main Stat – is one of the conclusions I reached after thinking about power in terms of Dungeon Quest. There’s a playtest card called, Lightning Strike in Blue that all of my players think is busted. It costs 4, can hit any target, deals 4 and if that creature dies it deals 2 to another target. And all of it ignores armor. In the early game, it’s basically pay 4 and kill 2 dudes with a level of impunity that is usually reserved for special occasions – like the good silver.
One of the original and core ideas of Dungeon Quest a concept called the Main Stat. It is different for each class and basically says that if you only use the single color on your character, you get a bonus to your resources. As of this writing the Main Stat for a character starts at 2, and if you only use that character’s color alone, you can get 4 instead.
The idea was that it would encourage people to build mono-color decks since there is such a resource advantage. Basically, you have 4 total points available all at once either way, but can only buy the more expensive things if they are in your color early on. It’s another way to prevent people for building 3 color whatever decks – which don’t have much in the way of replayability.
But, on the Mage character, that means that on turn 1 – they have access to 4 Blue and can throw Lightning Strike. That’s not good, because in the early game it basically reads “Shuffle up your cards, since you just won.” Yet, I’m beginning to think that maybe, just maybe, Lightning Strike is about where 4 drop cards should be power wise. Which means that I can’t have the big guns available so early. That means that I need to reduce the Main Stat. I’ll try out 1/2 for the next playtest and see if that works.
Speaking of things that I’ve been thinking about, I’ve decided that I do need to move everything into Core for Paper Zeppelin, because the spriteManager is a SpriteManager and not a Game. I’ll explain. So in MonoGame and XNA before it, you can designate classes as different types. Some of those types carry additional baggage with them. So like, the Core Function is a Game and the SpriteManager is a SpriteManager. That means that within those classes, they have certain built in functions. Right now, everything on the screen for Paper Zeppelin is a sprite or information that is derived from a sprite. So the bananas way that it is structured is more or less fine.
But it’s that same structure that is going to bang me badly. Let’s explain with an analogy, since we lack the technology for me to express it with interpretive dance and holograms. Imagine a mobile, like something that hangs over a crib. At the top, there is a hook. In our analogy that is the Main() function. Hanging from that is a string that attaches to a plush giraffe, that is our Core() function. Now from that is a little cross bar and off of one of those is a monkey that is the SpriteManager for the purposes of this analogy.
Now if we added sound, that would have to be hung on a different bar that is hanging from our giraffe Core. Let’s imagine it’s a cool zebra. But, here’s where it gets tricky. The cool zebra and the monkey are not directly linked in the structure, so that means that they cannot easily communicate, and it’s possible that it would be impossible.
That means, that Mr. Giraffe should be doing the heavy lifting and coordinating the data between the 2. That would be the proper way to structure everything. Now, remember what I said before about types? That also means that I couldn’t just pin the zebra (sound) and the monkey (sprites) together because a SpriteManager instance doesn’t have the built in sound functions.
The thing is, this would have been a massive problem that I would have had to find a work around for previously once I needed to do things that weren’t sprites. Now, I get the chance to fix it all before it’s ever a problem in the first place. So all base game logic and the SpriteLists themselves need to exist in Core. Great, now I just need to do it.