I've already finished my first game and working on my second simple game, I'm using tutorials with open sourced projects to write those games. All what I do is put the IDE on the right and put the source on the left and type in the IDE. I understand most of what I'm writing but I never really memorize those things if I'm ever asked to write them again. Is this how I'm supposed to learn? Or should I try to memorize the code from the source and try to write it down in the IDE? Or should I write it multiple times to memorize it eventually?
Its just that I see many game developers on youtube that code on the go and don't really look at sources when they're making their games throughout their videos. What are the best practices that I should do to learn game programming faster?
No, I don't think you are doing it right. I recommend you stop watching those tutorials and start challenging yourself to solve problems on your own.
Challenge yourself to write a program that does something, ideally something not completely trivial for your current skill level, but not so difficult that you don't have any idea how to do it. Then make a plan to build the program in small increments. If you are a beginner, the first step in your plan can be as simple as a "Hello, world". Compile, run and make sure the results are what you expected. Then add a few lines of code so the program does something closer to what you intend to do. Rinse. Repeat.
So if I am writing the AI for a board game, I would start by writing a class that can represent the state of the board and code to display it as text. The main program now consists of a definition of an object of that class and a call to display it. Test. Then I would figure out how I am going to describe a move, and again write code to display it. Change main to also create a move and display it. Test. Write a method of the board class that takes a move and changes the state accordingly. Change main to call this function with the board position and move I already have there. Write code to display the board after the call. Test. Etc.
In steps that require writing blocks of maybe 40 lines, I make sure my program is on solid ground every step of the way. I would probably do move generation next, then something that detects the end of the game and who won. Test. That might be a good time to write a program that plays random moves until the game is over. Test. Run this program a few times and inspect the results by hand, to see if everything seems to be working correctly. Then I will try to interface my program with a GUI for the board game, if one exists, or I might write a simple evaluation function and a simple search function to start getting some smarts into the move selection.
The steps I describe here are rather large, because I have quite a bit of experience in writing AI for board games, and programming in general. When you are newer, you should probably write much smaller chunks of code (perhaps 5 to 10 lines of code) between tests.
The great thing about this method is that you'll have a working program at all times, and when things stop working, you can know that the problem is most likely in the last few lines you wrote.
You can also start the program from the top, thinking of the total task you are trying to solve and breaking it down into smaller pieces. If you want to test something before the whole program is written, you probably want to use dummy versions of parts of the code until you get around to writing them.
I call these two styles "bottom-up" and "top-down", respectively. I often end up using a mix of the two. But I think bottom-up works better for beginners, and it's still what I use most.
Programming is not about code. It may look that way, but it is not.
A programmer is a problem solver. You take a problem (sum these 100 numbers for me), and invent a way to solve that problem, invent a recipe. Now, I am very slow at adding numbers. Computers are much better at it. So instead of adding the numbers myself, I expand the recipe into code that a computer understands (think of the computer as an incredible stupid person, you can't just say "sum these numbers", no, you have to explain to him to take the first number, then the second number, add them, take a third number, add it to the previous result, etc etc).
So what is the key information here? To me, it's "do a sequence of additions". When I then see code that is supposed to do that, I can easily verify if it is correct. Also, the code is pretty much throw-away data. I can easily reconstruct that code by thinking "I need to do a sequence of additions".
If you copy/paste code, you see the code, you type the code, but the overall thought to solve the problem "do a sequence of additions" is not written anywhere. That's the problem of code, it's there, it works, but it does not say why it works, or how it works.
To get further, I recommend to do what Álvaro suggests. Start from a problem you want to solve, invent a recipe, and expand that recipe into real code.
The best thing to do is get an understanding about what the code is doing, what API's and building blocks the code is using and how they are connected.
As other have said, programming is problem solving. While all developers might search for info on new API's they have not encountered before a good developer will look at samples and try to understand what is being done so they can take that knowledge and apply it to their given situation.
Aim to expand your knowledge so you can construct from fundamentals if you can. When you have a deep understanding of the code you find it easier to find issues and bugs when things go wrong.
Code is meant to be fun. Learn and expand your mind and enjoy the process :)
It's fine when learning to copy code from tutorials, as long as after you see that the code indeed works, you play with it and modify it to learn how it works, by trying to get the code to do different things. I've found that very helpful when learning to program.
The biggest issue is not memorizing function names, but learning how coding works in general.
My personal opinion. No not really. But there are exceptions to that rule.
A. When you copy the code, you read the breakdown of the code to see how it works.
B. You copy the code and modify it to see what would happen if you do something to it.
C. You copy the code in its Pseudo code format, but convert it into actual code.
Either way, you need to make sure you got the concepts. Not the code.
I agree with the others. I copy and paste code, but I try to understand what it does if I didn't write it. If you are copying the magic spell that will magically make your code work, then no, don't just copy it. Understand what it does.
This also applies to code libraries. I spent years working on a set of functions to replicate the pixel-perfect drawing routines of the original Macintosh's QuickDraw (I started programming on a Mac 512KE in the late 80's). I hated that it was doing something that I didn't understand and was so closely guarded, so I spent nearly a decade trying to figure it out (before the internet, when such information was not freely shared and difficult to find). I wrote a perspective correct texture mapping software renderer just because I wanted to know how it was done, more or less, in hardware. It bugged me that I sent vertices and a texture to the GPU and it "magically" rendered the triangle.
The point is, don't rely on code samples to do the work for you unless you fully understand what they are doing and have the ability to modify them. You will do yourself more harm than good in the long run otherwise.
Most of above advices are (obviously ) from experienced developer who like my just forgot how it is to learn programming for the first time. If it was a year ago I would respond the same. Recently my kid started to bother my to teach him this magical thing so I found a (great) book about making games in python. So far, so good, the book starts great with simple console based games (guess a number, hangman, tic tac toe, etc...). This is good pace at start where first samples are 20-30 lines, but it quickly gets to the point were retyping the code by hand is just... I don't know? Boring as hell?
So the option are:
1. We can copy the source code or just open provided file in IDE. That way it is more work to go through code to understand what it does and no way to catch some "clever" tricks.
2. We can re-type everything by hand falling asleep a few times on the way. Given how tedious is this task it is also no way to understand everything on the way and catch any "clever" tricks there are father than line 20
So I would say don't feel guilty that you "cheat" copying the code. Just do your best working through it so you understand roughly what it does and can get back to it to check how something was implemented. Also for every sample you work on try to implement something similar yourself. That way you will have to go back to the sample and figure out things you skipped at first as "simple" or "obvious".
