Part 5:
Included in Part 5:
* Turns added
* Mana System implemented
* QoL changes to old code
This Session:
This update covers the addition of three new parts to the game, Turns, Mana and Deconstruction. Some of the previous code base has been tweaked also, such as editing the Card script to prohibit when you can play cards to only your turn.
A new script has been created for this section, called 'Turns'. The Turns script contains all functions related to turns during the game, such as changing which players turn it is or incrementing the players mana based on how many turns have passed.
As always when setting up a new script, our first step is to declare our variables.
The first variable we declare is the GameManager variable, called gm. This allows our Turns script to communicate with the Game Manager, which is essential for drawing cards at the beginning of your turn.
After this, we creat a bool named 'isYourTurn' which stores 'true' if it is currently your turn or 'False' if it is the opponents turn. Then two ints are created named 'yourTurn' and 'OpponentsTurn'. These are integers as they store the current turn number, for example on your first turn 'yourTurn' will store the value of 1, where as 'opponentsTurn' will hold the value of 0.
There are two more ints, MaxMana and currentMana which store a value equal to the current amount of mana you have, and the maximum mana you can hold. Finally, there are three variables of the type 'Text'. These require the UnityEngine.UI library, and they allow you to change UI functionality through code. The ones listed correspond to three textboxes in the scene.
Once the variables have been declared, the next step is to set up the Start() function of the script. We set 'isYourTurn' to true, as the game begins on our turn. After that, we have to set the turn integer variables, so youTurn is set to 1, and opponentsTurn is set to 0. Mana is initialised next, setting our maxMana to 1 as well as our current mana, as the game will begin on turn 1. Finally, we draw a card, and the game sets some initial textboxes to be hidden.
A public function named EndYourTurn() is set up, containing all the code used to switch turns. This function has been assigned to a button in the scene that will call it when clicked:
An if statement is created, changing its result based on if the bool inside the isYourTurn variable is equal to true or false. If it is true (the turn is ours), by clicking the end turn button we will change the isYourTurn variable to false, and increment the opponents turn value by one.
While it is in another script, this seems like a good time to look at how we stop the user from playing cards on the opponents turn.
I have extended the if statement used for clicking on cards. Now, the script will check to see if we have the current mana to play the card, and if it is our turn. If both of these are correct, and the player clicks on the card while hovering, a card will be played and your current mana will be reduced by the cards mana cost. Alternatively, if it is not your turn, a textbox will display (cantPlayText) saying it is not your turn. Finally, a coroutine will start, waiting for 2 seconds until the textbox is set back to disabled.
While the card is in the Hovering mode, if the user presses the B key, the game will deconstruct a card and provide additional mana to the player based on the mana cost of the deconstructed card. Once the player presses 'B', your current mana is increased by the deconstructed cards mana cost. A textbox is then shown, to alert the player to the fact they have deconstructed a card (for clarity and a responsive feel). After this, a coroutine is started that pauses for two seconds, before hiding the text box again, and then sends the deconstructed card to the discard pile.
Going back to our EndYourTurn() function, we can start disecting this section of code now that we know how playing during turns is limited. When we click the 'EndTurn' button, it will do one of two things depending on if isYourTurn = true or false. If it is currently your turn (isYourTurn == true) then your is ended (shown by setting your turn to false), and your opponents turn is incremented by one.
However, if it is the opponents turn when you press the button, isYourTurn will become true, signalling the beginning of your turn. The turn number will be incremented by one, as well as increasing your maxMana, and your current mana will then be set to Max, as you will not have cast anything on your turn yet. The last thing the script will do is draw a card, and then the players turn begins.
This is everything we need for turns to be implemented into the game! This gives us a good foundation for a turn system, while leaving space to grow it throughout the development of the game.
You may have noticed that during this, we set up a few variables to do with Mana values. Now is a good time to have a look at our mana system.
In the Card script a new variable has been created named manaCost. This can be changed in the inspector to set the cost of each individual card. Level 1 cards cost 1, while Level 2 cards cost 2 to play. Your mana is increased by one per turn every turn, and reset to max each turn (as we have previously seen).
A mechanic has been implemented that allows you to exceed your maximum mana by 'Deconstructing' other cards. Lets have a look at this code now.
The final step to getting the mana & turn system up and running is to update our textboxes to show whos current turn it is, as well as the players current mana. On Update(), if it is our turn we set the turnText textbox to display "Your Turn", and on the opponents turn it will show "Your Opponents Turn". This allows the player to see what turn the game is currently on, and if they're allowed to play cards or not.
The very last line of code will set the manaText textbox to show your current mana and max mana. There is a small part of string in there ( "/" ) which allows us to put a static bit of text. This is so we can display our mana in this way:
1/1
where as if we didnt include the string it would display as this:
1 1
Next Project Step:
I am extremely happy with how the game is progressing. A lot of the key functionality of card games has been implemented, all thats left to do on the basic game mechanics is to implement and life system and allow players to attack with cards. This will be the next step I take in the project.
I have also started to think of new and exciting ideas for the card game that have made me realise that the layout of the game right now is a bit too restrictive. The ideas that I would like to see in the game will not be able to be implemented if the game stays with its current design. Because of this, I will be spending time Brainstorming new ideas for the game to fully understand how I want the screen to be laid out. Not only this, but along side creating the game I will be start creating physical documents that layout key game ideas, such as factions, locations, effects for specific characters and more, so please do keep checking back to see these.
As I close off Part 5, I'll leave a few images of the updated cards as mentioned in the video. These are redesigns of the current card structure done for clarity and for aestetic improvement. I am looking to include a 'Commander' card that helms each deck, the first design being Roy Mustang. Thank you very much for reading this far, have a great day, and this is one game you DON'T have to keep on the DL.
Part 4:
Included in Part 4:
* Full Video Update
* Playing a Card
This Session:
This update is a video update covering the implementation of Part 3's features.
Part 3 covered in detail the steps required for drawing cards, and also the feature to inspect a card in larger detail. This sections write up will cover the steps used to implement the playing cards feature.
In the above screen shot, you can see that the playCard() function is very similar to the DrawCard() function. This is because they both execute a similar function. A for loop is utalised first to check through all of your board slots to find one that is currently empty. This is similar to the for loop in the DrawCard() function, which looks for the first empty slot in your hand.
Once we have found an empty board slot (A slot where the current bool array availableBoardSlots[i] = true) we can begin playing the card. As the 'card' script holds all the information on a card, the function requires a Card to be passed to the playCard() function, which will be called 'card'. When we have our card (in this case the card we are trying to play) passed to the function, we can start altering the card to be played. First, the cards scale is set to its original scale. This is done as playing the card requires we inspect the card, and if we didnt reset its scale the card would be played at 3x the size of the board slot.
Once we have set the scale to the cards default, we move the card to the chosen boardSlot position. We set isInspecting to false, as we are no longer inspecting the card now that it is on the field, and we set isPlayed to true (as it is on the field). Finally, we change the current availableBoardSlot array index to False, as we cannot place another card in there while our current card is in that space.
The video covers this entire part in greater detail, and thank you for watching!
Next Project Step:
The next step in this project will be implementing a turn system where the game will alternate between the player and the opponents turns. This will also include restrictions on when the player can play cards, stopping the player from playing the opponents turn/when the player has no mana. After this, a mana system will be implemented, encouraging the players to make meaningfull decisions on which cards they decide to play each turn.
Included below is a preview of work in progress towards these goals:
Part 3:
Included in Part 3:
* Code Overhaul
* Card Zoom/Inspection
This Session:
This session I have managed to get a good amount of progress done on the game!
After leaving the last session, I was unhappy with the way my code was designed. Having no real game manager in place, I felt I was setting myself up for problems further down the line, and decided to remedy this before it became an issue.
I created a new Game Manager script, attached to a game object, and also created a card script that all cards would utilise. In my final year of university I figured out how to get scripts to communicate between each other, so I decided to try and hook my game manager up to talk to the card script.
Included in the screenshot above are the declarations the new game manager requires. I set up two lists, one to hold the cards in the deck, and one for the discard pile.
After this, two arrays are used, boardSlots and cardSlots. These hold the transform of the card slots in hand, and the card slots on the playing board. Finally, two bools are used, to decide if the current slot in hand or on board is available or not.
Next, the inspector needed to link the game objects to the lists & arrays they correspond to.
Once this had been filled in, I was almost ready to start working on the 'DrawCard' function. First, the card script needed a few variables defining before I could begin.
In the card script, I made three declarations. One bool, 'inHand', is used to determine if a card is currently in your hand. While the card is in deck or on the field, 'inHand' is set to false. Once the card is added to your hand, inHand is set to true.
I also created an int called 'handNum', to hold a hand space number while we loop through our hand (More on that later).
Finally I created a variable for our GameManager called GM, allowing the scripts to interact with each other.
I created a function called DrawCard(). In this function, we have an if statement to check to see if the deck currently has cards. While there is no other section to this if statement yet, it gives me the option to add a 'loss' feature once your deck has no cards in it. A variable called 'randCard' is created, of the class Card. This 'randCard' is chosen at random from the range of the deck list, which currently for me is 4. In the inspector, I have populated the deck list with four cards, one of which will be chosen to be our 'randCard'.
Once it has been determined which card our random card will be, I create a for loop to determine which hand slots are available to draw into. It checks the availableCardSlot array, and once it finds a hand space that is empty ( availableCardSlot[i] holds a value of 'True', where i is the hand card slot) it can begin to create the card in that slot. Then the card GameObject is set to active, as a way of 'creating' the card, or drawing it from your deck.
Earlier, in the card script, I created the int 'handNum', which will store the hand number the card is currently assigned to.
The card is then moved to its handslot position by setting the cards transform to the handslots transform. I set the card's 'inHand' bool to true, so the game knows it is currently in hand. This allows us to modify how the card behaves depending on which state it is in 'Eg, in hand or on field'. The 'isPlayed' bool is also set to false, as the card is not in play yet. Finally, the corresponding availableCardSlot[] space is set to false, so no more cards are able to be drawn into this space, and the card is removed from the deck using the Remove() function.
DrawCard() was then hooked up to a button, and with the press of that button, cards could finally be drawn!
I felt like just getting the GameManager set up was a victory of itself, however one design issue was starting to annoy me during all of my testing. I had designed the game board to be too small, and there was no way I could hold a card in hand and have it be legible at the same time. If I kept the whole card on screen, too much of the game board was lost, and if I moved the handSpace lower the card moved off screen.
I decided that my game needed a way to inspect cards. This way, I could keep my hand positions where they are, while allowing the player to have a way to check the contents of their card.
In the GameManager I created a bool called 'isHovering', which is set to true or false. This variable will be renamed to 'isInspecting' by the next update for clarity.
In the card script, I created a function to call when a mouse clicks down on the card. I set up an if statement that checks if the card is currently not in the hovering state and also if it is not currently on the field. The function stores it's current position (so the card can return to its handSpace), then moves the card to the middle of the board. Its scale is increased to 0.75 and isHovering becomes true, as it is being inspected.
Currently, the way to exit the inspection mode is written in the Update() function, however I am aware that this isunnecessarily resource intensive. By the time the next part is out I will have this moved onto the game manager. By moving it to the GameManager I will be able to limit the inspection to 1 card at a time, where as currently mutiple cards can be inspected at once.
This is a simple function that checks to see if the card is in the hovering state, and if the 'R' key is pressed the if statement starts. Hovering is set to false, and its position is returned to its position stored in priorSpace (handSpace position). Lastly, its scale is returned to its default scale.
Next Project Step:
While I also managed to implement the ability to play a card I wont cover that in this part, in fear of this session going on forever. Tomorrow I will write up how I implemented card playing, and I will begin working on smoothing out issues with the current design, such as being able to inspect multiple cards at once.
Part 2:
Included in Part 2:
* Deck Spaces
* Drawing to Hand
This Session:
This session I focussed on creating two deck spaces on the board, one for the player, and one for the enemy. Each space has been colour coded for now, however these will be replaced by a graphic more fitting of the setting & IP later on down the line.
After creating these deck spaces, I decided the next step would be to allow the players to draw cards from their deck.
I created a script attached to the deck that included a list named 'DeckList'. On Start, the script will find all cards in the scene with the tag 'Card' and add them to the deck list. (This is just a prototype workaround while DeckBuilding isn't in place. This will eventually be replaced by finding all the cards in the players constructed deck.)
Once I had the deck locating cards and 'filling' itself, the next step was to get the cards to draw to hand. I decided on expanding the current deck script to include a space for the players hand, saved as a GameObject.
I created an empty game object in the scene and set its location to where I want the cards to draw to.
Once this was set up, I had to start creating the script for drawing a card to hand.
I went into the DeckScript and added an OnMouseButtonDown(0) call, so that when the player clicks the left button on the deck, this function is called. We first create a variable called 'nextCard', which holds the top card of the DeckList. In this case, nextCard holds DeckList[0], which is our Maes Hughes lvl1 Card. Once nextCard is holding our decks top card, we then instantiate that card into our 'handLocation1' position and rotation. Upon clicking the deck, the top card is created in hand! (Included in the script is a print function for debugging.)
However, new problems were presented with this approach. While we can draw cards to our hand, all of the drawn cards go to the same space and stack ontop of each other, making most of them unplayable.
My next idea was to create 5 hand 'spaces', so that each card can slot into a different space, keeping all cards seperate and readable.
Finally, I had to have the script check if a current hand space is occupied by a card, and if it is, move onto the next space.
I created 5 GameObjects, handLocation 1 - 5, and made them public. I then assigned the 5 handSpaces in editor to their respective locations.
Once this was done, I set up a bool to determine if the space was currently occupied by a card. It is set to false initially, as you will start with 0 cards in hand. When the player clicks on the deck the script will check to see if H1isFull. If it is false, then we instantiate our card in handLocation1.
However, if HandSpace1 is full, the script then moves onto HS2 and checks to see if that is full. If it is not, the new card is instead instantiated into the space.
Next Project Step:
The next step for this project is to smooth out the code for drawing to hand. While I have a working code, it is not very efficient, and to get the code checking for all 5 hand spaces will require a lot of if statements. I will be looking to cut this down to one statement that loops through 1 - 5 each time, and fills the first space it finds empty.
Once that is completed, I will aim to get the player card moving from hand to board fluidly into the correct corresponding places.
Part 1:
Included in Part 1:
* Game Inception & Ideas
* Card Creation
* Board Creation
This Session:
I focused on the creation of assets for my game this week. I find I work a lot better when the visual side of a project has been worked on, so I decided to begin with creating a few cards for the game. Four cards were created, Hughes Lvl 1 & 2, and Hawkeye Lvl 1 & 2.
I also created a scene in Unity for the 'Play Area', and created prefabs of the cards I have created, setting a standard size for all cards, as well as creating and setting up different layers for the board and the cards to exist on.
I spent time thinking about how the game will play. I originally designed this to be a simple game, not requiring any knowledge of Card Games to experience this project. At this point in time, key gameplay ideas haven't been locked down. Since this is just a prototype version of the game, I have not designed any documentation or planning techniques. I will be assessing both the Agile & Waterfall methodology this week to determine which one fits my project best, and will then start planning my future scrums.
Next Project Step:
After creating 4 cards, the next step I am going to tackle in the game will be to create a 'Deck', and have the top card of the 'Deck' be passed over to the players 'hand'. My initial idea will be to use and array or list to stop all cards in the players 'deck', and have the top item of this list be moved into a second list that contains all of the players 'hand' assets.
Next Documentation Step:
My next step for the project is to lay out exactly what mechanics will be necessary for the game, and write a document stating what the game will entail, including features, layouts, menus and rules.
