Game Description
ExileCon: Mobile is a fan made recreation of the physical card game that was available at the Path of Exile conference: ExileCon. Players begin with a few cards, and defeat monsters to acquire additional cards. After each battle however, durability is lost, and once a card has 0 durability left it can't be used. 
Development Milestone 1 - Damage Priority Logic (Completed Sunday November 24th, 2019)
After battles, the monsters damage the players equipment. Most monsters damage a specific number of items, and have different priorities for how they choose. Some examples are: Rarity, item slot, and how much damage its sustained already. This was implemented as a bunch of different classes that implement the IComparer interface in C#, which are then chained together and given all of the players equipment. Unit tests were written to test different cases. These different behaviours can be used to configure enemies behaviour down the road.
Development Milestone 2 - Combat Logic (Completed Monday November 25th, 2019)
In the game, players can equip 2 rings, 1 amulet, 1 body armour, and lastly, either a two-handed weapon, or a one-handed weapon + a shield. The players attack must meet or exceed the enemies defenses, and the players defense must meet or exceed the enemies attack. With just weapons and armour this is trivial, however jewelry stats can be split freely between attack and defense. Furthermore: weapons, shield, and jewelry can all have wild symbols, which can create some very interesting situations where it's difficult to determine wether or not a player satisfies the requirements.
I approached this with test driven development. I wrote increasingly more complex test cases for combat situations until I'd built up a comprehensive system that worked for all the scenarios I could think of. You can see the test cases here. I could think of a lot of shortcuts, but in worst case scenarios I couldn't find a way to not brute force jewelry stat allocations to see if the battle can be satisfied. Since I'd have to do this in the end, and the runtime wasn't bad, I skipped implementing any shortcuts for now, and I'll only add them if it becomes necessary down the road. The algorithm I settled on is the following.
- Sum up the stats of the body armour and the shield as the players defense
- Sum up the stats of the weapon as the players attack
- Sum up the stats of all jewelry as the players floater stats
- Move all attack only stats from the jewelry to the players attack
- Move all damage only stats from the jewelry to the players defense
- As a quick check to see if it's simple - allocate all jewelry stats to defense and see if the player can win
- Calculate how many stats the player's attack is missing to overcome the enemies defense (attack_deficit)
- Try all combinations of stats from the jewelry with the size attack_deficit, add each of them to the players attack and the rest to the defense and see if the battle is satisfied
Combat is largely completed now - the only things remaining are quickly handling weapons that provide defensive stats, and implementing all of the unique items with unique behaviours, but that will happen at the very end.
Development Milestone 3 - Card UI (Completed Sunday December 1st, 2019)
The only way to get assets for the card game was to scan them in myself! Here's a variety of cards I grabbed using my scanner at home. These cards were selected because it gives a card of each rarity and each item slot.
My co-worker helped me to remove the text, stats, and item images from the cards using Photoshop's context aware fill feature in order to get the base cards.
I then exported the individual stat icons, the "active" version of the equipment symbols in the bottom left, and a hole punch in order to create a sort of "rig" for a card in Unity. It looks something like this.
The last step was to be able to pass an Equipment object in code to the card view and have it render. At this point I quickly threw together a rough data configuration system where I can edit item data using a spreadsheet editor, but I'll gloss over that ;) Here's an example of four cards being rendered in game.
The next milestone is writing a quick persistent inventory system.