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.

"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

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.

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.