Hey there guys. I've been following this forum for a few days now, and so I thought I'd pose one of the questions that has been on my mind. Am I biting off more than I can chew? A little bit of background info. I'm 18, and a first semester Computer Science student, with a Minor in Mathematics. Programming is what I've wanted to do with my life since I was 11. So I started teaching myself Java at 13, which went through an on again off again cycle all through high school, mostly due to time and extra curricular activities. I have a pretty decent understanding of programming as a result. Anyway. Game development has always been a more interesting subject to me, and as is true for a lot of others, is the reason I began programming. So, I understand the concepts of a whole lot of things, and I'm going through Lazy Foo's Tutorials to learn some stuff with SDL, and then I'd like to build on that base with the OpenGL SuperBible. My question is, am I hindering myself by going straight to SDL and OpenGL? I mean, I know there are plenty of engines out there. And so many different ways to make games. My problem is, I want to understand everything. I don't want to use somebody else's engine because I want to know how an engine works and make my own. I don't want to use something just because it makes things "easy", and I would much rather just start off muscling through openGL and engine creation so that I can build on a solid foundation and not have to bother transitioning later. Is this an okay mindset to have? Am I actually making things harder on myself? And, am I going about things in the right way (lazyfoo's tutorials, opengl superbible)? I appreciate your feedback! Thanks!

It really depends. If you want to gain a better understanding of the core mechanics behind how a game engine might be constructed, your current path might not be awful. I will say that there is a high chance your engine will be complete rubbish if you develop it outside of the context of actual games.

My advice would be that you really need to learn how games work before writing an engine. Really an engine is just the reusable parts for a game... so you should just try writing games, factor out the common stuff, and then you have your own "engine".

But of course there are already hundreds of engines out there.... some better than others....so if you really want to make games it might be best to not reinvent the wheel. The whole mentality of "I want to make everything myself!" is cute, but it doesn't typically lead to getting much accomplished, and it typically leads to frustration.

In the industry you will not (more than likely) be making your own engine anyway. You will be working with whatever tools they use... which will either be commercial engines or in-house solutions, but I think rarely will you be starting from scratch. Especially at an entry level position they are not going to have you creating the entire engine by yourself (and any company that did would seem highly suspect in my book!)

Also you will NEVER know everything. I firmly believe that anyone who says or claims they know EVERYTHING really knows absolutely nothing. The more I learn the more I realize how little I truly know.

It really depends. If you want to gain a better understanding of the core mechanics behind how a game engine might be constructed, your current path might not be awful. I will say that there is a high chance your engine will be complete rubbish if you develop it outside of the context of actual games.

My advice would be that you really need to learn how games work before writing an engine. Really an engine is just the reusable parts for a game... so you should just try writing games, factor out the common stuff, and then you have your own "engine".

But of course there are already hundreds of engines out there.... some better than others....so if you really want to make games it might be best to not reinvent the wheel. The whole mentality of "I want to make everything myself!" is cute, but it doesn't typically lead to getting much accomplished, and it typically leads to frustration.

In the industry you will not (more than likely) be making your own engine anyway. You will be working with whatever tools they use... which will either be commercial engines or in-house solutions, but I think rarely will you be starting from scratch. Especially at an entry level position they are not going to have you creating the entire engine by yourself (and any company that did would seem highly suspect in my book!)

Also you will NEVER know everything. I firmly believe that anyone who says or claims they know EVERYTHING really knows absolutely nothing. The more I learn the more I realize how little I truly know.

Thank you. I appreciate your advice.

My goal is like what you said, to create an engine by creating a game and then having the reusable parts for later. That's what I mean by creating an engine I suppose. I don't want to create an engine for creating an engine's sake. I want to create a game and create the engine for that game in the process. And I want to do that on my own so that I can do everything for learning's sake, as well. My fear is by using someone else's game engine, I'll be limited in what I'm doing, and I won't understand what's going on, even though I would get my first games out faster.

Worth it, or would you say I'm better off just switching to an engine and learning the API?

Probably the best advice is to learn the hard way. Your expectations aren't in line with your idea (create an engine). There's two ways to resolve this.

One is to heed all existing advice against creating engines, and just focus on making your game, taking advantages of existing engines and so on. At a certain point in the future, when you have significant experience writing games, you'll be able to revisit the topic of engines.

The other is to embark on your goal of creating an engine.

I cant comment much on C++ but I can comment on projects and ambition, on the internet and real life I guess, the common reply for any project usually results in "dont, it requires a lot of time and it will be shit", this is not limited to game development, I say game development because ironically people who want to make use of the unity engine and 'build' the game get just as much stick as people who want to build an engine.

"I want to create my own forums", "I want to create a socket server", "I want to crack this product" etc, all come with a reply similiar to "dont it will be bad" or "dont it is time consuming", truth be told I have never really came across an ambitious thread ever (even out of programming) where people actually say "go for it, just make sure you do enough research before starting it".

As for "its hard" remarks, this directly in programming translates into "its time consuming", but then what isnt, even a simple homepage is time consuming, in the end the only thing that matters is how the project will benefit you, how much time you have spare and how much capital you need to get it started, fortunately for programming you dont need to spend a lot or anything for that matter.

If you want to make a game engine, do you research in how they are made, play around with free game engines and look at some open source engines, in the end it doesnt matter how big your projects are whether you want to make the next wow killer or hack the internet, you will likely learn a lot from it, if you have the time for it go for for it, knowledge is priceless and you will gain a lot, even if it fails or is shockingly awful. The only exception to this rule is when you quit your job, abandon your friends and spend all your life savings for your ambition, thats really when an intervention is needed.

My goal is like what you said, to create an engine by creating a game and then having the reusable parts for later. That's what I mean by creating an engine I suppose.

The thing is, as a programmer you'll always end up reusing parts of your work. Whether you eventually want to bundle those parts into an engine, a framework, a library is a often mostly a matter of practicality.

Once you've made your first game, you'll end up with a bunch of source files. When you start working on your second title, you might refer back to that code and see if you can reuse some of it to save time. After you've copy and pasted it into your current project, you might realize that your old code can be improved significantly (reducing complexity, improving performance, making it more generic, etc).

After a few more games, you realize that this boiler plate code has become pretty static and instantly reusable over time. To save some of the hassle of importing source files, you compile it into a library that can easily be dragged into and out of any existing project. Perhaps after a while you have a created a bunch of libraries that more or less rely on each other, or are related because they all contain common functionality found in games. And you start calling it your engine.

Most of us don't even reach that last stage, mostly because by then you realize that using third party technology saves you enormous amounts of time and frustration. One of the reasons this very website no longer runs on custom software.

One of the most valuable assets of a developer is experience. So what ever you do, it can never be bad. But one thing that keeps people from gaining experience is losing their initial enthusiasm because they failed to meet their unrealistic expectations.

You're not missing out by using existing software. The more you know, the more you realize you don't know. There's always another layer: you might be an expert in using SDL/OpenGL and still know very little about the drivers or hardware it interfaces. I mean, if Richard Feynman can't even explain magnetism... ;)

[quote name='bean.' timestamp='1328418434' post='4909737']
My goal is like what you said, to create an engine by creating a game and then having the reusable parts for later. That's what I mean by creating an engine I suppose.

The thing is, as a programmer you'll always end up reusing parts of your work. Whether you eventually want to bundle those parts into an engine, a framework, a library is a often mostly a matter of practicality.

Once you've made your first game, you'll end up with a bunch of source files. When you start working on your second title, you might refer back to that code and see if you can reuse some of it to save time. After you've copy and pasted it into your current project, you might realize that your old code can be improved significantly (reducing complexity, improving performance, making it more generic, etc).

After a few more games, you realize that this boiler plate code has become pretty static and instantly reusable over time. To save some of the hassle of importing source files, you compile it into a library that can easily be dragged into and out of any existing project. Perhaps after a while you have a created a bunch of libraries that more or less rely on each other, or are related because they all contain common functionality found in games. And you start calling it your engine.

Most of us don't even reach that last stage, mostly because by then you realize that using third party technology saves you enormous amounts of time and frustration. One of the reasons this very website no longer runs on custom software.

One of the most valuable assets of a developer is experience. So what ever you do, it can never be bad. But one thing that keeps people from gaining experience is losing their initial enthusiasm because they failed to meet their unrealistic expectations.

You're not missing out by using existing software. The more you know, the more you realize you don't know. There's always another layer: you might be an expert in using SDL/OpenGL and still know very little about the drivers or hardware it interfaces. I mean, if Richard Feynman can't even explain magnetism... ;)
[/quote]

Ugh I meant to upvote this, not downvote it. Can someone be nice and upvote it please? I hit the wrong button . Apparently the software does not allow you to change your click if you misclick. The irony of course is not lost on me, but seriously why is the downvote button on the right? O_o .

Anyway I fully agree with the comment about experience. Failure is a great teacher, however it can be fairly demoralizing. We are not trying to shield people from "learning the hard way", so much as to encourage them to persue a path that might keep them from demoralizing themselves to a point of quitting.

If you jump in the deep end and nearly drown, chances are high that you might never swim again. But if you wade slowly in the water and work your way to deeper depths, you might realize that the water is not so bad.