Although it's not your entire question, part of your question seems to be "Which programming language should I learn first for creating a Linux game?".
Think of it though. This is sort of like a aspiring painter asking "Which kind of paints should I learn to use first?"; and, no doubt, in threads like this people don't hesitate to jump in and do the metaphorical equivalent of recommending that the Original Poster should "learn watercolour, it's the easiest" (Learn programming language X because it is 'easy') or "Learn Oil-based paints, the greatest artists all use it" (Kernighan and Richie invented C) or the entirely redundant "The sistine chapel was painted using fresco" (Excel is written in C++!).
It is all missing the point. The entire purpose of a programming language is to get the computer to do things. Programming languages vary in power- Java is weaker than C# (C# has delegates, lambda's, proper event handlers, etc) and D is more powerful than either of them, with support for static if's and strong metaprogramming support. Lisp is indebatably the most powerful programming language since it is, to programming languages, sort of what Mathematics is to most of the other sciences. A base, pure form that all others aspire to. many of the more powerful features of Lisp are only recently finding their way into popular programming languages.
That, however, is not a recommendation to learn Lisp. Everybody who works with programming languages has a favourite. My personal favourite at the moment is C#.
Let's take an example. Let's say somebody recommended you learn Java. regardless of the reasons, this is entirely subjective; there really is no better reason to learn java compared to any other language. In their mind, Java is better only because they are better with Java; they can look at less powerful languages like C and wonder "how could I ever get along without Objects?" but when they look at a more powerful language, they see constructs they are not familiar with; for example, many Java programmers I know don't like C# because it's "weird"; but it's only weird because they don't understand the constructs. They've essentially gotten used to their language of choice; if it's worth having, it's in their language, and if it's not in their language of choice, it's not worth having. Too often when I note the existence of C#'s delegates,events operator overloading, etc to a Java programmer, they will note "But that's not pure OOP" or "but why would I want to do that?", or "operator overloading is dangerous!" The first is a cop out- OOP is not some sort of end-all be all of programming languages and if anything the cost of maintaining a Triple-tiered Application framework based on clean Object Oriented design is at least as much as a standard procedural solution, by virtue of so much of the OOP code being boilerplate cruft. The second is nothing more than an expression of ignorance; just because you cannot immediately see an application for a given concept does not make that concept useless. The third, is equally silly because arguably with any amount of power there is additional responsibility to use it properly. If you litter your classes and code with operator overloads that make no sense, than, yes, it's dangerous. But once you understand what is going on and how best to implement them your code becomes cleaner and easier to read.
Anyway, my position on the question of "What programming language should I start with" has usually been that they should stop asking and start doing. You can ask 12 dozen different forums which programming language you should start with and get 12 dozen different recommendations, but those aren't going to actually get you to learn any of those languages- you have to start, and overall, it doesn't matter what you start with.
Python is a powerful language that supports, as you said, Object Oriented Programming. It lacks a few OOP concepts but again OOP isn't some sort of be-all-end-all thing; additionally, most programming languages that claim to be "fully object oriented" don't support even a tiny fraction of what should be required for a fully Object Oriented Language. Another nice thing about Python is that it doesn't force you to write in an Object oriented fashion. in java or C# everything has to be a class or object, but with python you don't have to write your main routine as a class.
Once a person recognizes two facts- the first being that programming languages vary in power, and the second being that if you are unfamiliar with a concept it will seem foreign,the sooner a person can realize that it doesn't really matter what programming language they are starting with, they are going to have to deal with something that seems foreign. I often also hear people say that "programming languages are designed for computers". But that's nonsense. A Computer cannot understand python any better than it can understand English. Programming languages are designed for use by people, and are translated by other programs, either through compilation or interpretation, into the one true language that the computer understands- machine code.
Another interesting but pointless debate that often springs up is the debate between "interpreted" and "compiled" languages, with proponents of compiled languages claiming that an interpreted languages can "never" reach the speed of a well-written compiled language. And that may be true, but the same argument came up between Machine code and compiled languages, with proponents of machine code saying that the compiled languages could never equal the performance of hand-tuned assembly or machine code. And that is true as well. But what both fail to realize is that the absolute speed at which a program ones is less important than the trade-off in development time that it takes to reach that speed. Is it really worth it to work 10 times harder on a C application rather than a Python script to gain a speed boost of 10%? That depends on the context. if it's a function called a bajillionty times in a CPU intensive loop, than it might be worth it. But for most applications that time is better spent adding features to the application rather than focussing on speed.
I seem to have rambled a bit there but I hope it helps at least.
