Unity’s ECS architecture is nearing its official release, and I am getting more and more excited for it. After a brief introduction, we’ll spend some time digging in and experimenting. By the end you should have an elementary grasp of Entities, Components and Systems within this new architecture.
C#
Scriptable Objects
Scriptable Objects are a special type of data object in Unity. They have several important benefits but may not work ideally for every scenario. In this lesson we will cover what they are and how to use them.
Make a CCG – JSON
In the previous lesson I hard-coded a demo deck of cards. This wasn’t “necessary” because of my architectural choices. It was merely a simple placeholder which didn’t require me to commit to any kind of data store or structure. Still, to help avoid any confusion, I decided I would go ahead and provide an example post that shows how the same deck could have been created with some sort of asset – in this case a JSON file.
Make a CCG – Spells & Abilities
Any card can have special abilities – by this I mean that it can cause one or more of our “Game Actions” to trigger based on special criteria. Spell cards are unique in that they must have at least one ability in order to serve a purpose. In this lesson, we will begin implementing spells, and by necessity, will also create an ability system that we can apply to our other cards as well.
Make a CCG – Targeting
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.
Make a CCG – Taunt
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.
Make a CCG – Enemy A.I.
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!
Make A CCG – Attack
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.
Make a CCG – Prepare to Attack
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.
Make a CCG – Mana
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.