More than 3 years without posting… That’s OK, I’m immortal, not as if Time was a problem. The beautiful thing is that it follows the steps of its predecessor: it’s about coding. In Python, this time.
I just “graduated” last week from a one-year full-time course to become a Python (web) App Developer. Yay! Congrats blabla banzai… Who knows how long it’s going to take me to find a (well paid and interesting) job, so why not keep improving by making some projects? I’ve been a gamer for decades, and to make the wait for GTA VI easier (it wouldn’t run on my current config anyway), I decided to make a Hangman game. Because, let’s be honest, who would rather play a stupid game with crazy freedom where you can kill whomever you want than play an amazing little one with grey text over a black background? See? I knew it. Let’s get to it, then!
When I created that game, I directly started coding, thinking along what to implement and how to do it. Which is NOT the right way to do. Before getting to coding, one must think about what they want, the features, the functionalities, the possible issues that might arise. You obviously can’t think about and anticipate everything, but having a solid base is extremely useful. So for better clarity we’ll make a list of the things we want in our program.
Let’s think about the principles of the Hangman game: the user must guess a word that was picked from and… ah, there is it, from where? How do you want it to be? Is there another person typing in a word, and the other one must guess it? Well, in my case it’s a solo game, so I want those words to be somewhere, and one is randomly picked. Also, I want the user to be able to pick their own different language. Right. So to make it easier, we’ll call the list of words a “dictionary”.
So, we must guess a word of x letters. The letters are usually replaced with an underscore “_” on which we right the well guessed letter. So for each right guess, an underscore is replaced with its respective letter. And for each wrong guess, a penalty applies. I want those letters to be displayed, which means I will need 2 different lists. As for the penalty, it’s common to draw a stick figure, with the gallows already drawn. I remember as a kid having drawn everything from blank, but that’d be too easy. So I’ll start from the rope, head, body, an arm, the other arm, a leg, and the other leg, which gives us 7 attempts. And I don’t assume that everyone thinks that way, so I also want to ass a health bar with the remaining wrong tries.
What else? Mmmh… not much I’d say. We can add an end screen upon victory/defeat with details such as the number of moves, the optimal ones (“banana” has 3 different letters, so the optimal moves are 3), etc. and a prompt that asks the user if they want to play again or quit.
That’s pretty much it for now.
So we got a nice list of what we must implement (not necessarily in that order), let’s have a look at it.
Features list:
– dictionary (list of words) where a word is picked randomly
– language selection
– 2 lists for the typed in letters (right and wrong)
– Underscore for each letter, replaced with its respective letter when guessed right
– Penalty when guessed wrong: start drawing the stick guy
– Health status to explicitly show the user how many wrong tries are left
– End screens
– Restart / Exit
LANGUAGE SELECTION: INTRODUCTION TO THE MVC ARCHITECTURE AND ITS VIEWS
I won’t talk about dictionaries right now. Instead of that, let me tell you a way of handling languages. Please note that I have no idea if it is a common way or what the right way is, but that’s the one I thought about after having worked with the Models-Controllers-Views architecture, also known as MVC. You don’t know what it is? No worries, here is an overly simplified explanation:
The MVC architecture pattern is a way of separating elements, it helps break up the front-end (the design, what the user sees) and back-end (what’s behind, the core) code into separate components. By doing so, it becomes easier to manage and make changes to either side without them interfering with each other.
– Views are supposed to be what is shown to the user (the GUI).
– Models are the backend, the data logic.
– Controllers are like the brains, it handles the input, what is to be processed and what is to be displayed.
The game being simple and quite straight forward, we won’t need the Models. We’ll use only a controller and a views file.
To understand it in a super simple way: the engine, the core of the game will be in the controller, and anytime it needs to display some text, it will “call” some specific part in the views file.
That way, 1) it becomes easy to separate the target languages 2) any changes to be made is easy to locate and does not interfere with the main code, as we change what is called and not how it is called. Cool and logical, right?
Wait, you said you are going to use ONE file for all the languages?
You’re right (yes, I’m talking to one of my selves, shush now), ideally it should be a file for each. The game being small, there is little to display, and I chose to display only 2 languages, so putting them both in one file is fine. But in case of a lot of text and/or many languages, it would make more sense to make a file per language. Always think about how “easy” your code should be.
That’s it for the first part. If you have some coding knowledge, think about how you could start implementing all the above. See you in part 2!