Design Process Documentation

Title: Tarot Academy

Team members: Jasmine, My, Percy, Emily

Game description:

We are designing a 2D Turn-based Tarot Card Battle Game. This game is designed for 2 players. This game could be played both in physical deck and on digital side. 

In this game, we made a lot of changes from the Original Waite Tarot cards, and designed our own deck, as well as the whole new battle rules. Each player chooses from the two characters, either the Sun or the Moon, as their profile, and begins battle by randomly drawing 5 minor Arcana from the deck. In our game, the two players against each other need to solve the restrain cycle between different elements and calculate their hand points in order to find the right strategy to attack their opponents.

List of systems inside of the game:

• Card element system: 40 minor arcana cards will be labeled as four different attributions, which are torches, cups, swords and pentacles. Each element includes 10 cards. Torches are the representation of fire, so the deck of torches are depicted in red color and the icon of torch. For the same reasons, cups(water) are in blue, swords(wind) are in green, and pentacles(earth) are in yellow.
• Restraint cycle system: The four attributes have a cycle of mutual restraint. The restraint cycle goes this way, water (Cups) will restrain fire (Torches), fire (Torches) will restrain wind (Swords), wind (Swords) will restrain earth (Pentacles), and earth (Pentacles) will restrain water (Cups).
• Attack value system: There are 40 minor arcana cards in total - 10 for each element, with values from 1-10 on each card.
• Battle rules system: Same/normal (any card that does not restrain nor is restrained by the attacker card) element drawn on defense: 

• Bigger number: the value of the other attacker’s card is decreased, whatever is left is dealt to the attacker’s health 
• Same number: both cards gone -> end of turn
• Smaller number: value of defense card is decreased, whatever is left is dealt to the defender’s health

• Restraining element drawn on defense: 

  + Bigger number  or equal to opponent’s card: Decreases the value of opponent’s card, whatever is left is dealt to the player’s health

+ Smaller or same number than opponent card: both cards gone -> end of turn

• Restrained element drawn on defense:

• Doesn’t matter what number -> player’s health is affected by full attack value. 

UI Design System:  

• I researched UI Design Systems and what made them particularly effective and tried to implement them into Tarot Academy based on the below information

https://medium.muz.li/creating-a-ui-component-design-system-step-by-step-guide-5...

Color palette :                                        Components:                                       

Icons:

Challenges

We had a hard time trying to map the systems we designed. The scoring system with combat is the most difficult to understand when we are trying to convert it into numbers, values and statements. Even after we logically understood the structure and the concept of how to develop the game in code, we are still quite lost in a little bit on how to write the codes in detail.

Although the coding process was a bit of a struggle, the end result of the cards, UI, and overall game-feel were well accomplished. To begin, the rules of the game were well documented and through several playtest sessions, we successfully balanced the card physical card game to feel like something fun. Once play testers got the hang of the rules, it was interesting to see how they changed their strategies to attempt to win. Another really lovely aspect of the game was the particle system added to the button to help the UI feel more responsive. The star sprites in the particles were constructed with the UI’s star themed backgrounds in mind. Each iteration of the game became more and more cohesive towards the end, which was really enjoyable to see.

Describe what you might do differently

All in all, we spent too much time trying to plan and design the rules of the card game. Initially, we were toying with various ways to create the game, considering a purely physical game or an AR game. With feedback and advice, we realized that these ideas may have been too ambitious, so we scaled the project down to try just to make a digital card game. We only started to code the project in the last two weeks before the deadline approached, which proved to be a big mistake.  In the future, we would like to conduct more cohesive research on how card game's function and how difficult digital card games are to code before attempting to map the systems and code. That way, we would be more prepared when building and coding Tarot Academy. If that was achieved, we would have had a better time management organization. Next time, we could create some visual effects/animations that occur after the two cards battle, make separate controllers (keyboard and mouse) for each player and opponent, and possibly add clashing battle sound effects.

Jasmine’s part:

In this project, I took on the role of a pure art designer for the first time this semester. Previously, whether it was an individual project or a group project, I have always put more or less of my energy and time into programming code and solving Unity implementation problems. Fortunately, my team members, who had been more of an art designer in previous projects, took on the programming responsibility for similar reasons. I am very grateful to them. I also trust their abilities, and they really put a lot of time and effort into programming, which is all there for us to see.

Let's move on to some of my own specific contributions to this project. I was mainly in the role of art designer. In our game, there are 42 cards in total. These 42 cards, including two-character cards and 40 number cards, were designed and drawn by me personally. Our game is inspired by the Tarot cards, so when I designed our game's own cards, I referred to the Tarot system and borrowed some basic elements. For example, the general tarot deck has four elements in its numbered cards: the Wand, the Cup, the Sword and the Pentacle. In the deck I designed, I kept the last three elements and changed the Wand to the Torch, out of my personal preference and because the torch is more expressive than the wand when drawing. Then in the design of the figures the original tarot was with four more figure cards, that is, the king, queen, knight and squire. In our game, since we don't need these four figure cards to appear, I removed them. In the deck I drew, each element contains only 10 number cards, from one to ten. In other words, I made a lot of adjustments to the original system of the Tarot that had to be adapted to our game's own rules. Here is a small detail, I decided to divide the four elements into four very distinctly different colors before drawing them. This way the player can see at a glance which element the card they drew belongs to. Then on the two-character cards, we discussed and decided to make them the very classic Sun and Moon cards of the Tarot. I adopted the same art style and design elements for these two-character cards as I did for the other 40 cards, achieving a unified style for all the cards.

Next, I want to write about some of the challenges I faced in drawing the deck. This deck of 42 cards went through a total of three versions of changes, and it obviously didn't get through all at once. Because there are 42 cards in total, all three versions of the changes actually had a significant amount of work. The first version I submitted was considered by the group to be too slim. When it was put into the game, the player couldn't see the lines on the cards. To solve this problem, I made the lines of the 40 cards thicker and added more color blocks so that they would be clearly recognizable to the player even after they were scaled down and placed on the computer screen. This was the second version. But then the second version ran into problems again. Since the size of the numbers on the cards in our rules would determine the player's victory, in the second version of the cards, our group discussed that a very prominent number should be added, so that the player would not have to read the text on each card as it was drawn. So in this version of the update, I drew another numbered corner marker for each card and scaled them to the right scale size and placed them in the upper right corner of each card. The third version was finally unanimously approved by the entire group. They presented very well on the computer screen, and the printout was legible and playable.

Then it’s the software and technical tools I used to draw. I used a drawing software called Procreate on my iPad, which allowed me to quickly adjust colors and overlay textures. I used Procreate for every icon including the border and the back of the card. For the final layout of the deck, I used Photoshop because it allowed me to be more efficient.

Finally, I would like to talk about some of my own feelings during the process of making this drawing deck system. I have to admit that drawing can make me feel very happy, and I feel very proud of my work and the effort I put in when I see the result of the whole 42 decks of cards being displayed. My friends commented on how playful, classical and mysterious my deck was. I feel very honored to have received such comments, and although I was not involved in the coding this time, I was there in the group discussions during the early rules development, and we eventually came up with consistent rules. At the same time, I also saw my group members put a lot of effort into other aspects of the game, and I'm grateful to be able to work with them on this theme that we all love so much, Tarot Academy.

My’s part:

We worked on the game rules as a whole team. My task in the team was to mainly to code the project, playtest and debug. In the first week I worked with my team to solidify our ideas regarding the game content and rules. We playtested our game the first time the following week and made changes, then Emily and I met up to playtest the game some more and tweak the rules the week after that and finally started writing codes. We unknowingly dug our own grave when we dove headfirst into this assignment.

I purchased some fancy effects and UI assets from Unity in the beginning so that we can use them in our project. However, when I made our first git repo and shared the assets with my teammates, the git was taken down two days later because it violated the EULA agreement (the assets I purchased was not supposed to be shared with other individuals), and that marked the beginning of my rocky journey.

Responsibilities

I divided the scripting tasks up so that Emily and I can work on them separately and save time. I mostly maintained/put things together in the Unity scene and made the layout mockup for Percy’s UI. I wrote the scripts for shuffling the cards, dealing the cards, refilling the cards, choosing the card to fly to the battle arena, displaying player health value, the list of cards with attributes and the conditions for the battle phase. Initially, Emily was working on the card choosing script but it didn’t work so I took over and fixed it.

Systems

To create the system for shuffling and dealing the cards, I created an array where I assigned each of the card game objects to and the 10 positions on the hands they would move towards. Then, I used System.Random() to randomize the order of the array and made the first 10 cards move towards (appear at) their designated positions. The Refill Card system supposedly will pass out cards at the empty slots on the hands whenever the hand has 3 cards on top of it. The problem is we don't know which card from which position will be used when the player battles so I attached 10 colliders to the 10 slots on the hand and whenever the colliders are not colliding with a game object tagged as card, the player can click the refill button it will refill the cards on those empty slots. To determine whether the slot is empty or not, I used OnTriggerStay() with an if else statement (if colliding with card being true and else being false - I know, it already sounds problematic but I don't know any other way to detect null collision.) When that doesn't work out as planned, I switched to using Unity Overlap Collider to detect the number of colliders on top of the slots. However, it always returned a result of (0) even when the card object colliders are on top of it (I made sure to set trigger to true for the colliders and tagged everything correctly). 

As for the choosing card system, I used OnMouseDown() and Lerp functions and attached the script to every single card to make them move from the hands to the battle arena. I forgot to make a condition to prevent the players from being able to click on the cards in the face down deck, but if I did I would make an if statement to check the position of the card (not clickable if the position is the same as the deck). I also tracked the collision of the cards on the hands to determine which hand the card is colliding with, if it is the left hand then it flies to the left position and vice versa. 

After I wrote the scripts for the list of cards with attributes, I didn't get to the point of connecting it to the battle phase because I didn't know how to access those attributes from a different script with if statements. However, if I did, it would look something like this: 

void Defense()

    {

          if (cardA.cardElement == "Cups")

          {      

           if (cardB.cardElement == "Cups" || cardB.cardElement == "Torches" || cardB.cardElement == "Swords")

                    {

                        if (cardA.cardValue >= cardB.cardValue)

                        {

                        currentPlayerHealth = currentPlayerHealth - (cardA.cardValue - cardB.cardValue);

                        }

           }

}

}

That's just an example of how it could've looked like. However, we didn't get to that point. When Jason demonstrated the battle system for tracking the turn for us and cutting down the game rules, it made the game simpler and cleared up some of our questions for how we would have the game play out. With whatever time we had left before class, since I still didn't know how to access the card attributes, I changed the winning conditions when comparing the 2 cards to this: 

string p1 = player1Card.name;

string p2 = player2Card.name;

int aWin = 0;

int bWin = 0;

        for (int x = 1; x < 11; x++)

        {

            if (p1 == "cups" + x)

            {

                for (int y = 1; y < 11; y++)

                {

                    if (p2 == "torches" + y)

                    {

                        Debug.Log("player1 won");

                        aWin = aWin + 1;

                        Debug.Log(aWin);

                    }

                }

            }

void Update()

    {

        if (aWin == 5)

        {

            player1Win.SetActive(true);    

        }

        else if (bWin == 5)

        (   

            player2Win.SetActive(true);

        }

    }

I basically tracked which element the current card on the battle arena is using its name. Whichever card has the restraining element wins over the other one. Whoever reaches 5 wins first wins the game and the winning screen appears. Even though I had the script working for displaying player health value, I could only display it for one player and not the other, because for some reason the text refuses to show up when I make a public variable to attach a Text from the game to it. So I decided not to display the players' health value anymore. 

Aside from the systems in the code, I also worked with the team to come up with the restraint cycle and battle rules of the physical game. In the beginning I set the rules as the attack card can only lose points if the one defending restrains it, however this made it really hard for both sides to lose any health so Emily and I changed it so that as long as the defending card is the same or a neutral element, it can deduct points from the attack cards. 

Problems

My several first problems were I didn’t know how to implement the card attributes & shuffling function we have in our physical game in the Unity world. I looked online for solutions and tutorials but not all of them can be applied to our game. I got the deal card and shuffle buttons barely working by returning a random value in the card array and making the cards appear on the designated positions on the hands. I also made a class to store all the cards’ attributes. However, the scripts proved to be rather lengthy and inefficient so John helped me restructure them and fill in the missing parts later on.

The second problem was the refill button.  I spent 12+ hours testing different ways to see what was the problem and fixing the button. Despite my efforts, I couldn’t figure out what went wrong and how to resolve it. I was determined to fix it by myself because I thought the game won’t be able to move on when we’re unable to refill cards when they run out. I guess the key takeaway here is that I have to know when to step back and move on with other tasks.

The third problem was I didn’t know how to access the card attributes from the Card class. I only pieced together the use of lists and classes for the attributes after watching online tutorials and John’s help and I also didn’t know how to mark which player’s turn it is both conceptually and coding-wise. When Jason introduced to us the switch-case statements and the use of lists & dictionaries the overall coding structure, it made things a bit more clear conceptually and I went home and looked at how to piece everything together. Of course, it still didn't work out because I couldn't find the solutions to my specific problems. When I looked online, there were tutorials on making objects have attributes in a class but they were using different complicated methods to access it and I don't understand their methods. 

Aside from the huge chunk of the coding problems, I feel like our team would have benefited from better task division. Throughout this project I felt like I was handling most of the hard tasks for the team and even went beyond my own tasks to help other members with their tasks e.g. fixing the UI buttons, making the initial layout for the game UI, making the end screens, creating most of the scripts needed for the game, fixing others' scripts. Emily and I also came up with the idea for the trailer the night before class and we shot and I edited it. We didn't plan well in the first place and didn't have a list of tasks and deadlines to manage the project. This led to the problem of everyone trying to make changes at the last minute in the same git version. There were tasks that I feel like could have been done outside of our coding problems and not at the very last few hours before we have to present in class e.g. adding animation to the start screen UI buttons. Maybe it was also due to a bit of miscommunication that led us to having this problem. 

What I enjoyed and what I would do differently

Next time I would definitely divide the tasks more evenly between my teammates and work on communicating better. It was perhaps partially my fault for not asking for help more from my teammates even though I did mention my concerns of not being able to figure out how the codes work. However, for this particular project, knowing my teammate's specialties and abilities, I'm not sure if we would be able to come up with a solution even if they chimed in to help. This leads to my next point: better research. Maybe if we had deeply researched how to make a card game earlier before solidifying the game rules, we would know to step back and work from our own constraints of what we know and not know how to do. 

Through all of the struggles and hardships that this project brought, I still enjoyed some of the process. Shooting and editing a trailer at 5AM was actually quite fun. Because it was so tedious to find a solution to a problem, once I got the scripts working I felt immensely fulfilled and relieved. Thanks to this, I now have gained exposure to more intermediate-advanced coding concepts that I normally would never touch. I feel like I can see systems a bit more clearly after doing the majority of the codes for the game and my logic is more solidified and less abstract. I also have troubles articulating my problems, and thanks to this project, I am now more aware of it than ever. Sometimes it takes getting unexpected hits in your most vulnerable spots in order to improve. The whole time I worked on this I felt like a model wearing a dress that doesn't compliment her form, but at least now I'm aware of the things that went wrong and hopefully in the future I can learn from my mistakes. 

Percy’s part:

I was in charge of the UI and Sound Effects of Tarot Academy. In the beginning of the process of planning this project, all of the team members of Tarot Academy chose to make all elements be in black and white to help the different art styles look more cohesive in the end result. As the project further developed, this concept was changed in favor of a more colorful layout in order to match the cards that Jasmine had begun making in a more colorful color scheme. The UI was created in Adobe Illustrator and Procreate.

For the UI, I implemented a  button click system to make the UI be as intuitive as possible. The components of this system are mouses, clicking, sound effects, and a shaking animation. The user clicks the mouse on the button, which then triggers the button clicking sound effect, shaking animation of the button, as well as a star explosion. Then after this feedback to the button being clicked happens, the user is then taken to a different screen. Other systems implemented were a sound system with a simple user interaction that allows the user to click on the sound button to remove the background music. All icons for this were hand drawn in Procreate as well.

Several challenges surfaced when attempting to implement a button clicking sound. For some reason, when the button was pressed, the sound would not play although it was pressed. After thinking about it for a while, I realized that the scene changer script acted before the sound had a chance to play. To fix this, I coded the scene to change after a delay that I set in the Editor. This effectively solved the problem, allowing a one second delay to let the animations and sound effects play. Another challenge faced was the lack of communication between team members. Often, other members would begin working on the project without telling anybody, resulting in loss of progress. Also, seeing as though key coding components were missing for a majority of the project, we were being asked to create assets for aspects of the project that didn’t exist yet. This was confusing especially because there was nothing to implement these assets to.

In another scenario, I would have emphasized communication between all team members as this was a constant issue. Communication is important when working on group projects, and I believe that this may have been a key contributor in most of the issues that came up. It seemed like although the coding might have been a bit difficult, the code team were figuring it out and dealing with it accurately, although it may have been more difficult than they had let us know. We only knew how truly broken the game was in the last week.  In the future, I would also make sure that there was a strict schedule being set for each member to have deliverables by. Things were being put off until the last minute to figure out the main components of the game, and this would not have happened had there been a timeline to adhere to. I would also have ensured that the main coding components of this game had been thoroughly researched before even attempting to implement them so we could know the scope and what was achievable. 

During this project, I enjoyed creating all of the assets and experimenting with Adobe Illustrator, as I had little to no previous experience with it. I researched a lot of UI elements and used a few codes that I had never tried before, which made me feel more accomplished. The music control button was an aspect that I had never used before in previous projects, so I enjoyed implementing that and having it be functional. I also enjoyed finding cute button clicking sounds to enhance the user experience and add to the overall fun and adventurous aesthetic of the game. I wanted the feel of the game to be fun and adventurous, like most card games. With the tarot theme, I wanted it to have a fantasy feel to it, as if you’re in a Japanese Isekai playing cards at the tavern. I believe that with the color palette and background music, I have successfully done so.

Emily’s part:

I am working on this project with My as a coder, a play tester. Systems we used in the game are implemented by remeasuring physical elements of a card game and logically think and design them in code through assigning them with new values, statements and datas. It was a big challenge for both of us because our game includes different phrases, 4 constraints, number values assigned to cards, defining terms with two players, combat systems, etc. We had a really difficult time mapping the game system and got stuck on this idea of how two players enter attack or defense phrases to how combat works etc. The combat was the most challenging to map and understand. I did a lot of research related to almost every element we need to code including dictionaries and lists, etc but it was hard to understand the concept of how to code it. At first, I replaced physical cards that players hold in their hands into ui buttons that players can select with different keys and mouse when dealing with how players make selections. Making physical cards into ui buttons can help one player easily navigate through a shared screen while they are battling against their opponent (the second player) who is using the mouse as a controller. UI buttons also have a default built- in input along with the arrows so the player can easily press the arrow keys to go up, down, left or right, but I disabled the default input and even thought about creating a new input system to avoid two players using the same controller. One player could press shift to make a selection after they see the card options. The opponent can use their mouse and hover over an object, when the game object detects the mouse, it shows the border highlights to true to present a selecting animation, when the mouse is not hovering over the object then sets the border highlight to false. Only clicking on the object with the mouse will have the highlight border stay and trigger it lerping to the battlefield in the middle. In lerping, we wanted our game object to move (“fly”) to the battlefield by using” local.position” to calculate the previous location of the card placed then transform it to a new place on the screen. There, the first step for card selection worked. However, My and I didn’t talk through this thoroughly first--we had different methods of defining cards in the game. My implemented each card as a game object since there are different datas and rules designed in the game system that logically making the cards a game object rather than a button is a better choice. There, I discarded my older code and tried to write a new code that references two different types of controllers on the cards as game objects. I had a hard time trying to use Ray cast with keys to a game object, there we decided not to have key selections because using the same mouse as a controller is easier to code throughout the game. Then I did dictionaries and lists after learning how it stores data like a json file for every card’s value and restraints. It was an interesting transition to think mathematically transferring restraints into numbers too. But then we didn’t know how to use the Datas. Although My did most of the code, I tried my best working and helping her as we worked on the scripts together and debug. I learned a lot from My although we both struggled with code, I got a better concept on how to map logic into code and ways to approach systems when we are designing it in a physical game compared to a digital game. I took a lot of notes and documentation on how to fix some bugs we had in the game as well during playtest. 

Playtest Feedbacks & Revisions:

Week to week schedule of predicted milestones:

Week 1 + 2: (due date Nov 30th) Final pitch + prototype

Week 3: (due date Dec 6th) Demo beta + playtest

Week 4: (due date Dec 13th) Finished Game + Documentation + Postmortem etc.

(Initial thoughts, changes were made during the design process)

Battle system:  When the battle begins, there are 22 major arcana for players to choose as their “heroes” with special abilities. The rest of 56 minor arcana cards will be labeled as four different attributions- wands, cups, swords and pentacles. The four attributes have a cycle of mutual restraint. The restraint cycle goes like this : water (Cups) will restrain fire (Wands), fire (Wands) will restrain wind (Swords), wind (Swords) will restrain earth (Pentacles), and earth (Pentacles) will restrain water (Cups). The attacking sequence is decided by the sum of all the major arcana in one player’s team,and the one with the smaller sum goes first. When one attribute gets restrained by the other, the attack value on the card will be reduced by the attack value on the other card. After calculation on all of the cards, the remaining attack value will be executed on the major arcana.

Cups > Wands

Wands > Swords

Swords > Pentacles

Pentacles > Cups

Special ability system: 

The health value of each arcana is assigned in the parenthesis. Each round, the player can only choose one of the special abilities from all the three major arcana.

1. The Fool (20) Pull a new minor arcana from the deck, and replace it with one arcana you already had in the magical spread. What if this happens to the opponents?
2. The Magician (15) Switch one arcana in the spread with one from your opponent’s spread.Wait read the parts at the end of the document - we’re changing the major arcana
3. The High Priestess (18) Hide one arcana from your spread, show it when your opponent finishes attacking. Your opponent can’t attack the hidden arcana.
4. The Empress (25) Make the value of one of your opponent’s arcana equals to one of yours.
5. The Emperor (25) Make the value of one of your arcana equals to one of your opponents.
6. The Hierophant (10) Change all the values of your minor arcana equal to their median.

Roles: We are all sharing the art and drawing cards, as well as constructing the rules and balancing the different major arcana.

Jasmine:Minor and Major Arcana cards, Pitch

My: Code Developer, Playtester, Trailer, Debug, UI fix

Emily: Code Developer, Playtest Facilitator

Percy: UI, UX, Audio, Postmortem Editor

Challenges: The balance between 22 major arcana with their special abilities. The game build on Unity code-wise (balance)

Feedback from John:

The game has to be digital--

AR game? Challenges like space, lighting, phone build

How to make mechanics on having other players not knowing player’s card 

Multi-monitor? 

Maybe a single player fighting against the “enemy” we designed? ( Facing AI challenges)

Firebase data base resource - multiplayer 

See all possible combinations 

Buttons-controlling different sets/control 

Guessing the special abilities/power of the heroes maybe until the player pressed the button

Two monitors?

Feedback From Jason:

You all are in a rougher spot because you’re in the process of balancing the desire for a card game and the challenges of digital. I think your biggest challenge is going to be coordination and integration into a single project. You all will need to work together to make these real.

It’s not easy to make a digital card game. So my main advice is actually to simplify this game intensely, and then simplify it some more. This isn’t the last time you will work on a project like this, and you don’t have to accomplish everything all at once. Instead, focus on a very interesting core that you can control. This is a strategy to make sure you can accomplish something that you’re still satisfied with without being lost in a massive project.

---

Going a little out of field for a moment:

This is something I want you all to think about: https://youtu.be/NU29QKag8a0?t=805

The whole talk is worth watching, but this is about making prototypes that sell us on good ideas. This particular section is about faking it till you make it. Make interactive scenes! Go super minimal, use your artistic abilities to sell us on game moments.

My thinking is that this will give you a way of leveraging the considerable creative ability that you all have individually, and then work towards bringing them together.

I bring this up because I want you all to consider making an anthology. Make a collection of minigames that capture the spirit of the Astrologer pitch. Make minigames that capture the different scenes. 

For example your tarot game might be simplified into a rock paper scissors game played with the major arcana. And your school life can be a tea swirling minigame (to read the tea leaves for fortune telling). Or you can have a quick clothing picking scene. And use them as a collection to represent a “day in astrology academy”

This would let you use digital methods to prototype and experiment with the game ideas that you have in this document. Because as is, I think there is the possibility for a compelling card game, but I’m not entirely sold yet. Perhaps heroes can have different days of different minigames?

I don’t know your full enthusiasm for going into a very technical expiration of an AR game or online game, so I offer the above suggestion as just that, a suggestion. 

Coming back to the original idea, I still like the idea of a game that is played on the digital space and supplemented with the physical cards. But I would need to see a lot of extra design work done for it. 

For this kind of game, I wonder if you can create a kind of speculative battle system inside of the digital game. Maybe there’s something like a War simulation that you set by playing the card game? You choose which characters have to battle on the digital side by playing the card game and then you deal out “damage” on cards after the digital game finishes. Sort of like rolling dice to determine damage but with a simulation that is more than rolling dice. 

That way you could have a set of characters that are “in” the Unity game that lets you choose how they fight by setting the cards down in a particular way. I am not sure--hard to say without knowing more about your card game in detail.

I see a heavy emphasis on art, but not so much on integration. That makes sense because we’re still not sure what that art would be integrated *into*. So we definitely need to figure out what the digital element is going to be before continuing. Otherwise, you’ll have a great art collection but not a great game. Get together and think about how digital elements can augment your game in ways that aren’t using cameras. My advice there is to avoid the lens approach to AR and start to think of them like random number generators or something.

I want you all to succeed at this, but it’s hard for me to say where you’ll end up. Would love to chat further about this during a one on one.

Changes: 

There are 40 minor arcana cards in total - 10 for each element, with values from 1-10 on each card.

There are X major arcana cards, each with a different ability. The players can choose which card they want as their character from the start of the game. Everyone starts out with 20 health. 

In the beginning of the game, each person gets 5 cards in their hand. They can take 2 cards from the pile to refill when they have 3 cards on their hands at the end of a turn. 

A turn consists of one person attacking and the other defending. Player A attacks first and player B has to defend. This is one turn. Then, player B attacks and player A defends. This is another turn. 

At the end of a turn, 2 cards that were used for battle go to the discard pile.  

Win state: Whoever runs out of health first loses the game and the other one wins. 

Battle rules:

• Same/normal (any card that does not restrain nor is restrained by the attacker card)

 element drawn on defense: 

• Bigger number: the value of the other attacker’s card is decreased, whatever is left is dealt to the attacker’s health 
• Same number: both cards gone -> end of turn
• Smaller number: value of defense card is decreased, whatever is left is dealt to the defender’s health

• Restraining element drawn on defense: 

  + Bigger number  or equal to opponent’s card: Decreases the value of opponent’s card, whatever is left is dealt to the player’s health

+ Smaller or same number than opponent card: both cards gone -> end of turn

• Restrained element drawn on defense:

• Doesn’t matter what number -> player’s health is affected by full attack value. 

Major Arcana change suggestions to fit more with our tarot theme (because the cards have meanings on their own outside of the meanings we give them)

• The Hanged Man (original meaning: delay, restraint, unable to progress): The opponent cannot draw a new card from the pile in this turn OR the opponent cannot attack for the next (1) turn
• Death (original meaning: end, loss, transformation): The opponent has to abandon their current deck and get a whole new set of cards from the card pile. 

• Steal opponent's hero power from them once?
• Divination : Look thru the top 3 cards, choose 1 to swap with 1 of your current cards and place the other 3 back in the pile in whichever order you want

Pseudo-code for how the turn works:

*Battle begins when 1 card from each player flies to the deck. Player A always attacks first in the beginning. When it’s player A’s turn, only player A can select and choose a card to send to the deck and vice versa. Player A’s turn is finished when they send a card to the deck and now player B can defend. Right after, it’s player B’s turn to attack.

For the system to determine which card is attacking and which one is defending: 

Step 1: put a collider onto the deck area sprite and tag the deck area as “Deck”

Step 2: put colliders on the cards and tag the cards as “card”

Step 3: if the deck is not colliding with any object tagged as card -> the card that flies onto it is attacking 

Step 4: if the deck is colliding with an object tagged as card already -> the card that flies onto it is defending. 

UI: 

First iteration ^

notes

If ( void ontriggerenter 1 object tagged as card ) 

{ attack bool (state) = true; }

{ void ontriggerenter 2 objects tagged as card){    

       //labeling this as an attack card?

 attack bool (state) = false (defend mode on);

}

If (attack bool == false) { defend obj = object tagged as card now has Defend layer attribute }

If (defend obj has = or > element 

Battle time: 

How do we make attributes or assign attributes to our cards? 

Has some physical reality - how did you map it to code? 

Systematic representation 

Adding special abilities to the minor cards themselves

Feedback from John and Jason

A visual representation of the 

Every player plays twice : play an attack → defense---> attack

Just check the integer of the cards the player has left other than the play area define 

Jason : 19

John : 14

Players forgot their turns 

It is not interesting as the player can predict the moves of the opponents --add more abilities 

Card particle effects*

There isn’t much to do when the player only have as much cards they have* 

Before i knew more cards are coming, i am strategy --try to get as much damage as i can get of the enemy

Limit the amount of card take(2) to shrink the play time 

Refilling should be a choice ? 

High # of information and they don’t need to worry about the amount of cards needing to refill 

Players can sacrifice the turn to refill their cards as a choice?

Add more health on the cards or what does it do more? More health and less health  

Final Words:

What's working is the UI, audio, illustrations, and a lot of code. We all worked hard on Tarot Academy. We also made really lovely looking physical tarot cards and it was cool to be able to visualize the cards that Jasmine made. The documentation is very fleshed about and detailed, and an accurate representation of what we had to go through to construct what we have.

You should play Tarot Academy if you love playing card games like Pokémon or Yu Gi Oh! With the tarot theme, it is easy to play this game without having to buy the deck that we've made. It's accessible because it has a digital form, but is also completely able to be played outside of the digital version. If you enjoy playing battle card games, or just love tarot themed games, you should play Tarot Battle Academy!!