I concur with Khaiy. Even if you know the syntax (and you don't), watching videos does not teach you how to program - writing progressively more difficult programs does. I think that focusing on C++ is a mistake, and thinking that C# or Java are more difficult is a clear cut sign that you have no actual experience making programs.
Slow down. *Practice*. Show that you can take the knowledge you've gained and apply it to solving problems.
Can I ask, though, why has nobody mentioned Direct X? To my knowledge, that's a very big one, unless I've missed something.
In general, Direct X (or OpenGL) is more low level than people need to accomplish their goals. It's there, you can use it, but for the majority of games (and all For Beginner's first games), SDL and SFML will do what you need with 80% less headache.
Can anyone please relate to me and see why I'm struggling?
I can't really. I mean I never really encountered these problems, but let me see if I can explain my understanding.
1. Computers are "computation machines". Thus all of the things they do boil down to math. Do you know what a function is? Do you know how to generate functions to solve word problems? Do you know how to combine functions to achieve more complex results? That is all programming is, and all computers do when you boil it down.
2. All these things are tools you use to solve problems. Why would you return void? Because your problem doesn't require a result. Many things are like this. The tutorial can't say when you would use them because they don't know the problems you face.
Now on to the specifics:
"If I return 0 in another function, what would happen? Why would it cause an error?"
If you return 0 in another function, the caller would get 0 as a result. It would only be an error if you were really supposed to get 1 or 42 or whatever as a result. And even then your program would run, just incorrectly.
They say this differs from traditional programming methods but I have no idea what traditional methods were and how different they were.
Traditionally, programs were very function oriented. They said "do this, then do that, if x=y then this other thing". Object oriented programs are designed more like "make a dog and a cat. make the dog chase the cat". Instead of focusing on the operations/recipe to do something, it focuses on modeling the parts of the problem as objects.
I don't know the difference between my "code" and the "data".
Data is variables.
Code is operations performed on variables.
I know that it's more effective to use a single instead of a double when you're working with a smaller number, but why?
That's the thing, it isn't always true. singles are 4 bytes (in most languages) doubles are 8 bytes (in most languages). So if you don't need the range (larger min/max values) or precision (more decimal point accuracy) of a double then you can use 4 less bytes to store that variable. Since you have less bytes to work with, operations should be faster too.
Unfortunately, on some machines, working with 8 bytes at a time "fits" better with how the processor works, so is actually faster.
That said, the performance difference is negligible and saving 4 bytes here and there is also usually meaningless these days.
Your modeling app is only rendering that model, and it's doing it in not real time. Rendering engines need to render a bunch of models at high frame rates, all while doing all of the other logic involved in games.
Frankly, the odds of your game making any profit are nil. Just use cryengine.
You know enough to say that there will always be boxing/unboxing in non-trivial code but fail to realize that any non-trivial code will have design flaws or at the very least, sub-optimal design trade-offs.
Of all the possible performance improvements in C#, boxing is like 10th in modern codebases. Have you curtailed your allocations? Have you chosen the right collections/algorithms? Have you pre-allocated your collections? Have you looked into pre-JITing to your target platform? Have you looked to parallelize/memoize your common algorithms?
Have you actually compiled in release mode and benchmarked the differences?
Look OP: you may be right, but understand that we see literally hundreds of people coming in here complaining of performance issues or claiming they NEED to do these things that the best of the best universally see as frivolous. We're just playing the odds that you're not the sub-one percent that really do need to do these things...
2. If you are the only coder on the project, do not over-engineer for the sake of some higher principle / book / pattern / <insert random bullsh*t reason>. Refactor, so that you, as a coder, have to spend minimum (preferably zero) time on that class you wrote 18 months ago.
3. Prefer "Ugly" code [that works] to a "Beautiful" code that hides/obfuscates dependencies [and suddenly stops working].
There's a reason that good programmers advocate the use of 'best practices', it's because worse practices cause actual, real life problems. KISS, and YAGNI matter of course, but "just slap it together" cannot be universally employed to produce quality software. Refactoring is important, but cannot be your only route to good design.
There needs to be a balance, and doing some simple things like not using singletons in your design will make the code significantly better and save you time - regardless of how many developers are on the project.
I feel it is garbage. An IDE in modern programming is nearly as influential as the language itself. Why spend so much time fighting your non-IDE? I find it hard to believe you learn better/faster with so much overhead.
In practical usage, though, it looks like you end up making a thing that has data members and functions that interact with those data members.