As you are learning by yourself, the list of tech to make a 2D game goes on and on.. after all it's 2014 and these things are pretty much a solved problem and vastly below the levels that can be achieved by modern hardware.

One thing to consider in deciding for your language/API.. I see you talking about trying to avoid cheating. If that is the case, you might want to look into a language not trivial to decompile. This means avoid C#, Java of course Python.. and/or put as much game logic on the server as possible.

Although.. to be honest, considering it is your first game I wouldnt really care.. if you come up with something players think is worth crack open to cheat then it means you are already rich and doing very well ;)

My personal suggestion: Use Go with GLFW/OpenGL.. you get a compiled binary, hard to crack and easy immediate portability to Win, Linux and Mac... and you get all of this while having fun with a great modern language. Of course the price to pay is little information available about doing games with it.

i really want to work with GLFW but i really really need the major console support; at least 1 of them

well and I really hope you understand that GLFW is just an API to abstract some part of an OpenGL application such as window and contex creation and control plus some input in a platform indipendent manner.

By itself GLFW can't do anything.. so saying "I want to use GLFW" really doesnt make any sense at all.. what you really end up doing is working with OpenGL and do 10-11 calls to GLFW in your main function.

Also.. major consoles do not use OpenGL.. on the console world you are basically only left with SteamOS supporting OpenGL. I think in my experience Monogame seems like the only framework to give some hopes to be ported almost everywhere with minimal changes.. unless you want to jump ship and go with something like Unity even if you dont like it.

You see, low level automatically means no trivial cross platform support.

What kunos said....if you don't want to have to take lots of efforts for porting, you will have to use a higher level language, software, or a pre-built engine of sorts. Gamemaker and Unity are probably the 2 best at this generally, though there are competitors. I've never used Monogame, but if someone else says it works, I'll believe it.

You say 2006 - 2008 was when you were using Gamemaker. Back then it wasn't Gamemaker Studio, and it was also a whole different product. It still isn't perfect, but it is better than it was, far better. The same can be said about Unity, though the two programs took different paths to get there having started with different purposes. While technically it is true that an interpreted language is slower, for most games, including 3d games, it is fast enough. The game logic is rarely the problem, rather the underlying render code, which you generally don't have to access. I guarantee it is easy to write bad C/C++ that runs slower than your average interpreted language. And with 2d games, it is even better because they tend to have lower speed/performance requirements than 3d games. The last thing I should add about this subject is that in the case of Gamemaker, they have added a few exports that are fully compiled native, as in not a C++ compiled runner interpreting GML, rather the GML gets compiled fully to C++ with Visual Studio. This makes some games run faster, but some games get no effect because the things slowing them down weren't the interpreted code speed.

But let's be honest. You can look up plenty of topics about this. If your goal is simply game creation, you are better off going with a higher level language/software as opposed to coding down to the metal. Very few people use Assembly anymore for exactly that reason. Someone mentioned above that in general, 2d game creation is a problem that is pretty much solved. There are many implementations of 2d collision detection, including pixel/pixel collision, and it has been generally optimized to death. So why would you want to redo all(or any) of it?