If you are 16 and are able to program in C++ and write a small test engine with the architecture described in the GCC4 book, and somewhat understand it, you are on the right path.

When I was 16 I was just breaking through in understanding C++ completely, and was able to do some REALLY basic game stuff, I made a scene graph and tried to base my entire engine around that.

Just keep practicing, reading, programming cool stuff, asking for help, and you'll get there.

Originally posted by Nickie2
Hello, I'm currently sixteen years old and I'm really interested in game development(as you can see). I know you are busy people but I have to know this.
SourceCode
This is my project I've been working the last month. First of allq is it normally to take me so long time to do something like this?

Yes. Game programming takes a LONG time. The Sims 3 took like 6 years. The Sims Medieval took 2 years and it started with The Sims 3. A very basic game can take months, even when you're an experienced developer.

I glanced at some of the code in the repository and noticed a few things. First, there seems to be a complete lack or organization. You should organize files into logical directories to keep them nice and separate. When you have 20 files, it's not a big deal. When you have hundreds or even thousands of source files, it becomes critical. Here at work, we have nearly 200 projects (yes, 200 separate vcxproj files) across three or four solutions making up the entire game. It can get pretty crazy at times, so organizing your files up front is a good thing.

Second, I noticed that everything is public. You should never have public member variables unless there's a real reason to. In my entire game engine, I have one public member variable. And I'm not proud of it. Any const static variables are the exception to this rule.

Third, your naming conventions are inconsistent. You should strive to be consistent in all of your naming conventions. For example, some places you use the GCC style of having V in front of virtual functions and other places you don't. You should choose one and stick with it. It's more important to have a consistent coding style than a "correct" coding style in almost all cases.

Currently I have no idea how to avoid dependacies. Seriously. I have compile time of 3 minutes and I haven't even started physics and scripting(scene graph is unfinished, I've got no frustum). When I started I had no idea about design patterns. I think this will take me down later. Any advices?(I'm currently reading this.
Thanks.

There are two types of dependencies: the first is an architectural dependency and the second is a source file dependency. I see both as problems in your code.

Architectural dependencies are much harder to deal with. Architecture is something you'll work on for your entire career. Even experienced engineers like Mike and I still have to sit down and think through an architecture to ensure that any dependencies are necessary and reasonable. Reading up on design patterns is a good first step, so I'd keep up with that. Unfortunately, this is one of those things that requires you fall into the same pitfalls we've all fallen into in order to learn. Humans learn best by trying something, failing, reflecting on why they failed, and trying again. Once you've had to rewrite your entire engine for the fifth time due to an inflexible architecture, you'll start learning why and how to change it.

As for file dependencies, a general rule of thumb is to avoid #include'ing anything in headers. For example, Actors.h includes TransformComponent.h. Not only does this break the abstraction (actors should never know about concrete components, only about the Component interface), but I also don't see anything in the file that uses anything in that header. You could probably just delete that line. Same thing with SceneManager.h; I don't think you're using anything from that file in Actor.h.

PS. I Posted a thread about scene graph and event manager soon. Now when I'm to the game logic I see the real need of them. It is real pain to get some messages to their destination without the manager.

Told ya.

-Rez

One of the things that has helped my out a lot in my personal code is to follow google's coding style guide.
google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Any decent development company probably has their own style guide that they adhere to, but until you get to the point of actually working at a company, it couldn't hurt to stick to one so that you are used to writing your code in a structured manor.

This is one of those things that was never taught to me in school, and when I look back at most of my project, I tend to cringe...

Schools are generally REALLY bad about teaching good naming conventions, code consistency, and commenting. It drives me nuts.

I agree completely with Kl1X said, you really should just choose something and stick to it. Google's convention is just fine, although I personally disagree with several things. Read through the last "Parting Words" section. That's pretty much the philosophy that follow in the professional world.

-Rez