Alright, I am an aspiring game developer (mostly interested in the field of programming and general design/storywriting) currently learning C++. Actually, I do have a good hold of the language in topics ranging from basic procedural programming with standard output to some novice OOP. I have been learning programming since I was 15, but that was mostly algorithmic stuff and only now at my 21 years have I started a serious self-educational campaign, by buying a book and allocating -that word is growing on me- dedicated study and practice time. I was a gamer probably since when I was back in my mother's womb, but the desire to make something of my own has been eating my insides for a long time now. Oh, and I have some form of OCD-related perfectionism. You might need that information to answer.

Anyway, I managed to convey my enthusiasm to a coed at Physics school and good friend of mine, who is also serious about it - and a very talented artist. He too wants to learn programming, but mostly focuses on the digital art aspect of game development. We decided to form a small study group to practice together and learn, by setting small goals and achieving them to gain some experience. Since we both can handle the language well enough for beginners, we decided to try our hands at SDL. I find it a very good beginners' library with a relatively high level of abstraction, but that comes at a psychological cost for me. While I read every line of the tutorials and try to understand what each chuck of code really does, I'm not an expert in C++ and DO end up with questions, but I also use the code to my own devices (I'm currently working on a small graphical Rock-Paper-Scissors game). Long story short, I feel like I'm just dragging and dropping stuff. And that murders the side of me that loves technicalities.

I know this is all more of visit to the therapist than a game dev related question, but I do value your opinion very much. So, to distill this to a question instead of a philosophical text: do you think a beginner should first tame the language as best as they can and then even think of making a game, or is the practice of 'just doing it' and understanding along the way a better alternative to actually learning?

Thank you very much for your time.

Peace out, Jim.

The way you want learn is a good choice but SDL to address as high level of abstraction ... i have to disappoint you. Sdl do only some basic stuff like initialize a Window and do some basic 2d stuff like blitting picture to the screen etc..

The most work still lies by the programmer. Try an look at sfml that e.g. would you call an high level of abstraction of an library.

To answer your question yes you should first master language but you have also master the external libraries you want later use.
Just doing it would be sometimes to be frustrating if you first an beginner in programming and still later too. As quick answer. I think tomorrow I will edit this post with a more detailed answer

"Oh, and I have some form of OCD-related perfectionism."

Me too, but I don't think that matters. I'm perfectly OK in using libraries.It's do or die, really. If you try to create everything yourself you're not going to be making any games.

I have been programming for many years now, and it's just recently that I'm trying to create most of the things I need myself, by learning advanced algebra at the same time.

I'm not making anything, and I know it all too well. It's part of my process, but at least I have made many games and many huge projects before. I always relied on everything I could find.

I'm strongly convinced that the best kind of code is the one you know has been proven and is well tested, and that's it. Creating games is a huge amount of work beyond just programming.

Let's look at the things you may need to do for, say, a zelda game:

1) Layered map format AND map editor, the latter being a major source of frustration the first time around - perhaps an external proven editor will work out

2) A ton of art assets in specific formats, because without them you don't have a (visually pleasing) game

3) A vast amount of interactive and _related_ gameplay mechanics

* Such as hooking into a floating "brick" which you can move away from you by, say, boomeranging it

* Lifting throwing and pushing the same thing

* Common enemies that can be scattered throughout the world

* Scripted (unique) boss battles

* Player states: Idle, jumping, running, jumping and running, flying, falling, swimming, diving, drowning, damaged + any other state (typically just blinking sprite), received item, holding sword, sword spin, attack, use item, frozen, electricuted, .... and the list goes on

4) Resource management that simplifies scripting, so that the level designer can design levels effectively (eg. being able to place NPCs WYSIWYG)

5) Realtime palette, so you can reuse assets, if you want

6) Weather and time of day effects, because its 2013 ;)

7) Binding it all together for redistribution among testers, designers

8) Version control for the codebase, levels and scripts

9) Game design that utilizes the present and future power of the game engine

Many of these points are not necessary, of course. But it could be something you have planned for.

The game will never be as good as you originally set out to do, but you may be surprised that it has improved in other areas.

So, I think focus needs to be on what doesn't already exist, which is essentially what is unique to the game you want to create.

If i had the choice between programming a level and drag-and-dropping it, assuming the programming happens in a text-editor, I would choose the drag&drop approach.

Being able to instantly see everything even in a very limited editor can be very healthy for morale. You can weigh the pros and cons, I suppose.

Try to implement Lua scripting, and create some NPC classes that all behave in unique ways, then do the same for items. That's all you need to get your foot in the door. The rest is just lots of work, and lots of rewritten code. You're never going to create your first game all the way from start to finish without having to do some serious thinking and scrapping both ideas, concepts and code.

How you solve all the problems is entirely up to you, and I think it helps you as a coder not to cheat and have everything in the gameplay laid out before you. Ideally you should get to a point where you take any concept and implement that in some way into a game. That concept almost never survives the design and implementation process, simply because things don't always fit in perfectly as it starts out as an unknown and you can't prepare for everything. Eventually you'll get a better sense of what works and what doesn't.

The bottom line is really simple: Ensure you and your teams motivation stays high by using whatever is proven and works. From there you can do whatever you want, because you can't blame the underlying structure. The rest is up to all of you to just start coding, and no amount of planning survives contact with reality.

EDIT: As the man above says, SDL is simple, but it's enough for a 2D game, if you keep things within reason. You mention having many years experience with programming, so I think you can just go ahead and make a small framework that renders sprites and sorts them by (an imaginary) Z-value. Create a camera class that follows the player around. Create Tile class and add some functions you can override with derived classes. If you are into that kind of thing. :P

Be like water, my friend. Like water.

Alright, I am an aspiring game developer (mostly interested in the field of programming and general design/storywriting) currently learning C++. Actually, I do have a good hold of the language in topics ranging from basic procedural programming with standard output to some novice OOP. I have been learning programming since I was 15, but that was mostly algorithmic stuff and only now at my 21 years have I started a serious self-educational campaign, by buying a book and allocating -that word is growing on me- dedicated study and practice time. I was a gamer probably since when I was back in my mother's womb, but the desire to make something of my own has been eating my insides for a long time now. Oh, and I have some form of OCD-related perfectionism. You might need that information to answer.

Anyway, I managed to convey my enthusiasm to a coed at Physics school and good friend of mine, who is also serious about it - and a very talented artist. He too wants to learn programming, but mostly focuses on the digital art aspect of game development. We decided to form a small study group to practice together and learn, by setting small goals and achieving them to gain some experience. Since we both can handle the language well enough for beginners, we decided to try our hands at SDL. I find it a very good beginners' library with a relatively high level of abstraction, but that comes at a psychological cost for me. While I read every line of the tutorials and try to understand what each chuck of code really does, I'm not an expert in C++ and DO end up with questions, but I also use the code to my own devices (I'm currently working on a small graphical Rock-Paper-Scissors game). Long story short, I feel like I'm just dragging and dropping stuff. And that murders the side of me that loves technicalities.

I know this is all more of visit to the therapist than a game dev related question, but I do value your opinion very much. So, to distill this to a question instead of a philosophical text: do you think a beginner should first tame the language as best as they can and then even think of making a game, or is the practice of 'just doing it' and understanding along the way a better alternative to actually learning?

Thank you very much for your time.

Peace out, Jim.

Both are valid options. The key is to gain experience. You can gain experience in a number of different ways but it all depends on your goals.

If you want to make a game then use the highest level library that you can get away with.

If you want to understand every little detail of how the game works (but maybe not actually create a game) then do that.

Using existing libraries, high level programming languages, and even game creation software is not cheating. It is being practical.

Time is finite and so we must use our time in the best possible manner. Recreating the wheel while an interesting thought exercise is not necessary in every circumstance.

So use SDL, use SFML, use Python, use Game Maker... Make your game with the knowledge that the fleeting technologies you use today are not what matters, but what you learn along the way.

Be like water, my friend. Like water.

Damn. We have a guy at work who plays ping pong like Bruce Lee.

Using GameMaker is not cheating.

Using SDL is definitely not cheating. SDL is much 'lower' (closer to the metal) than GameMaker is.
I prefer SFML over SDL, personally, but they both serve as a similar level of abstraction, just as C++ is an abstraction from pure assembly.

AAA games are cobbled together with many existing libraries and middleware packages. Many big game houses even use whole premade engines.

Building your own tech just to build your own tech is in many respects just intellectual masturbation: fun but unproductive.

Nobody is well-equipped to making their own core game tech until they have experience with using similar tech in a real game. You could make a physics engine, for instance, but if you've never made a physics game you'll have close to no idea what your features your physics engine should have, which pieces need the most performance, what the API should look like, what weird corner cases need specialized solutions and which can be ignored, etc.

Even if your goal is to learn, learn by making a game. Don't worry about the questions that come up; just finish the game. Then make another game, working with lower-level tech, answering those old questions and coming up with new ones. Then make another game. Point being, *make games*. You'll figure out the other stuff as you go.

I never understood the reasoning. You'll always use something others made. If it's not libraries, it's the platform API or something else.

Dude, just learn one library and use it for the next 5 years and keep pushing out games. Don't worry about using other peoples stuff, just keep pushing as many games out as you can and improve your game programming logic instead. Tech keeps on changing, worrying about these things will get you nowhere.