Sprint Blog 1
Here begins the first of my programmer/dev blogs for Ace of Spells. I made a lot of progress, and I'm excited to continue working on this semester-long project.
I was in charge of creating the google forms page for the paper prototype. I followed the final critique categories to ensure we’re getting quality feedback.
I created a Github project for the game. I have used Unity’s collab system before for version control, and there were tons of problems. I am excited to try something new and use Github instead. I’ve used Github for many projects before, but they were usually by myself. I’ve never really used the branching ability Github has, so I’m currently learning about how that works. We’re doing it so that each team member who wants access to the project creates their branch to play with. When they want to add their changes to the main branch, it will have to be approved by me (the “project owner”). Thankfully, the tool GitKraken makes the whole process easy. To see the visual layout of GitKraken, see Figure 1 below.
Figure 1. Gitkraken layout. My commits are light blue, Josh’s are dark blue, and Alex Lopez’s are purple. The other members of the team will soon have their branches.
Before I began any actual programming, I created a class map of the deck and card system (Figure 2). This way, future me and my other classmates can look at this class-map and understand what’s going on - without wasting time looking at the code itself. And to be honest, before I even started a class map, I started scribbling ideas on paper.
Figure 2. The most recent version of my card system class map.
As you can see, it’s quite small, but there are lots of explanations (see the yellow boxes). For the majority of the functions listed, I explain what they do. That’s because, in my opinion, class maps don’t explain enough by themselves. Usually, when creating complex diagrams, the implementation/usage is ignored. When I had to implement the functions, the yellow text was practically pseudocode, which was nice.
As for actually implementing the system, I started with the Card scriptable object. Card is a scriptable object, which holds all of the basic information every card will need. See Figure 3 for an example.
Figure 3. The card Fireball holds the name, description, element type, cost, and spell game object that the card creates.
I made it so that the Deck class holds three List<Card>: draw pile, discard pile, and hand, since to me those lists together make the deck.
The way RefillHand() works is I shuffle the discard list and add all of the cards in it to the draw pile. Then, I clear the discard list.
I created a generic ShuffleList() function, which takes in any list of cards by reference, and shuffles it. Keeping the DRY principle in mind (“Don’t repeat yourself”), I allowed myself to be able to shuffle any list of cards I want - instead of making many functions that do the same thing. This is nice because, both the draw pile and the discard pile need to be shuffled at different parts of the game.
In CAGD 380 last week, we learned about how a function's arguments can have default values, so I tried to apply that to this project. DrawCard() will draw one card by default, but you can enter as many cards as you want. For example, at the start of the game, the player starts with three cards, so I call DrawCard() and pass in the constant, HAND_SIZE_MAX, which is set to three.
Figure 4. The implementation of the DrawCard() function. If the function is called with no arguments, the variable amount is set to one.
For the player to swap between different cards in their hand, I created a simple function, which simply increments an index value. When that index reaches the max, it will wrap back around to zero.
Figure 5. The implementation of the SwapSelectedCard() function. See an issue? If the player only has one card in their hand, there is a chance they will have a handSelectionIndex of 2! drawPile[handSelectionIndex] could cause a segfault, and was an oversight by me. I will be fixing this soon.
To test the system, I created used debug prints (Figure 6). It’s admittedly a hacky way to test, but given there is no UI I figured this would be the fastest way to see results.
Figure 6. Testing the DrawCards() functionality.
At the start of the game, you draw 3 cards. If I call DrawCards() again, it will draw 0 cards, since I’ve already reached the max amount of cards in your hand. Then I activate a card - removing it from my hand, which causes me to draw another card from the draw list.
Completed Task List:
- As a player I need to be able to build a deck of spells to attack enemies with spells I find around a level. (1)
- As a player, I would like my deck to reshuffle my cards back in once I cannot draw or discard anymore. (1)
- As a player, I would like to be able to draw a card. (1)
- As a designer, I would like a deck system that holds all of the players cards that are not in their discard or in their hand. (3)
- As a designer, I would like some organization within Unity so that we may properly place new assets and scripts. (1)
- As a designer, I would like a unity project to be made so that we may build the game. (1)
- As a player, I would like to be able to swap between cards in my hand. (1)
- As a designer, I would like a deck class map that covers the deck, the hand, the hand selection, reshuffling, a discard pile, and a destroy card function. (3)
- As a designer, I would like a google forms page to be made, so we can gather feedback about our game. (1)
- As a designer, I would like each team member to concept 5 spells, one for each type so that we can get everyone's ideas for cards and make a diverse game. (1)
Tasks In progress
None
Issues/Problems/Solutions Encountered
- I could have added more comments to my code, rather than having a bunch of debug prints. The debug prints will eventually be replaced by actual UI and functionality, but over this semester, some more comments will certainly be useful. This is something I will be working on during Sprint 2 and the following sprints.
- Another thing that will be a potential issue is the fact that the programmers are creating class maps separately, rather than as a team. For example, there might be overlapping class maps (like two people making the enemy class). As of now, it is not a problem.
That’s all for this Sprint 1. See you in two weeks when I talk about my progress in Sprint 2.
No comments:
Post a Comment