Don't go with Python or C++. Why? You've already built up momentum with C#. The last thing you need as a beginner is to throw away your momentum and start over from scratch.

C# is a great language, and you can do a lot with it, and it's perfectly fine for making games. Learning one language does not restrict you from learning another language later on. As a programmer, you will learn multiple languages over time (assuming you become a decent programmer), and most programmers are comfortable working in several different languages (of course, they're not beginners though). Generally, the hardest part is just learning to "think like a computer" and design systems (which has very little to do with the actual language you've picked). Once you pick up one language, it's a lot easier to pick up another. Just carry on with C#. You made a good choice.*

And you can think of C# and Visual C# as being the same, sure. C# is simply a language defined by a standard, and Visual C# is Microsoft's implementation of the language (just like Visual C++ is Microsoft's implementation of C++, Visual Basic is Microsoft's implementation of Basic, etc.).

[size=2]*And despite what people might say, there is no "best choice" because there is no "best language." C# is a good choice, so have fun and roll with it.

I would actually start with C# too. It is a simple language if you don't dig too deep and it has lots of free tutorials and help sites around. C# also has XNA which is another well-documented and easily learnable game framework written with C# in mind. I wont go into any more detail and confuse you with abbreviations any more, all I really want to say is that learn C#.

Btw, Visual C# is just a reference to using C# in the visual studio IDE. Its no different from regular C# written in notepad and compiled using command line tools (although why anyone would do it that way when visual studio makes it so much simpler is beyond me)

Thanks. The only thing I see that I may be falling behind is when I use buttons and forms. I mean I can use them very easily with Visual C# but then again I don't really know how I would code it if I were to code it from scratch. I gues as long as I have the Visual C# IDE I'm good to go hehe.

To be honest, I personally think you should stay away from any kind of GUI (WinForms, WPF, etc.) until you are quite comfortable programming in C#. I'd seriously suggest just working on command-line programs. The reason is because a) the people who made the GUI tools (and the tutorials on using them) assume you are already familiar with C#, and b) it's waaaay too easy to get something up and running that looks cool (though it may not accomplish a lot) without having learned anything. Learning how to program is different than learning how to make a GUI (and often a GUI will just distract you from the real goal of learning how to program).

Another question that pops into my head now, I've been using variables like int, floats, doubles, and I get the diference between ints and floats but why doubles? and why floats numbers need to end in F?? I know how to use them and I've seen a couple explanations arguing about floats being 32 and doubles 64 I just dont get why they couldnt just make them into one and hence less complications lol

[font=courier new,courier,monospace]float[/font] and [font=courier new,courier,monospace]double[/font] are both floating-point data types, and as you've read, one is 32 bits of memory and the other is 64 bits in memory (in C#, at least). However, it's important to remember that these two data types require a finite amount of memory, which means they can represent only a finite number of numbers. Since [font=courier new,courier,monospace]double[/font] has more memory to use to store its value than [font=courier new,courier,monospace]float[/font], [font=courier new,courier,monospace]double[/font] can represent more numbers ([font=courier new,courier,monospace]float[/font] has about 7 decimal digits of precision, and [font=courier new,courier,monospace]double[/font] has about 15).

You might ask "why not just use [font=courier new,courier,monospace]double[/font] all the time and get rid of [font=courier new,courier,monospace]float[/font]?" There are lots of answers to this question, but here's a few: [font=courier new,courier,monospace]double[/font] takes twice the memory [font=courier new,courier,monospace]float[/font] does, so if you've got tons and tons of numbers, you may be forced to use [font=courier new,courier,monospace]float[/font] because you might be limited in memory. Additionally, [font=courier new,courier,monospace]double[/font] can be a bit slower than [font=courier new,courier,monospace]float[/font], so if you're processing tons of numbers, you may pick [font=courier new,courier,monospace]float[/font] for speed. A lot of times in programming, precision isn't the problem*, speed and memory are. There's also the problem of talking with the hardware or some other piece of software: sometimes they may not support [font=courier new,courier,monospace]double[/font], and so [font=courier new,courier,monospace]float[/font] must be used.

My general rule of thumb is "always use [font=courier new,courier,monospace]float[/font], unless there's a clear need for [font=courier new,courier,monospace]double[/font]."

The reason that [font=courier new,courier,monospace]f[/font] is required at the end of a number for float is so that you can be very clear as a programmer how much precision you want and enjoy the blessings of type safety.

It's interesting to note that since [font=courier new,courier,monospace]float[/font] and [font=courier new,courier,monospace]double[/font] can only represent a finite number of numbers, but there are an infinite number of real numbers, they approximate numbers as best as they can. For example, neither of these types can perfectly represent [font=courier new,courier,monospace]0.1[/font]. But they'll approximate it pretty well, and [font=courier new,courier,monospace]double[/font] will approximate it closer than [font=courier new,courier,monospace]float[/font] will.

There are additional implications that come with this, like floating point precision error, but I'll leave that for another time (just be aware that if, for example, [font=courier new,courier,monospace]a = 1.0[/font] and [font=courier new,courier,monospace]b = 2.0[/font], [font=courier new,courier,monospace](a * b) / b[/font] may not be perfectly equal to [font=courier new,courier,monospace](a / b) * b[/font] (though they'll be close)).

[size=2]*precision can be a problem though. But since float and double both approximate numbers, neither of them are going to be exactly precise a lot of the time, so double only wins out when you need the "closer approximation but still not exact." You have to deal with precision errors with both data types.