C# seems good, but....

I suggest Java or C#, since you won't get bogged down with all the complicated stuff that C++ has. Not to mention finding and utilizing all the right libraries just to get a window up. And setting up a toolchain. If you're gonna use C++, at least use multiplatform libraries and GNU compiler suite. If you just want to program inside of Windows for Windows, use C# for everything. It's going to take a long time (years) before you should even think about speed. Java and C# are not slow. It's just that C++ let's you do certain things manually, such as memory management and placement new. Which is an expert level topic.

Depending on what you want to achieve, or if you're like me, just want to program games - there are 1000 things to learn, which is why its not a good idea to start with something slow like C++. You'll want to learn about programming in general, data structures, object-oriented programming, basic memory management, lots of algorithms, linear algebra (which lets you do cool stuff like rotate objects), timestep/tick combined with physics, networking. And so on.

So, it doesn't matter what language you choose. What matters if what you learn, and what you think is fun and interesting to do. Pick a language that is easy to get started with and has a gigaton of material. Avoid choosing a complicated language (C++), or one with less material to choose from (Basic derivatives). You don't want to get stuck on small things that don't matter.

Good luck :)

--While reading keep in mind I am in a mobile device--
C# seems to be really popular here, but I have heard it is slow and similar to java. I can read java code, but can kinda write it. I have messed around with c++ (which I kinda like so far), python and lua. So as I know when you begin, you should stay with one language. Should I just stick with c++ and learn a "pro" language first or continue on with Java. I have written a "black box" in java before and would not mind doing it again in any other language. I want to get into game programming and would like to start off with a language that is versatile and I can write faster (in the start of developing). What language should I start with and is the there any good ebooks/ text tutorials online that I can use with the corresponding language. I am open to almost any language that will be continued for a long time.
P.S. I really like game dev so far because on most dev forums your post get rejected because of stupid reasons cough *stack overflow*

> I'm new to driving a car. A lot of people seem to like the Toyota Camry, but I've heard it's very slow like a Hyundai. Should I just stick with a Lamborghini and drive a "pro" car first, or continue with my Hyundai?

If you try to drive a Lamborghini fast as your first car, you will wreck it and look like an idiot in the process.

C#, Java, and C++ can all be very fast if you know how to use them properly - or very slow if you don't. Most of these people talking about how fast C++ is, usually don't know jack squat about writing fast code in the first place. A few have some inkling but have never done it on a serious scale. Many are just blindly repeating what they heard in 2006. That said, I find Java's usability to be infuriating, and consider it easily the worst design of the traditional client languages. Graphics code in particular in Java is just awful looking.

In general my recommendation for newbies is C# or Python, with a strong lean towards C# if you don't have trouble learning it. C# is also the language that I personally would recommend for somebody who is trying to complete an indie game, even if that person's day job is professional game development in C++.

C#, Java, et. al. all have serious problems in the AAA space. However, you're not making a AAA game, and you shouldn't even pretend like you're going to, even if its your goal.

C# and Python are both fine languages for a beginner, or anyone making basically anything that isn't targeting the ultra high-end (I share Promit's opinion on Java). They're going to get the job done faster in man-hours (which is what really counts 99.9% of the time) than C++. However, unless you really need to pump out games fast (like, if you're relying on it as a major source of income), you should use what you enjoy using first and foremost. If you enjoy C++, there's no reason whatsoever you can't stick with it, though I would still recommend checking out python and C# because that breadth will help you in the long run.

I am going to go with c# with the monogame framework. What's a good ebook or online tutorial for it. Even something like a "c# in 30 mins" tut would be awesome.

C# is perfectly fine. A lot of very successful games are written in C# these days. Lots of successful games are written in many different languages.

Minecraft is a ridiculously high-grossing indie game written in Java. Java _is_ slow, and I could with some time explain qualitatively why its a horrendous choice for games, and yet Minecraft was written in it and grossed millions (and then sold for 2.5 billion to Microsoft).

Some of the highest grossing MMOs are written primarily in Python; not just small bits of gameplay logic, but almost the entire games sane graphics, physics, and networking. Python is a very poor choice for games for any number of reasons that are again rather definitively provable with some case studies, and yet Python has been used to develop games that gross hundreds of millions of dollars per year.

Your choice of language will impose different pros and cons. Python is easier to write and develop in than C++, especially for small to medium projects, but has problems at larger scales and has performance problems. Which of those matters more to you?

If your plan is to write the next huge blockbuster game... you're going to be sorely disappointed, so don't aim for that and don't worry if your first language is suitable for that. If your plan is to learn and grow and become a great programmer, then picking _a_ language is not the point. Pick one to start. Then learn another. Then another. And another. You don't need to master each of them, but learn them well enough to write a few simple small games in them (Tetris, Pacman, etc.). It's easy to tell which programmers are weak one-trick ponies who've spent most of their career memorizing a single syntax and learning a single paradigm; you don't want to be one of those.

Speed is the most highly overrated argument ever. So what if your game runs 3% faster when it crashes every 5 minutes and has the feature set of an early 90s game? Our low-end phones are faster than the high-end gaming systems of that era. You don't need to be obsessed with speed any more!

Besides, even if you use C# (or Java, or ..) for your project, you can drop out to C/C++ for those tiny bits of code where it might actually make a difference, leaving you with the best of both worlds.

On the topic of "Pro languages":

There is no "Pro language". A professional dev will use the right tool at the right time. Trying to put a hammer on a screw or a screwdriver on a nail will work if you apply enough force, but you have to work harder and the result will be less than optimal.

That is why most expierienced pro software devs know more than a single language, even if they call themselves "Java developer" or "C++ crack"...

There are inherent pros and cons to each language, and tools / tricks / frameworks to work around the cons and strenghten the pros. Then there is a large comfort zone where the cons do not really matter because the use case is just... laughable compared to the computing power available.

Use Java the right way (best practices, patterns / anti patterns), apply some tweaks boosting performance, and maybe don't try to aim sky high with your goals, and Java is far from to slow for what you try to achieve. Same can be said about ANY language out there.

Our low-end phones are faster than the high-end gaming systems of that era. You don't need to be obsessed with speed any more!

The counter argument to that is one of power; the faster you can get back to a 'low power state' the better on phones so while languages like JavaScript are popular I weep the amount of resources which are wasted by them.

However this is very much an aside and doesn't really have an impact on the OP because they are just starting out so I would echo the recommendation to use C# with the additional consideration that, depending on their aims, using an existing engine to make a game might be a good direction to head in too.

Genuine question, not trying to antagonise. Does someone learning to program really need to start concerning themselves with algebra to do rotations when a high proportion use an engine that does it for them?
I know nothing about maths but I can still create a nice scene in UE4 or apply simple logic to Unity objects. Granted I am highly limited hence why I'll never make a game that anyone else will play.

Genuine question, not trying to antagonise. Does someone learning to program really need to start concerning themselves with algebra to do rotations when a high proportion use an engine that does it for them?

It depends on how well you want to understand what the code is doing. I'm making an engine alongside my game, so it was really important for me to understand how matrices worked and why I needed them to rotate my sprites and collision-primitives, especially when there were bugs with the rotation code.

I think a lot of people can get by without knowing very much about it, though, if they use pre-existing engines or libraries. I would argue that not knowing would be a limiting factor for a lot of lower-level (not platform low, necessarily) programming.

Genuine question, not trying to antagonise. Does someone learning to program really need to start concerning themselves with algebra to do rotations when a high proportion use an engine that does it for them?
I know nothing about maths but I can still create a nice scene in UE4 or apply simple logic to Unity objects. Granted I am highly limited hence why I'll never make a game that anyone else will play.

Personally I feel like you should be able to write the math for something like a missile that follows a target, which requires basic understanding of rotations. There's a lot of places to skimp on knowledge, but the basic math of 3D really isn't a good choice to omit.

I can understand wanting to know, after all knowledge is power. However, depending on your overall goals I think it's hard to simply state that someone should learn X.
As an example, I don't work in IT, I just like to mess around with tools and coding. If I suddenly had an actual idea of a game I wanted to try and make then I'd likely try to take some short cuts with things like the math part.
This may be a bit off topic actually so apologies :)

Genuine question, not trying to antagonise. Does someone learning to program really need to start concerning themselves with algebra to do rotations when a high proportion use an engine that does it for them?

Yes, you need to know at least some basic fundamentals about the underlying math for many things or you'll have a more difficult time getting certain things to work out the way you want, regardless of whether or not you actually implemented that math yourself or are just invoking it through a library. You certainly could power through all your problems with brute force, trying all possible permutations of "negative sign here, now there, now maybe I multiply instead of divide or use this vector instead of that one, or normalize (or not) that one..." but who wants to do that all the time?

A lot of people bash Java with all their energy, saying it shouldn't be used in any way because it's slow. Java is not slow, but it can be if you don't know what you're doing, just like in any other language.

Unlike most people, I would recommend starting with Java, although the raw language is definitely bad for games, there are many frameworks that can make your life exponentially easier, like LibGDX. It's easy to get started, can port your code for many platforms (including Android and iOS) with no complications and there are thousands of tutorials out there.

As an indie developer, you shouldn't worry about what language is faster or "pro". Don't get me wrong, performance and speed are definitely important, but you can wait a little bit before diving in that deep ocean.

About C#, I wouldn't say it's slow, but it's focus is at the Windows platform. Although you can port your code with monogame, and also experiment with Unity.

A third option here is Javascript, which has been growing in the mobile world and has good porting options as well.

Honestly I would recommend you to choose the language you feel more comfortable with for now and learn the "basics" of the game development process. After that you can easily port your knowledge to pretty much any other language.

A lot of people bash Java with all their energy, saying it shouldn't be used in any way because it's slow. Java is not slow, but it can be if you don't know what you're doing, just like in any other language.

I'm not sure how much production stuff you've done in Java, but the truth of the matter is that if you are targeting resource-limited platforms (i.e. smart phones and tablets), Java starts to look like a whole lot more effort than it is worth.

You are correct that any language can be slow if you use it wrong. Unfortunately, Java is incredibly easy to use wrong, when it comes to performance. It takes considerable experience just to reliably work around the many, many pitfalls around the garbage collector on mobile JVM implementations (and you end up writing the equivalent of manual memory management, modulo the need to subvert Java's existing resource management paradigms). And when you get past that and start on actual optimisation... the inability to control layout in memory completely hoses your ability to utilise the cache sensibly, and you end up porting the performance-critical sections of your program into native C++.

[source: several years writing high-performance Java software for Android devices]

Speed is not my primary beef with Java, but I'll echo the above sentiment and add that it's actually a lot harder to write performant Java than it is performant C++. Enough so that I'd personally say it completely dwarfs any productivity gain you might originally have. In projects under a few hundred thousand LOC, I'm not convinced it's worth the effort to glue a bunch of languages together either.

As for the 3D math question, definitely. Matrix and Vector operations applied incorrectly, are a huge source of bugs, and fixing those bugs can be a nightmare if you don't understand how the operations work. You'll wonder things like why everything looks wrong when you multiply by a matrix, only to find that you needed to multiply by the inverse-transpose matrix, or why your camera flips out (or doesn't appear to show at all), only to find you multiplied rotations in the wrong order. You really want to know what you're doing, and subsequently why you're doing it.

Unfortunately, Java is incredibly easy to use wrong, when it comes to performance. It takes considerable experience just to reliably work around the many, many pitfalls around the garbage collector on mobile JVM implementations (and you end up writing the equivalent of manual memory management, modulo the need to subvert Java's existing resource management paradigms).

Yeah, I agree with you on that. In my experience the garbage collector is often the culprit of performance issues, forcing me to almost avoid it entirely by using pools and whatnot.

However in the perspective of a beginner, I found myself much more comfortable starting with Java than C++ (I tried C++ first), and I still believe it's a great language to begin with. Sure it has it's downsides, but what doesn't?

I can't say for C# though, since my experience with it is zero.

I actively use both C++ and C#.

With C++, you can very easily shoot yourself in the foot if you mismanage pointers or forget to deallocate heap memory. It's one of the biggest sources of common bugs, especially with beginners.

C# and Java try to help you avoid these problems by taking care of most of that backend stuff for you. They both give you a garbage collector which will clean up your unused objects, but you lose control over when that happens. This can cause slight performance issues, but I have yet to see them myself and I wrote a rudimentary game engine using C# and XNA.

What really determines "speed"? I would argue that algorithm choice and implementation design are a hundred times more important than language selection. If you have 10,000 objects in a game world and you need to run collision detection on them, the technique you select is going to have a bigger impact on performance than any slight boost you'd get from using an unmanaged language. In other words, bad code / algorithm choice is much more responsible for bad performance than language choice. Aim for O(LogN) algorithms instead of O(N*N), and you'll generally be just fine. Even C++ will struggle with bad algorithms.

My recommendation: Use C# until you find a really compelling reason not to.

And when you get past that and start on actual optimisation... the inability to control layout in memory completely hoses your ability to utilise the cache sensibly, and you end up porting the performance-critical sections of your program into native C++.

To be fair you can do that, at least in desktop Java, with "direct" buffers (ie, heap allocation outside GC controlled heap). Downside is that you basically have to implement an array of structs manually (oh the irony). ie, computing the field offsets by hand (say, to read/write a field you'd do adressOf(buffer) + structSize * structNumber + fieldOffset).

There a couple of ways to go about this from what I've read, you can use a direct buffer alone, or direct buffer + Unsafe, maybe you can even use Unsafe alone (I think there are functions to do a malloc call and keep the pointer).

I do agree its a PITA, considerably more boilerplate than doing a simple array of structs in C++, C or C#. Although I'd argue that the amount of code that would need to "look" like this would probably be very little compared to the rest of the codebase, and the rest of the codebase would benefit from the simplicity of using a managed language.