I wanted to create a collaborative game so created a race when the aim was for two players to BOTH finish in as few gos as possible.
I really enjoyed coding, testing and playing the game once it was finished. Below are a few screenshots and if youโd like to play it, here is the code on GitHub.
Hey @gracekishino the code looks good but I spotted 2 issues that I will mention below:
The code currently assumes that the user will input either โrโ to roll the dice or โqโ to quit the game. However, if the user enters something other than these options, the code will keep asking for input endlessly. To make the game more user-friendly, you can add a validation mechanism to ensure that the user can only enter โrโ or โqโ. In case of an invalid input, you can provide a clear error message asking the user to input a valid choice. By implementing this validation, you will enhance the user experience and prevent unexpected behavior in the game. The code assumes that user inputs will always be valid. It would be helpful to add some error handling in case of unexpected input or exceptions. For example, if the user enters a non-numeric value when rolling the dice, the code will raise an exception.
Itโs generally a good practice to encapsulate the game-playing logic within a function. This way, you can easily create multiple instances of the game and start playing them independently. You can create a function called play_game that takes a Game instance as a parameter and contains the game loop.
Well apart from these issue I donโt find anything wrong well if you want to improve the code quality then you can add more comments and using better variables name like instead of p1_name use player1_name. Rest everything is amazing keep it up @gracekishino.
Better is very much a relative term. I think p1_name is preferable to spelling out player (my opinion). Using long variable names that donโt add clarity may seem better to you, but look like overly verbose clutter to others. You could argue that player1_name is more descriptive, but Iโd shy away from telling others that my personal preferences are better.
Indeed, you raise a valid point. In regard to p1_name , it is worth noting that while it may not necessarily be considered a poor variable name in this specific instance, I did not emphasize this aspect among the primary concerns. However, it is important to acknowledge that when working on a project that is intended to be showcased to other developers and fostering collaborative work, it is advisable to employ meaningful and descriptive variable names. This practice contributes to enhanced code quality and facilitates comprehension for fellow developers. My intention was simply to emphasize the significance of maintaining code quality.
Given that the code is in the context of a game, p1_name is sufficiently meaningful and descriptive in my opinion. Our opinions differ. Thatโs perfectly fine. My preference is not better or worse than yours. Simply different.
@dakshdeephere thanks so much for taking the time to look through my code and give feedback I really appreciate it!
The code currently assumes that the user will input either โrโ to roll the dice or โqโ to quit the game. However, if the user enters something other than these options, the code will keep asking for input endlessly. To make the game more user-friendly, you can add a validation mechanism to ensure that the user can only enter โrโ or โqโ. In case of an invalid input, you can provide a clear error message asking the user to input a valid choice. By implementing this validation, you will enhance the user experience and prevent unexpected behavior in the game. The code assumes that user inputs will always be valid. It would be helpful to add some error handling in case of unexpected input or exceptions. For example, if the user enters a non-numeric value when rolling the dice, the code will raise an exception.
I thought I was handling this on lines 85-86:
while choice != 'r' and choice != 'q': choice = input(player.name + ", it looks like you didn't choose 'r' or 'q'. Press r to roll the dice, or q to quit the game: ")
Did you miss that, or were you thinking of a different way to handle it?
Itโs generally a good practice to encapsulate the game-playing logic within a function. This way, you can easily create multiple instances of the game and start playing them independently. You can create a function called play_game that takes a Game instance as a parameter and contains the game loop.
@midlindner thanks so much for your feedback! When I was coding I was with you thinking that p1 was clear enough and find code easier to follow if the variable names are shorter.