Many cards require a “target” as part of their play requirements. For example, a spell might heal an injured ally, or a minion’s battlecry ability may deal damage to an opponent. Sometimes the target(s) can be chosen automatically, and other times they require the user to manually pick. In this lesson we will begin the process of supporting manually targeted play actions.
One of the first learning hurdles encountered with SpriteKit comes when determining how to get the contents from a scene to display as expected on various devices, each with their own resolution and aspect ratios. We will review a scene’s scaleMode property as a built-in solution that may work for some projects. Then, we will build a custom solution to overcome the limitiations we were otherwise stuck with.
While a card’s stats such as cost, attack, and hit points can add a lot of strategy to how you build your deck, its set of abilities may impact your strategy even more. In this lesson we will add a new ability to our minion cards called Taunt, so that whenever it appears on the battlefield, the enemy must attack it before it can attack non-taunt minions.
Now that we have the freedom to attack, you might be thinking it would be nice if there were more options. In this lesson, we will add code so that the enemy opponent can actually play cards and attack us too. This will give a greater variety of move options, and add a bit of strategy to the game, all while giving a great boost to the fun factor. In my opinion, this is where it actually starts feeling like a real game!
In this lesson we will pick up where we left off, and finish a working implementation of attacking. This will include creating a new game action, implementing it through a system, and providing a viewer so a user of our game can see it all happen. Along the way I will also do a bit of refactoring to make things more flexible.
The only way to win a match is to reduce your opponent’s hit points to zero. We currently support fatigue damage as one path toward this goal, but that is merely a battle of attrition. If we were to implement the ability for minions and heroes to attack each other, the level of strategy and fun would increase dramatically. We will lay some foundational work toward this end goal, and will create a working demo that highlights minions which are attack ready.
If there are no constraints on summoning minions, then this game would be almost entirely luck based. Whoever drew the strongest card first and played it would almost certainly win. Doesn’t sound fun to me. Let’s fix that by constraining the ability to play cards by their mana cost.
Now that we can play cards, let’s add a reason to do so. Our player’s deck is currently filled with nothing but minions, so you might be able to guess what this lesson is going to be all about. After playing a card that happens to be a minion, we will “summon” the minion. Instead of going straight to the graveyard, it will go onto the player’s battlefield, ready for combat.
You can take turns drawing cards from your deck and putting them in your hand… but at the moment all that leads to is a hand full of cards. Sounds like we need a way to start playing cards from our hand toward some other purpose. In this lesson we will provide the ability to play a card, and also enable the local player to control which of the cards they wish to play by interacting with what is presented on screen.
In the last lesson, we implemented the Fatigue stat – caused by attempting to draw cards from an empty deck. However, although we could watch the stat change, it had no real effect on the game itself. In this lesson, we will add a reaction to fatigue which applies damage to the player’s hero by the fatigue amount. As a result, we have the means to determine when a game will end – whenever a hero’s hit points have dropped to zero.