My first code. A text based game

So here we are. My first blog post.

(writing for my future self here. You must feel this can use a lot of editing. but deal with it! It is the first one)

To start my coding journey, I have signed up to Codecademy. After some 101 in CS they have signed me up to write a game. Examples include; Who wants to be a Millionaire and Blackjack. So I wrote them...

1. Starting out
2. Small steps are key
3. Defining your project
4. The internet, my friend
5. Take your time
6. Test == ratification
7. Finding examples

**Starting out
At first I felt like I was nowhere near prepared enough. The Class module felt way too short, my proficiency in VSC was lacking and the project seemed way too big! After a few days of procrastinating I started writing the 'Who wants to be a millionaire' project. A quiz seemed way easier than a full on card game.

**Small steps are key
This project taught me how to start. For time in len(project): I just wrote the code. Turns out, this is not a very proficient way to write. At first it is fine. You write some starting lines, you get used to your interpreter, you get some initial result, but then you hit a road block. You don't know how to properly use or implement a class for example. So you start researching, and trying, and looking up Youtube videos that turn out to be way more advanced than what you are looking for. Then you think about the project and see how much you still need to do. Isn't there an easier way? Like, isn't there someone else that has some example code for me? Just to check how they would do it, and then I might just write my own version. Yeah... That doesn't work. You try and read the code, write your own and then end up taking the easy way out and just copy bigger and bigger parts of their code.
You do learn some things from it, like what a more advanced user does, and how sometimes the solution is way more straightforward than you think. You find out that writing good code is trying to reduce the amount of code you need to achieve the same thing.
However, don't be afraid to write bad code or over 400 lines for a mere simple text based game. You will learn a lot from it. And who knows, maybe you come back to it a year later and write it again with all the things you have learned(wink, wink future self). That is the fun of learning; you will see how much you have improved and laugh at your younger, less experienced self.

**Defining your project
When I started on the Blackjack game, the first thing I did was write a scope. What do I want my program to do? I want to generate two random cards, place a bet, pull more cards and let the bank win or bust. This should make for a nice Blackjack game. I don't think I could have written this scope without first making the quiz willy nilly. I mean I never used it again after I wrote it... and ended up writing way more than the scope described, but it really helped me get my thoughts in order before starting. So it definitely helped and I would do it again. On a bigger project this will be a bigger help than here.

So in the end I wrote way more than I initially thought. If only because it turned out that the Blackjack game had way more edge cases than I realized. Like what if a player pulls an Ace? do I assign 11 or 1? And when? Plus I thought it would be a good idea to add a split card function which added about 40% extra lines to my code...
But it was fun! it gave my game way more functionality, I re-thought my code order and got better at reading error messages.

**The internet, my friend
This time it also helped me approach the assignment differently. By taking small steps and writing down the functionality, I wasn't tempted to copy the whole project from the internet. You can still look up pieces of code and tutorials, but this time you actually learn more from it because it is only a small part of the puzzle. Looking for a tutorial on writing a certain function is way easier than a whole project. And once implemented, you are bound to use it again, but in your own way.

**Take your time
Writing this project took me about a week. I have a full-time job, so I don't have that much time to work on it. But every day i would spend at least two hours on it. And some more on my days off. I found that I was looking forward to trying some part or finishing it. Or I would be working my regular job and suddenly had some inspiration that I couldn't wait to implement later on in the day. on the other hand, when would spend all day on it, I would start to get burned out on the project and just take a break. Not working on it for a day really helped.

**Test == ratification
One of the most enjoyable parts of the whole experience is to see the immediate result of your code. Testing it, finding where the code fails, trying to make it fail. That made my code stronger and more stress resistant. What I am sure a lot of game developers know, is that if you write and test your own projects, there is only so much you will find. The first time I let someone else test the game, they immediately did something I didn't expect and broke the code... So make sure you let other people test it! But don't be disappointed when your code isn't perfect. No matter how good you are, there is bound to be someone that finds something it can break.

**Finding examples
Codecademy had some examples of code for you to look at once you felt like you were stuck. I made sure not too look at them since I thought it would be nice to compare afterwards. Well that was a big disappointment... Turned out the example code was very small, nowhere near as functional and way more basic. Which in turn made me feel prouder of my game!

In any case, this was a lot of fun. Until next time!
-G

ps. if you want to see the game, check out my GitHub