Develop Trading Card Game Battle System With Unity 3D: Part XVIII (Command System, Decision Making) | Vladimir Limarchenko | Skillshare

Develop Trading Card Game Battle System With Unity 3D: Part XVIII (Command System, Decision Making)

Vladimir Limarchenko, Game Developer, Unity3d and C#

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
3 Lessons (45m)
    • 1. Command System – Scripts of Individual Commands

      15:15
    • 2. Decision Making in Dragging Scripts

      15:01
    • 3. Testing Card Draw

      14:39

About This Class

In this class/series we set an ambitious goal of developing our own trading card game with Unity3d and C#, mostly focusing on card game battle mechanics.

In this class you'll find a more detailed overview of the “Command system” that we use to transmit info about the events that happen in the logical part of our game to the visual part of the game. After we have the list of commands, we can re-produce them in certain order and show all the outcomes of our players' actions to them visually. We'll take a closer look at individual commands for:

  • Drawing a card
  • Starting a new turn
  • Updating the amount of mana crystals in the mana pool
  • Attacking with creatures
  • Showing an end turn message.

As a rule of thumb – we should use the system of commands and write a special dedicated command for every single event in logic that might have visual consequences in the game that:

  1. last for a certain amount of time (not instant)
  2. or happen instantly, but should happen in a certain order relative to other events

This class also contains a ton of useful information on decision making when we drag our cards or creatures. And we'll finally get to test the results of our work – after some minor adjustments we'll get to test card draw and control the way the cards travel from the deck into our player's hand.

With this class you will gain access to a compete, fully functional Unity project that is an example of a card game battle. The game mechanics are somewhat similar to Hearthstone: custom spells, hero powers, creature effects and so on.

Additional information:

  • The files showed in the course are downloadable from the link that you can find in the "Class Project".
  • The next class of this series will be published on 2017.01.13.

Transcripts

1. Command System – Scripts of Individual Commands: Hello, everyone. And thanks a lot for watching the scores in this lecture. I wanted to have a brief discussion on our command system. So you've already seen this glass? That is cold command. And the main feature of this class is that any other class that is also a command. So any class that will inherit from our command class will have a method that is called at two Q. And this way the command will be added to this static que off commands. And then this command will wait until it is time for it to be executed. And I wanted to take a look at all the other scripts that are also commands that inherit from this glass. So I've opened a couple of these glasses in my motto develop and for example, let's open this first glass draw a card command. This comment is actually unnecessary right now. And I think that this private interred your I d is not used in this command as well. So I can do eat this line, and now everything's fixed and we have a very common structure for our command. So even though our command class doesn't have all these private fields Player P card logic cl these fields. They're specific to this drawer card command class and in our constructor for this class. So each off our command glasses will have its own constructor. We want to initialize all these fields. So our draw a card command constructor will take as an arguments all the values that we need to assign to these private fields and inside of this constructor will do just that. And then the only method that will be unique for each command is cold start command execution. So it will contain all the code that we have to execute When the order in our command que comes to this command. And another point, it's mostly about the philosophy off working with our command system. For example, if we have a command that is called draw a card command, it means that when this method start command execution is called. In our logic, the card is overly drawn. So at this point, in our logic, everything has happened. We already have this object that is called card logic. That represents the card that was already drawn. And this command is Justin means off telling to the visual part off our game that okay, we have already drawn a card, and now it is time to show this to our player. So commands there just the means off communicating what has happened in our game logic and then showing it to our players in the visual part. Off our game and inside off this method, we have just thes two lines in the first line. We are accessing our players deck. So our player, which is our player in game logic, he will have a reference to Hiss player area that will contain all the references to the visual stuff that this player has among all the visual stuff will have a reference to our players deck and the deck is a very simple script that will control the thickness off our deck in the scene. So when we draw a card from our deck by saying cards in deck minus minus will show to our players that the thickness off our deck became a bit smaller and the second line will excess our hand visual, a reference to our hand visual will be also president in our player area and we'll call a method give player, a card on our hand visual and well past all the information from this drawer card command into this method and to work with our commands. Let me just open our player script to remind you how this works in our player script. I want to find the method for drawing a card, and there we have it. So it's a method for drawing a card. There are several checks, but we are interested in this blast part that says, Create a command the syntax for creating in you command and adding it to a Q is saying New drawer card command. And here in these parentheses, we have to list all the arguments that our constructor for this class has, and then in the end, it is very important. We have to put adult here and we should say at two Q so that this command is not only created, but it is added to our acute. So it is now a waiting for its execution, and then when the order off execution off our commands comes to this command, for example, our drawer card command this method start command execution will be cold. And for this drawer card Command. We're not calling a method command command execution complete here because we want to wait until this whole process off drawing a guard is complete. And only then we want to switch to another command. But it's not always true. So I'd like to show you some other commands that might use a different approach to moving to our next command. For example, who have this command? It is called start, turn command. And the reason for having a start turn command in our project is that we want this event off. Starting in, you turn to be incorporated in our system off commands. So it should also happen in a certain order. For example, if we are currently playing some effects like damaging our opponents, creatures and attacking and everything else during this time that all these effects take place, we want to wait and only then we want to start in u turn. Unlike our previous draw a card command, this command will have just one private field that is called Player P. So it's constructor will contain just one argument. It has to initialize just this private field wishes our player and inside of this method start command execution. We have just one meaningful line that says turn manager Instance Who? Stern Equal speed. So the point of this command is to wait until all the other commands are executed and they're shown to our players. And only then we have to start our next turn. And actually, with this command, we're doing something different. So with all the other commands were usually accessing our visual part in this start command execution. And here we are, making something with the logical part off our game. Instead, one thing that comes to mind, I think in Harsh Stone they don't do this. But there was this card that was coldness door, which is a dragon. And it made it so that the players only have 15 seconds to make their turns, which is not a lot. And once played, this card sometimes caused one player to miss history entirely. So if you blame his dorm room and then you feel your turn with different actions that have to be shown, then the other player doesn't have an opportunity to play his cards. And in our project we won't have this problem because we are starting in u turn on Lee after all the events from the previous turn have played. So you have to be attentive with your turns because playing with them may sometimes lead to unwanted behavior off your app. And another important part of this script is that here in the end off our method were saying command execution complete. We don't have to say command dot Command execution complete because our start a turn command is already a command. So this method command execution complete is actually located in this same class. So we can just call it like this And it means that the only points off having things command is to add this command to our Q and it will not actually last for a certain period of time. This command will just be executed instantly. Then we have some other commands. For example, this one is also instant. It is called update Mana crystals Command. So this event off updating our manic crystals will also happen through our command system. And it will mostly affect our A i player. So when our computer roommate, his Stearns after each turn, we will see that on Lee. The amount of Mana that he used this, Stern was subtracted. And then he will make his next decision. And in this method, start command execution. We are accessing our players Manipur or a man of bar. And we're setting all these values. And then we are also saying command, execution complete. So in our case, we don't have any animations off our mana crystals appearing and disappearing and you can include them. And then you can call this method command execution complete somewhere else. But in our case, showing the new amount of Mana will happen instantly. And that's why we can instantly say command execution complete here. Then we'll have a command for our creatures attacks. And this command has much more private fields. We have the ideas for both off our Attackers. We have the health off our targets and off our attacker after the attack. And we also have the amounts of damage that are taken by both off our battling characters. In this constructor, we initialize all these values and in our start command execution, we're trying to find the game object for our attacker by accessing our I d holder and searching for a game object with this attack your unique I d. And then on this game object attacker were searching for a component creature attack visual that will actually execute our attacks. And we're calling the method attack target that takes in old thes arguments for damages unique i, ds and health after the attack off both off our battling creatures or characters. So all the commands, they're pretty similar. Let's take a look at one or two more of these commands. For example, our show message command will look like this who have just do private fields. One of them is string message and another one is float duration. We'll initialize this feuds with our constructor. And in this method, start command execution will excess our message manager, which is a singleton and will call a method show messages that takes these parameters as arguments. And inside of this method message manager, a Cortina will be called that will measure the time for showing our message and in the end of that quarantine will call a method command command execution complete to know that will move to our next command and one last command that I wanted to show you this cold delay command so sometimes and I don't remember exactly when I've used this command, but it is used somewhere. We want to include certain delay inside off our command. Q. So to achieve this effect, we can create this delay command and say at two Q. And the interesting part of this script is this method Start command execution here. I'm using our tweeting engine. You've already seen these do between sequences in our other scripts. So here I am creating in you do between sequence and sequences have these methods pre penned interval or upend Interval. And here I'm just seeing s dot depend interval delay and on complete I am calling the method Command Command execution complete. So that's actually another way off. Using our on complete method on complete takes a delegate as an argument so we can just pass the name off our method without having parentheses in the end. And this way, when this method start command execution will be called inside of this method, nothing will happen. But the system will wait for this time off delay and only then it will say command, command, execution complete. Which moves are execution to the next command. So in this lecture. We have taken a look at actual implementations off our commands, and you have seen that they're all pretty similar. So first they contain certain amount off private fields that are unique for each unique command. Then they have their constructor that has to sign something to all these private fields. And they also have this method start command execution. That is called when the order off execution in our Q off commands reaches to this command. And inside of this method will most likely pass the values in these private fields as arguments into some visual methods and this method command command, execution complete. It might be either cold inside off our command. It means that executing this command doesn't take any time, so it just happens instantly. And if it doesn't happen instantly, like in the case with our drawer card command or creature attack command, then command execution complete should be cold somewhere else. For example, in our visual scripts, that should know when the execution is actually complete in the next lecture, I think we'll have a brief discussion about our dragging scripts that will be used in the game. They're mostly similar to the examples that we've seen in this folder that is called Dragging Tests but each off our dragging action script that are actually used in our project, who have a unique way off figuring out what happens when we release the bottom off our mouths and when the drag is over, so we'll take a look at that and then we'll move to some other topics. I'd like to thank you for watching this course and I will see you in our next lecture. 2. Decision Making in Dragging Scripts: Hello, everyone. And thanks for watching the scores in this lecture. I wanted to talk about our dragging actions, scripts that will be used in our project to figure out what happens when we have dragged a card onto the battlefield or when we have dragged that target onto another creature to attack him or maybe do something else with him. So first I have opened this script that is called dragging Actions, and it will serve as a base glass for all our other scripts, like Drag, Creature, Attack, Drag Spell, No Target and so on. First, unlike our Dragging Actions Test script that we have used to discuss these concepts of dragging, this script has a property that is marked as protected so we cannot access this property from other classes. But we can access this property from classes that derive from our dragging actions. The property is off type player, and it is called player owner, and here we are using our system off tags for the first time. So we'll check if the tag off this game object when we are assigning. The tags were assigning them both through our cards or creatures and also to hold their child game objects. So we know for sure that our game object with the script of type dragging Actions will have a tag, and we can check if our tag and tag it's just a string. And for strings, we can figure out whether this string contains a certain phrase or a word. And here we check if our tag contains low, so it might be either low creature or low card. Then we're going to our global settings. And the global settings will contain the info about both off our players so we can say global settings. Instance. Low Player else we can check. If our tag contains stop, then we return the top player and else. So if none of these situations were true, then our game object is untaxed, and this shouldn't happen in our game. So we're always assigning tags to our game objects when we're creating them, and so will log an error to our console that will say and tagged card or creature. And we'll add a name off our game objects so that it's easier to find which one of our creatures is on tact. And that's everything that I wanted to show you in this script. So in other scripts like our drag creature attack or drag spell no target. We can use our player owner property there because we'll have access to this player owner from those scripts and now wildlife to open our drag creature attack script, You can notice that it derives from our dragging action script. Drug Creature Attack will be attached to a target game object on our creature Together with the Dragon will script, and it will ensure that when we're dragging that target game object in our scene, we'll select the target for our creatures attack. And there's a lot of code that you have already seen that will help us draw our line. For example, finding these sprite renders and line renders to manage our line and target and everything else, and the same is true for this method on dragging in update. Actually, it's absolutely similar to the method that we had in our test script, and the interesting part that we want to check out in this script is this one, the method that is called on and drag and inside of this method on and drag, we have to figure out what happens when we have released our mouths. We want to know if we have found a valley target for our attack. And if we have, we want to execute our attack, an attack, a creature or a player, so to know if our target is valid and if we can attack this target, we have to recast in this moment when we are ending our drag, our cursor is right above the game objects that we want to attack. So we're also using this Ray cast all and here When calling this method, we're actually using named arguments. So one of the arguments off our array cast old method is called origin and we are passing our camera main transform position as an origin as a direction. We pass this other vector and as max distance we best 30 f, then we have for each loop and inside of this loop will check if the tag off the game object that we have hit equals two top player. And if the tag of this game object is equal to Low creature, then we can attack our opponents player. And the same is true. If the tag off this game object is top creature and we're trying to attack our lower player . Then this also can be done. So in this case, we have to go face and we're saving the target game object in this variable that is called Target. So we say age, which is our hit transform game object, and else we also check for a situation when we can attack creature. Then we're checking if the tags correspond to our creatures and if these tags are actually different. So we're making sure that we cannot attack our own creature if we don't include these checks than it is possible to attack our own creature. And if we have found the game object like this that has suitable tag, we're saving the reference to this game object in our target variable. I think that this target variable is a field off our script. So if we go all the way up here, we're actually able to find this private game object target. When we stop dragging the game object that we're targeting will be stored in this variable . And if I scroll back down after this loop, we still have a possibility off not finding any target. So here we have to check if our target is not equal to know and only then we do all this other stuff. So first we're finding our targets. I d by finding its i d holder And then we find its unique I d from an i D holder. So if our targets I d. Is equal to lady off one off our players, it means that we have to attack our player. So we go to our creature logic and we're using aesthetic dictionary creatures. Created this game off class creature logic to find our creature logic game object that corresponds to this creature that we are attacking with. So we're saying creatures created this game and as a key to search in our dictionary were first getting the component off type I D holder. And we know that I D holder in this case will be attached to our parents game object. So we're saying get component in parent I d holder, Unique I d which gets us the unique I d for this creature. And this way we have already got a reference to our creature logic that corresponds to this creature. And we can call a method go face which will just attack our opponents character and else we have another interesting check were also accessing our dictionary and we're checking if our dictionary contains a creature logic that has an a d off our target i d. So if this is not equal to no, it means that we're trying to attack our creature and then we should do the same thing for finding the underlying creature logic object for our creature that is attacking. And then we should call a method attack creature with I d and as the targets I d. We send our target i d that we have just got in this line. And then we had this variable that was called Target valid. And we've said it to false initially in both of these cases, when we actually got to attack something we've said the value off this variable to true, and then we check, if not target value. So if target value is still equal to false, then we want to return our creature to its original position. So then we should say, Where is this creature of visual state? And we want to set it to visual states. Low table. Actually, we should also check here and we should set its visual state top table if it's our opponents creature. So here I'd like to include this check and else we can just copy this line based it over here and changed this low table for top table. Here I'll go to file and save all these changes. And while it's not so essential for our creatures because they will not overlap, we also want to set the sorting order. This time, we'll call the method set table sorting order on our where is the card or a creature script ? And finally, this is the part that disables our target and are lined with an arrow. And you've already seen this in our test scripts. And this method that is called drag successful is not used in this script. So the process off determining whether our drug was successful is a bit more complicated. That's why we're having this long method on and drag, and we're using it to both figure out if our drag was successful and doing something or taking action. If it was so, we have just seen this script for are creatures attacks, and I've also decided to show you the script drag spell, no target. This script will be attached to our no targeted spell cards, and it will be much simpler when we're dragging the card. If we have dragged the card onto our table, this will trigger the spell effect, and the spell will be played onto the battlefield soil. Just scroll a bit, lowered to this on and drag method. And here we actually have this method that is called drag successful. And we're returning the value off table visual dot cursor over some table, which is static property. And it will tell us if our mouse is over our table or over our opponents stable. So the spell will be cast even if we are dragging it onto our opponents stable. And when we call this on and drag method, we assume that our card is currently not in our hand. So we have actually dragged the card away from our hand, and it is somewhere else. So first we check if our drag was successful, then we actually want to play this card. So we're accessing our player owner, and we can do this because we are inheriting from dragging actions and player owner is the property off our dragging action script and we say, Play a spell from hand and we're passing in our unique I D. The second argument is minus one because this spell is not targeted and it's just our convention. So we're passing an argument off minus one as our targets, I d. And we know for sure that there are no targets with a DS off minus one. And else this means that our drag was not successful. So we're not actually casting this spell. And because our card is not in our hand, it means that we should return this card back to our hand. So we are setting the value off our slowed in our where is the card or creature class to be equal to saved hand slot, which we have saved in our own start drug method. And here I think I should also include this check. So I should say, and I mean in the next line, I should say, if then we'll find our hand visual game object And here, instead of saying turn manager instance who stern and accessing our hand visual this week, we could have said Blair, owner and do the same thing. So our card anyway belongs to this player that is called player owner. And we can say Player owner, P area hand visual and this way get to our players hand. And here we want to get the correct position for our card, which is the old guard position. So we say Player hand. We use a reference that is called slots, which is reference to our same distance Children script. We access the ray that is called Children, and we supply our value off, saved hand slowed as an index, and we want to find its transform local position. And then, in the end of this method, will use our do Tween engine to return the card back to our hand. If we haven't played it so well, say transform, do local move and we want to return this card to its old position in one second. So we have discussed the way how these dragging Scripps work in our game and most importantly, how they figure out what to do when we have ended our dragging process. And in all the other aspect, these scripts they work absolutely the same as our dragging test. Scripts later will try to add some higher quality comments into this script, so encourage you to check out your downloads folder. Maybe there will be version off our project that will be called Final or something like that. And there you will find the most comprehensive comments and the highest quality off code. I know that we've been talking about code for too long. I think that in our next lecture we should finally do something. And probably the most suitable goal for us is to enable our car draw. So at least for now, we'd like to press on the button on our keyboard, and we'd like the card to be drawn into our hand. I would like to thank you very much for your attention and I'll see you in the next lecture . 3. Testing Card Draw: Hello, everyone. And thank you very much for watching this course. In our previous lectures, we have talked a lot about scripting and actually we have achieved a lot and our game is almost complete. But because we haven't been making any changes to our scene and to our game in unity right now, it is not very noticeable. So in this lecture, I've introduced just a couple of minor changes to our project. And now we can test our card, draw our command system and so much more. First, I wanted to talk about these changes that I've introduced, and then we launched the game and test how everything works. So first I remember that I had the wrong tags in my project, and we can access tags by going to this man you, and going to this option at tag here. I've had tags that said low hand and top hand, and I've changed them to say low card and top card instead. And these are the tags that are used in the scripts in our project. We also had to establish some references. For example, our lower player area. It has this stripped player area, and I had to establish the connection with our hand visual and our table visual. And then I had to make our lower player that is apart off our logic know about our player area. So I just grabbed our lower player area and dragged it onto this be area public field. Another change was a minor change to our player script. I'll open it in model developed and show it to you. If I zoom in on the code, you will see that I've added just one method that is called update, and it's a method off our model behavior class. L zoom in even more on this method, and the comment on top says that it's for testing only. So we don't want this behavior to be present in our game. But for debugging, it's perfectly fine. If we press letter D on our keyboard, then our player will draw a card. But because we will have two instances off our player in the scene and for now we are making all the changes, saving the layout, establishing the references just for our lower player. Therefore, I had to go to my scene, find our top player, and I wanted to disable this game object for now so that this script player on our top player will not react to expressing D on our keyword. And the card will not be drawn for our top player. And now, if you launch the game, I know that there's another little issue. Our decks now have different thickness, and for our top deck, the thickness is not updated because we don't have our deck script there yet. But for this deck in the lower part of thickness is updated. Now, if I presidency on my keyboard and you card will appear, it will travel to this preview spot, and then it will go to our hand when El Presidente again then and you card will appear. And I don't like this issue with sorting order. So this second card it should appear on top off our first card, and it's just not happening. We can do that a couple more times, but in terms off placing our cards on to these slots, I think that everything works perfectly and you can see that our cards they lend just in the centre off these slots, the slots came, object gets shifted and the guards are always appearing in the center off our hand, which is also the center off our mana pool and off our screen. For now, I'll exit play mode and I wanted to make a minor change to one more script. So I'll go back to mono develop and here I should find our script that is called Where is the card or creature? We have not taken. Look at this script yet, but it is very simple. We have this in, um, that says visual states for all the states that our guards or creatures might have in the game. We have a reference to our harbor preview that is attached to this game object. We have a private reference to our canvas to set the sorting order, and then we have this property that is called Slot. Previously, I had the sorting order off our game. Objects changed when we're setting something to this slaughter property. But there are situations when we want to set the number into this slot, but we don't want to change the sorting order off our game object. So right now this property behaves just like an automatic property. Then we have another property for our visual states that it's called Visual State. And when we're setting something to this property, we also make sure that our however previews are turned on or off. So if we are adding this guard to our hand for our lower character than the previews are enabled, if we are adding this card to our table area, no matter which one of them, then the hover previous should also be enabled. Actually, I could have unified all these cases and just make them look like this. But for all these other cases were setting this preview enabled to false. So if our card is in transition, or if we're dragging this card or if this card is in the top hand, so the hand off our opponent, then we should not be able to preview these cards, and in a week we're getting references to some of our private fields. Then we have a public method that is called bring to Front that will set our sorting order and the name off our sorting layer so that this game object appears on top off everything, and then we'll have to methods. One of them is called set hand sorting order and the other one will be called Set Table Sorting Order. And we'll get a value for hand sorting order from this method, and it's exactly what is causing that behavior in our scene. So the cards, they don't appear in correct order, and it's very easy to solve this issue. We can just add a minus here, So instead of having all these sorting orders with a plus sign, will just make them negative. And now we can go and save the file and we'll see what happens. So I'll go to file hit save. And if I returned back to Unity and launched the game, if I press deal on my keyboard, we'll get one card. If I present E again, we'll get another card and it should now appear on top off the previous card. So I think that it looks more intuitive and just better. And let's check out what happens if we pressed the a couple of times soil go on and I'll press d d d three times in a row. Then, after one card is drawn instantly, another card will be drawn and then the next one, so we have just added a couple of commands into our cue off commands, and then they're old, just played back and shown to us in our game in a certain order. And actually, there is much more interesting stuff going on behind the scenes. So if we go to our lower player, which is this player that we are experimenting with right now, we have the deck for this player that currently contains five cards. The first card to be drawn is this fireball card, so we're actually able to see all these guards that are player has in the deck. If I pressed the right now and I have to return to my game Tab El Prez D, then a new card will be drawn and it's a fireable. The fireable gets added to our hand and removed from our deck. So this way we can just verify that everything that we've talked about actually works. Then if we go and select our hand, our hand script will have this list that is called cards in hand, and I can expand this least Currently this least has six elements and I can expand in view each and every one of them for example, our element zero is the card. As the owner, it has our lower player. It has a unique card lady off seven and it's a fireable. So the card at zeroth position is our fireable that we have just drawn from the deck and I can expand all these cards. And now, if I go to my game and I president again, then the situation in our hands script will change no longer. The Fire Bowl is our first guard. Now it's located at Element one, and at Element zero, we have this new card that is our swamp lor creature. So it seems like everything is working just as we expected. And I wanted to address just one minor issue. If I press D, then the card is transferred to this drawer preview spot. But I wanted the card to be a bit larger when it's on our draw preview spot. And one of the ways to control this is by controlling the position off our draw. Previous spot game objects so I can exit blame old for now, and I'll go to the visual part. I'll try to find my hand visual or actually, I'll find my draw previous spot and I'll select another gizmo so that I get to see this game object in are seen. To understand what I'm doing, I will go to my pre fabs en el grab any card that we have prefab, for example, this creature card and I'll make it a child off our draw preview spot just like this. Then I'll change its position 2000 so that it appears right where our draw previous spot is , and they don't control the placement off our draw previous spot while I am in the game tab . If I make the value off Zed for this transform negative, then it moves the game object closer to us now. What I want to achieve is I want to be able to see our card closer to us, and I wanted to appear somewhere around here, so I want the card to travel from the deck to this spot. And then from here, I wanted to travel back to our hand. Just by making these adjustments, I think everything should work fine, so I'll delete our creature card for now. I'll just hit do it here in the hierarchy and with our draw previous spot on this new position. Let's launch the game now. If I press d, then our card will be much larger in our scene. L will be able to see the better, and it will create an illusion that our card Pope's out of the dock it gets and be closer to us. And then from there it goes into our hand and our previews air working. So everything else that we're not touching here, it works perfectly fine. I'll grab a couple of more cards, maybe a couple of cards in a row, so that we can test our command system. And actually, I've experimented with our car drawer a bit more, and I have noticed that we have another unwanted behavior that I wanted to address in this lecture. When we draw a card right now, if I hover over this card even while it travels from our deck into our hand, we are able to preview this card, which should not happen. So in order to fix this, I have to exit play mode. I had to go to our hand visual script and here in this method, give player card. When this card is created. And when we are finding our component, where is the card or creature? On this card? Here, we say, Bring to front. We're setting the slot to be equal to zero for a new card, and we should also set the visual state of this card to visual states transition. And if we go to our where is the card or creature script and go to this visual states property, then if we said this value to transition, it will tell our hover previews that this preview should be disabled by setting this preview enabled to false. And now, once I've introduced this minor change, I'll click save all. And now I can go back to unity. And if I launch the game and if I prez D if I hover over this card while it travels from the deck into our hand, the previous will no longer show, and they will show on Lee when the card reaches our hand so well. Prez d A. Couple more times, and this will be true for all the cards so Onley. When the card reaches the hand, I'll get these previews, which is exactly what we wanted so I'd like to thank you very much for watching the scores . Just wanted to show you this little part of the functionality off our game that already works to let you know that we are on the right track. And in our next lectures, I think that will mostly work in Unity editor To establish all these connections and to make our game actually work. I think that the next interesting goal in terms of testing before we have an actual finished product would be to test how playing creatures onto the battlefield actually works . So I'll try to figure out the way to show it to you in one off our next lectures. I would like to thank you for watching this course, and I'll see you in our next lecture.