It's actually harder to jump in and get started writing games now than when I was learning. My programming class had a bunch of even-then ancient 486 clones, and we did MSDOS with QBASIC. We wrote lots of shit code, but when its as easy as doing SCREEN 13, LINE x1,y1,x2,y2 to get stuff up on the screen, it's easy to try stuff out and do crazy things.

Haha, makes me remember how I used to draw filled circles for a checkers game I wrote by drawing concentric circles using the parametric circle equation and going from r to 0...

So slow, and there were always aliasing issues that left uncolored pixels.

For example, I had before attempted to make a pong clone in Monogame, only to be frustrated and not understand how it was meant to work.

Monogame is an open source implementation of XNA. Googling for "XNA pong" yields lots of tutorials and videos. Honestly, what more do yo u want? There is so much information on the internet.

No, it's just an example :P

And I believe Monogame is a little different, atleast.

A little but not really. I moved between them and I barely noticed. And certainly for the programming parts. I remember there were some content pipeline stuff that caused issues but they may be fixed now.

A little but not really. I moved between them and I barely noticed. And certainly for the programming parts. I remember there were some content pipeline stuff that caused issues but they may be fixed now.

Monogame used to completely lack tools for managing the content pipeline in the ide and compiling assets.

Is this a solved issue now?

And I believe Monogame is a little different, atleast.

Unity is different to Unreal Engine 4. A lot.

Yet many people make the transition one of both ways. Because, in the end, both are modern 3D engines that tackle similar problems in a similar way. If you understand how lightmapping works, you just need to know the quirks of the engine you use when it comes to lightmapping, and where the buttons are to build a lightmap.

Which in turn is easy to ask online, as it is a simple question: "where is the button to build a lightmap in UE4?"

As far as I heard XNA and Mono are much more similar. You might run into one or two differences that prove showstoppers in a tutorial. THEN you should come here and ask questions to be able to proceed in your chosen tutorial.

If you find a good XNA tutorial, just try it out, IF you want to go MonoGame. Chances are either there are no real differences, you will be able to figure out the few slight differences you find, or in case you find a bigger one, someone on a forum will be able to help you.

Don't complain about missing tutorials in this day and age. There are plenty online. They might not fit your problem exactly, or might be for a slightly different tool, engine or framework. But a lot of things transfer from engine to engine or framework to framework, because its a common principle or just solved the same way in both. And if you use common sense and some clever thinking, you can figure out a lot of the remaining things yourself.

It's because it is so much better to concentrate on small, really small, practical projects that you can actually stand a chance to complete than diving head first into making a game engine or a MMO.

If Pong seems like too much, then it would probably make sense to set the bar lower and pick a simpler project.

You learn more from finishing your projects, no matter how small/trivial they are.

Make games, not engines.

I try to tell Newbies to do that.

The simpler the game, the better.

No, I'm just saying that it's hard if you have no knowledge of a framework, and if there are no good tutorials

The thing is, that game programming is hard.
Programming in general is hard.

If you think Pong is to big a challenge, then try to divide it into smaller parts.

How to create a window.

How to draw a sprite in the window

And so on.

Even when you are a professional programmer with a university degree, you will still find hard problems with no tutorials to solve them.

Dividing a problem into smaller subproblems is actually a really good exercise.

Also there are a lot of very good beginner books that you can follow. They will often give you a deeper understanding of the subject, then smaller tutorials that may just focus on one thing.

Dividing a problem into smaller subproblems is actually a really good exercise

It's not a "really good exercise". It IS programming itself.

That's what beginners should and should be able to understand. Making a game is a pretty good way to get that feeling, that there is no "paddle", no "ball", no "collision", just sub-problems that can be solved with the same "few" solutions to choose from. The higher level the language, the more specific and numerous high-level problems you have to get down to, but getting down to any lower level is just more work, not really fundamentally harder (maybe you just have to read through more documentation).

I have to add that finding elegant solutions and to architecture nice programs is a very different beast, but you can get your own games with any ugly code that does the job. You and your code will evolve with the programs you make (very important: NOT just games!) up to a point when elegant architecture will not be a dream but a reachable goal.

The last time I checked, this was gamedev.net. What else would we recommend a newbie to create? ;-)

As for someone totally new to development, many early programming assignments are text-based games like word guess, hang-man, etc. They're great tools for introducing new concepts.

So, what would make you excited about learning how to program?

A) automated bank teller, movie database, calculator, ..

B) pong, pacman, zork, ..

So, what would make you excited about learning how to program?

A) automated bank teller, movie database, calculator, ..

B) pong, pacman, zork, ..

Black Ops 3 sounds fun.