Pre-Course Week 3: Feeling Classy
Tags: makers, ruby
Published: 2019-11-03 11:43:03

So this week I thought it might be better if I just showed you the main challenges I did in each chapter and just walked you through them because there's a lot more to this week's challenges, so let's get started ...

CHAPTER 6

Chapter 6 had 4 questions at the end of it but the one I'm going to focus on was the biggest one, which naturally is question 4. It's a choose your own adventure type game which was quite fun to do.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/p9tml249k1xk51fqx2ul.png)

This looks like quite a lot when you take it in all at once but I like to split it up into more manageable sections which helped me understand it and as you can see because of my choice of variable names it's very readable. There are 3 sections which are split into loops, *"in_game"*, *"in_hall"* and *"in_study"*, each of these variables are booleans and since the while loop takes a boolean value I can enter them without the *"=="* operator. This means that each of these loops will continue while their corresponding variable is true. The first loop, *"in_game"* loop, it's only active as the name suggests when you are in the game. There are only two ways to break this loop, by entering *"quit"* or winning the game. There are 2 things you can do in both rooms *"quit"* and *"look"*, quitting makes you leave the loop you're currently in and leave the main loop ending the programme and looking print a short description of the room you're in. Which leads me onto the second loop which activates when you in the hall, its been set to true at the top this means this is the room you'll start in. So now I can start dissecting the rest of the programme, *"action = gets.chomp.downcase"* so *"gets"* is getting user input as a string, *".chomp"* is used to remove the enter character from a string (user input looks like this without *".chomp"* *"hello\n"*, once *".chomp"* is called it turns into this *"hello"*) and lastly *".downcase"* was something I added for usability so it changes all the letters to lowercase so if you tried to quit but you hit the caps lock on accident *"QUIT"* will still be recognised as a valid input and it'll make you leave the game and once I get the input from this process I assign it to the variable *"action"*. If you've read my other blogs you'll know what the *"if"* and *"elsif"* does but I'll go over it quickly it takes a boolean and activates the code inside it if the boolean is true ( in this case it checks what the user input is equal to). I've been through the *"look"* and *"quit"* statements so I'll skip straight to the *"north"* statement, what this does is it makes you leave the hall to go to the study by making *"in_hall"* equal to false which makes you leave the hall loop and it also makes *"in_study"* equal to true entering you into the study loop, the *"south"* statement is very similar to the north statement except it does the opposite it takes you out of the study loop and puts you into the hall loop. So now you're in the study loop and you already know what *"look"*, *"quit"* and *"south"* do so I'll move onto the final *"elsif"* statement this one I again took usability into account the challenges tests would check for *"enter combination 2451"* but I thought if you were really playing this game the likelihood of you typing all that out would be slim so I used *".include?"* what this does is checks the user input for the digits *"2541"* and if it finds them it will print the victory statement and make you leave the study loop and the game loop by setting those variables to false. I thought this was a nice touch cause it meant the user didn't need to type out a full longwinded statement to win the game.

CHAPTER 7

Chapter 7 had some interesting challenges but the one I'm going to focus on is the crocodile river game the idea is that you're floating down a river full of crocodiles and you would type in command on which way to go, the objective is to get to the end of the river.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/0lpaouc4jwfhcex88m56.png)

First thing I did was define all my future variables *"@in_game"* which is the same as chapter 6, there are two variables that take the river string and converts it into an array one is for adding the player to the other is used to convert the path back to the way it was, *"@player"* which is the players icon, *"@lat"* and *"@i"* which keeps track of what section of the river you're in (*"@lat"* keeps track horizontally and *"@i"* keeps track vertically). After that I defined a method (I think I got ahead of myself on this one cause I didn't learn about methods till chapter 9) what it does is it deletes the item at the index you specify it saves that item to a variable to check if its a crocodile (*"C"*), if it is it sets *"@in_game"* to false and displays the game over message, if the place isn't a crocodile it places the player at the specified index, but because of the way this method works I can also use it to revert the previous stream to the way it was. I start our programme with an *"each"* loop which will run for each section of the river, the next line splits the section of the river you are currently in into an array then I used the *"revert_stream"* method to add our player to the stream at the horizontal position set in the variable *"@lat"* (you start in the middle) after that the array is joined again and ready to be put into the *"riv_arr"* at the vertical position set in the variable *"@lat"*. While the code was doing that it was also checking to see if the place where the player moved had a crocodile (*"C"*) in it and if it did the next line will break the loop and end the programme. So after all that its prints the river in the console so you can see where the player is and the path you need to take (unfortunately this was part of the challenge so I couldn't mess with it to make it more challenging) the programme then asks for user input using *"gets.chomp"* and then it reverts the current stream to the way it was before using the *"@streams"* variable which has all the streams the way they were originally. Now I'm moving onto the *"if/else"* statements, if the user enters right it adds 1 to *"@lat"* essential moving up one in the array and if the enters left it subtracts 1 from *"@lat"* moving down one in the array, anything else the user enters will be taken as neither and won't change *"@lat"*. After the each loop does that for each item in the array it'll then check if you made it the full way through the game by checking that *"@i == 4"* because if you get through the full game the code will have run 4 times, it will then display a victory message and exit the game by setting *"in_game = false"*.

CHAPTER 8

I was introduced to hashes in this chapter which are similar to arrays except they have a key that you can access so instead of having to get things through an index it uses a key-value pair which makes things easier to access as you can see by this hash.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/6w8b7xi5iu4gial6iyrm.png)

 In this case, you can access the name of the first person using *"people[0]["name"]"* which is easier although it starts to make a bigger impact on a larger scale. This hash was used in one of chapter 8's challenges which were to make a programme that gets the user to enter a category and print out all the items in that category with the names of the people in each group. 

 
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/0tkvxxe1tq699ypd5rcy.png)

Once again I'm asking the user for input and I'm saving it to a variable, I also create an empty array (*"category_arr"*) to push the category items onto. After that the programme will loop through the array of people and check the category, using the category as a key, the user gave it and pushing each item in that category onto an array and then using *".uniq!"* To make sure there are no duplicates in the array. Then I created an empty array (*"arr"*) for the people who have that item under the specified category, I then loop through our new array using *".each"* and I nest another *".each"* loop inside that for the people array. If the persons category item is equal to *"category_arr"* item it'll push that person onto the array (*"arr"*) then the programme is going to print out the category item then all the people who have that item in the specified category, it does this for each category item then the programme ends

CHAPTER 9

This chapter only had one question at the end of it which I had a bit of trouble with but I got it done in the end which made the victory all the sweeter when it was done. It was a simplified blackjack simulator.  I learned about methods in this chapter so I'll go over each method separately.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/bkv53db9qss1qlv4xez8.png)

This method was already made as part of the challenge what it does is create an array of cards then it uses *"rand(13)"* to create a random number from 0 - 12 and uses that as an index for the array to give you a random card.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/lw6mxsdm2649exvk43d8.png)

This method is just for getting user input and returning the result using a case statement that works in a similar way to an *"if/else"* if the user enters hit it returns *"hit"*, if the user enter stick it returns *"stick"*, otherwise it returns hit.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/xs1mo30ak6xcpcjhqx8w.png)

In this method a had to give it an argument for the tests, I defined a hash giving every card a numeric value so I could calculate the score, I then set variables for the *"current_score"* and *"total"*. The next thing I done was run an *"each"* on the *"cards"* argument which will be an array with the players' cards in it. I then loop through the array and add each card using the has to get a numeric value for each of the cards and adding them to the *"total"* and *"current_result"* variables, and at the end of each iteration I convert the current result into a string and add it to the *"Score so far: "* string. Lastly, I return the total to be used later in the programme.


![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/5uuhxuoje476q6eu8xim.png)

Now time to move onto the final method the *"run_game"* method. So this method starts by defining an empty array called *"cards"* which will be the players' cards and a *"total_score"* variable which will check if the player goes over the maximum score and end the game if they do. I then run a while loop that takes the move method runs it then compares the result to *"hit"* and if the players' input is hit and the players' total score is less than or equal to 21 it runs the code inside. It then pushes a random card onto the *"cards"* array and calculates the score using the *"score"* method and sets the result to the *"total_score"* variable. If your score goes over 21 you exit the loop and it tells you *"You busted with: "* and then your score which is converted to a string and added to the sentence. But if you choose to stick before you go bust it'll tell *"You scored: "* and again converting and adding your score to the string.

CHAPTER 10

Now I'm onto the last chapter this is where I was introduced to *"Classes"* which are a collection of items, for example, *"Strings"* and *"Integers"* are both classes and have certain methods you can call on them. I got to see how to change existing classes and how to make new ones which is what this challenge was about. I get the feeling that there's a lot more to classes that I'll get to see when I start on site so I can't wait for that, anyway onto the challenge.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/050kuvzzvlyp010dh057.png)

So after I learned about classes I was given the challenge of making a todo list using classes and methods on the classes. The classes are defined by calling class followed by the name of the class you're going to make, as you can see I have 2 classes in this challenge the *"Todo"* class and the *"TodoList"* class. Starting with *"Todo"* you can see a method called *"initialize"* this method runs automatically when you use the *"Todo"* class, it sets your todo to the argument given to it by the user. But unfortunately, this will return our input as an object so the next method *"text"* changes it into a string so you can push it onto our to-do list. The second class is the *"TodoList"* class which like the *"Todo"* class has an *"initialize"* which sets it to an empty array, its got 2 other methods the *"add"*, which takes a parameter of a *"Todo"* and converts it using our text method and then pushes it to the empty array, and the *"print"* method, which loops through every item in the array and prints it with a bullet point beside it. This challenge was quite simple but as I said I suspect that I'll be learning more about these classes because they seem quite useful.

SUMMARY

Naturally, this weeks challenges gave me a lot more trouble than last weeks but I enjoyed working through them, plus it made finding new ways around the problems all the more satisfying when I got the answer. I can't wait for this weeks study group it'll be fun to see how different people approached each problem. Next week I'm doing pair programming, so I'll need to find a partner to pair which but I know plenty thanks to the study group, this will be different since I usually rely on myself but I'm looking forward to it.