I'd suggest:

Start with one of these:
Java
Objective C
C++
C#
This: HTML
And pick one high-level webpage language.

Right in there, you've got:
1) Any computer which can run the Java Runtime Environment (which is pretty close to all modern).
2) Apple's programming language for their computers.
3) The old standby. It's a very powerful language and has been around for 30? years, so it's not likely to die. Plus, learning it helps you learn a lot of the fundamentals that underlie higher-level languages, as well as some of those of lower-level languages.
4) Microsoft's programming language for their OS's. Also, the poorly-named Mono project provides portability for other OS's
5) Every single page on the internet is built on top of this (except the Flash pages, but that's bad practice, anyway).
6) Something to know so you don't have to mess with HTML too much, unless you want to.

Pick one from collumn A, one from collumn C and HTML. Probably best to learn them one at a time.

Also: Which language you learn first ultimately doesn't matter; learning programming is independant of the language. True fact: It takes an experienced programming no more than about a month to get up and running with a new language. Given that projects take years, one month doesn't significantly matter.

...Also, broken italic commands.

If you're writing web-based games, here is a high-level look at what you need to know:

1) Client-Server modelling

Browser-based games, if they are to do anything ranging from storing high scores, to permitting multiplayer and persistent state worlds, require communication between "what the player sees" (i.e. the client) and "what controls the game logic" (i.e. the server). Often the logic is stored IN the client, as is the case with many Java or Flash games, but even "storing high scores" needs to talk to a server at some point.

2) JavaScript

Until Google gets their development workflow for Native Client (NaCl) worked out, JS will reign as the "king of the browser-based functionality" languages. Learn it. Inside out. Closures. JSON. RESTful interfaces. Simulating classes. All the important HTML5(-ish) tags (canvas, audio, video, websockets, workers). This will take care of the client in your "client-server" model.

3) WebSockets

Chrome, Firefox, and Internet Explorer 10 (i.e. the browsers that matter) all support WebSockets. Why? Likely because it is going to be the Next Big Thing in browser/server communication. Understand what it is, what it offers, and why it's probably going to be adopted sooner than SPDY vs. S+M.

4) Server-Side (Scripting) Language

Your server needs to be able to run in a persistent "loop". Many server side scripting languages are more built for "one-off" executions. This includes PHP, and I would take a closer look at Python in this light, as it might be unsuitable (or rather, there are likely more suitable languages for this purpose). Think of a script which needs to run in a "while(server.active)" state, crunching incoming connections. Better suited languages would include C#.NET (or C# on Mono, if you prefer cross platform) and Java.

5) Database and SQL

You need to store your persistent data in some form or another. My personal preference is to use an ORM layer which abstracts away from the RDBMS, and provides "object-like" functionality for manipulating table data.

For TGE's workflow and build environment, I use pure (i.e. library-less and toolkit-less) JavaScript (canvas, audio, video, client websocket, workers), Chrome Developer Tools (JavaScript debugging), SuperWebSocket (server websocket), MonoDevelop (C# on Mono IDE with debugger), ODX.NET ORM layer, MySQL and Workbench.

Of course, there are other configurations which can be used, it really depends on how painless you want your development to be. Remember, the tools you employ must work for you, and not you for them.

@Narf the Mouse Well I want to develop for the PC (and probably for the Android OS but the PC is my main focus), so from that list Java and C# looks the most appealing to me. How scalable is C++ when it comes to web games? how about python?

@Servant of the Lord I know it takes time, dosent matter if it takes even 1-2 years to be good at one or two programming language. I am doing this to extend my creativity.

C++: Very scalable. It's arguably the fastest object-oriented language, or among the top. The price of that is there isn't a lot between you and the bare metal, compared to something like C#. It's also hard to learn, generally. To do analogies:

C is a 50's chainsaw. It has no handguards or any real safety features to prevent you from from disaster.
C++ is a modern chainsaw. It has some pretty neat safety features, but it's still possible to have a major disaster. OTOH, it'll still cut nearly anything.
C# is one of those saws the doctors use to cut casts off. It's hard to have a major disaster in, but you can't cut near as much stuff (without addons and here the analogy breaks down).

Python: Python is not very scalable, although it gets more so if you compile it. It's usually interpreted, which means Python sits between your code and the comptuer, interpreting your code into things the computer understands. This is comparable to talking to someone through an interpreter. OTOH, interpreted languages run on anything that has an interpreter for the language.

C and C++ are compiled, which means that they're translated into code your computer understands. Much like talking with someone through an interpreter, knowing their language is faster and makes for better communication. OTOH, you have to recompile for every platform you support. Everything costs something.

C# is "JIT (Just-In-Time) Compiled", which means that your program is compiled while it's running. Once it's compiled, the code runs on the bare metal. The downside is that startup is a little slower and the .Net/Mono runtimes monitor the code, so that provides it's own small reduction. However, it can recompile for greater efficiency.
C# is still, in general and in usual, slower than C++ on a pure speed test. But it's also a higher-level, easier-to-use language and can interop with lower-level languages in .dll form (Dynamic Link Library, or a library of code you dynamically link to), if you really need the speed-up. C# is also memory-managed, and one of your first tasks in C++ would usually be to write or download a memory manager.

Java is comparable to Python in that it's interpreted, and people do seem to be doing intensive work in it. It's also fairly fast, as interpreted languages go.

Benefit of interpreted languages: You can often change the code while it's running. C# can do the same, in debug mode. C and C++ can *not*.

[quote name='Narf the Mouse' timestamp='1333395182' post='4927602']
[quote name='cristycs' timestamp='1333356999' post='4927408']
How scalable is C++ when it comes to web games?

C++: Very scalable. It's arguably the fastest object-oriented language, or among the top.
[/quote]
Your advice is very good and valuable, but just to nitpick slightly (We're on the internet after all ), you didn't answer this question fully, but he has the impression that you did, so he's walking away with faulty information.

Question: "How scalable is C++ [color=#ff0000]when it comes to web games?"
Answer: Horrendous.

C++ is not made for web-based games, and if you want to get C++ games working in someone's web browser, you have to do weird stuff like having users download custom or uncommon plugins for their browsers just to play your game, presenting major security risks and driving away users, whereas some other languages (like Java) most of your userbase will already have the plugin installed.

C++ is not the ideal language for web games. Neither is C#, though C# is somewhat better (Unity plugin, and I don't know what else, but it seems Microsoft designed C# for web support as well). Python I don't have a clue about, though I imagine it's in the same boat as C#.
Java is much better suited for web games, at least presently.
[/quote]
...I tripped on an assumption, sorry - I was thinking he'd use C++/C#/Java/Python for the backend (or what runs on the server) and the weblanguage for the frontend (or what runs on the client).

*Embarrassed*