Intermediate programmer, need advice

How well do you know the languages and APIs *really*?

Vague self-evaluations are worthless, since its incredibly rare when a person possesses both the knowledge and humility for honest self-evaluation.

That's not to even mention the relativism of scales -- for you, being an expert programmer -- a 10 out of 10 -- might mean knowing the language inside-out -- but, Google, for example, literally considers 10 out of 10 to be "I wrote/invented it", 9 out of 10 to be "I wrote a book about it", 8 out of 10 to be "I could write a book about it", 7 out of 10 to be "I'm the most knowledgeable in my team", and so on.

To help us understand how much you *really* know, tell us *what* you know.

How comfortable are you with C++?
... pointers?
... recursion?
... inheritance?
... polymorphism?
... simple templates?
... template meta programming?
... algorithms and Big-O?
... data structures?

How about mathematics?
... Algebra?
... Geometry?
... Linear Algebra?
... Calculus?
... Physics?

What projects have you undertaken? Completed?
... book exercises?
... console applications?
... gui applications?
... games?

Bonus questions:
... What's the most amount of code you've written for a single project?
... What's the most amount of code you've seen in a project you were involved in?
... What's the largest team you've worked in?


With that out of the way -- the best way to write your first engine is to *not* write your (first) engine first! Writing an engine up front requires requirements and perspective -- neither of which you have without completing several smallish games prior. Write your (small) game, and build only the necessary structure to support it -- that is, only write parts of the "engine" when the need is a direct result of the needs of the game, and don't be overly general about implementation. When you've done this 3-4 times and incorporate what you've learned with each project, you'll find that your engine has magically "evolved" into being. Your first general-purpose engine is something that should be "discovered", its not something that can simply be wrestled out of a naive mind.

How well do you know the languages and APIs *really*?

Vague self-evaluations are worthless, since its incredibly rare when a person possesses both the knowledge and humility for honest self-evaluation.

That's not to even mention the relativism of scales -- for you, being an expert programmer -- a 10 out of 10 -- might mean knowing the language inside-out -- but, Google, for example, literally considers 10 out of 10 to be "I wrote/invented it", 9 out of 10 to be "I wrote a book about it", 8 out of 10 to be "I could write a book about it", 7 out of 10 to be "I'm the most knowledgeable in my team", and so on.

To help us understand how much you *really* know, tell us *what* you know.

How comfortable are you with C++?
... pointers?
... recursion?
... inheritance?
... polymorphism?
... simple templates?
... template meta programming?
... algorithms and Big-O?
... data structures?

How about mathematics?
... Algebra?
... Geometry?
... Linear Algebra?
... Calculus?
... Physics?

What projects have you undertaken? Completed?
... book exercises?
... console applications?
... gui applications?
... games?

Bonus questions:
... What's the most amount of code you've written for a single project?
... What's the most amount of code you've seen in a project you were involved in?
... What's the largest team you've worked in?


With that out of the way -- the best way to write your first engine is to *not* write your (first) engine first! Writing an engine up front requires requirements and perspective -- neither of which you have without completing several smallish games prior. Write your (small) game, and build only the necessary structure to support it -- that is, only write parts of the "engine" when the need is a direct result of the needs of the game, and don't be overly general about implementation. When you've done this 3-4 times and incorporate what you've learned with each project, you'll find that your engine has magically "evolved" into being. Your first general-purpose engine is something that should be "discovered", its not something that can simply be wrestled out of a naive mind.

- I think I would be 5/10 on C++, and SFML is very easy so I think I am an 8/10 on it since I havent memorized every function yet. And with OpenGL I am a 1/10.
- I use pointers very regularly and I know how use recursion. I understand polymorphism and inheritance but haven't used it in my projects. I use simple templates sometimes and understand them. I don't even know what template meta programming is. I know a few algorithms and what is the Big-O? I know most data structures such as vector, map, queue, stack. I have also tried re-making those data structures and not using the STL ones.
- I am only in 8th grade but I still know Algebra and linear algebra well. We are starting geometry but I am going into AP Geometry next year. I know nothing about Calculus and almost nothing in physics.
- I have completed many book exercises and about 20-30 console applications. I have probably made about 10 GUI applications with VC++ but now I am on Ubuntu so I am about to learn QT. I have made one game, which was Pikin Sticks. A very basic version of it that was very sloppily coded.
- I have written about 800 lines of code in my current 2D game project (which is why I am asking what I should do).
- I have a small company (not really just a team) and the co-owner is writing some stuff for a 3D game and there is probably about 4,000 line of code in that project. I am involved in it a little bit.
- I have a team of two programmers (including myself), a web developer, and a game designer.

What my engine is, is actually common code I think. Its not game specific at all. Its just a menu system, subscription system (where functions can subscribe to be called in the main game loop which is called in the Engine::Update() function), and the engine class basically handles the windows, events, and main window game loop (SFML while window is open loop).

To quote Rayne:

[color="#1C2837"]

Vague self-evaluations are worthless, since its incredibly rare when a person possesses both the knowledge and humility for honest self-evaluation.[color="#1C2837"][/quote]

Pay attention! For it is very good advice!

- I think I would be 5/10 on C++,

If you program for 8 hours a day, 7 days a week, for the next 10 years, then you'd be 5/10 in C++. Do not underestimate how insanely complicated C++ is!!
You can say you're 1/10 when you understand absolutely everything in a standard C++ textbook. The other 9/10 can only be learned through experience!

I've seen some amazing games written using nothing more than global variables and the worlds longest nested if/else statement. Yeah the code sucked, but it worked, and in the process the author learned that 'functions are a good thing for next time'. Programming is, and always has been, about the experience.

and SFML is very easy so I think I am an 8/10 on it since I havent memorized every function yet.

To be an 8/10 I'd expect you to be able to pull down the code repository for SFML, make changes to the source (fixing bugs or adding new features), and then submitting your patch back to one of the library maintainers.

Memorising functions is pointless, because:
1) Library Documentation exists so that you don't have to memorise the library.
2) Functions don't get called in isolation.

The second point is important. In order to accomplish X, which functions do you need to call, and in which order? Is it possible to call the functions in a more efficient order, whilst maintaining the same result? Where does the computational saving come from? And it does it pose risks you should be aware of? This sort of knowledge can only be gained through experience (and lots of it!)

- I use pointers very regularly and I know how use recursion. I understand polymorphism and inheritance but haven't used it in my projects.[/quote]
I know about pointers and recursion too!

void recurse(int* ptr)
{
recurse(ptr);
}

Just because you know about a language feature, does not mean you are using it correctly (or wisely). Get experience using language features. This will tell you HOW to use them and WHEN!

I don't even know what template meta programming is.[/quote]
It's an interesting academic exercise, that's best done in solitary confinement. It fails as soon as you add a team member.

I know a few algorithms and what is the Big-O?[/quote]
Big-O is a measure of computational complexity.

A very basic version of it that was very sloppily coded.[/quote]

^^This^^ is good. Write another sloppily coded game, but this time try to make it less sloppy

- I have written about 800 lines of code in my current 2D game project (which is why I am asking what I should do).
[/quote]

Add lots and lots of features until you get to about 15,000 lines of code. Make lots of mistakes along the way. When it's successfully become an unmaintainable spaghettified mess, refactor the better parts out into a library or two, and throw the rest in the bin. After you've done this 3 or 4 times, you'll have a better understanding of how a game fits together. Once you've done this 20 or so times, you'll appreciate that you can never get anything right in programming, you can just do it better next time....

What my engine is, is actually common code I think. Its not game specific at all. Its just a menu system, subscription system (where functions can subscribe to be called in the main game loop which is called in the Engine::Update() function), and the engine class basically handles the windows, events, and main window game loop (SFML while window is open loop).
[/quote]

No it's just code. It's common code when it's being used by 2 or more live projects.

I found that Game Engine Architecture by Jason Gregory was pretty useful at giving a general overview of the systems that make up a game. Mostly it focuses on the graphical pipeline, states, physics and collision, and general systems. It does not delve deeply into sound, AI or networking (it does point out a couple networking architectures, but the treatment is brief). It is a very general, bird's eye view of these topics, however. This means it gives you a good understanding of the structure of various game engine components and what they do, but you won't be able to plug sample code from the book into an IDE and have a game engine. It still makes for a great starting point.

This was mentioned in the Write Games not Engines article, but you really do want to write the code to run your specific game rather than a general game. Don't try to make things too general at the start, you'll drive yourself nuts and screw up somewhere. As you write more games, you'll get a feel for which parts are re-usable, and how to make them such. These can be extracted and thrown into some libraries that you re-use in future projects. There's absolutely no shame in writing a well-coded but purpose built game.

Edit: The math might be tough for you to grasp at the moment. Trigonometry is highly useful when doing computer graphics. Calculus is also useful, but you might be able to scrape by without too much knowledge of calc. You could alleviate the mathematical burden by using external libraries for collision and physics. Still, if you know how to program well and Linear Algebra in the 8th grade, you're probably smarter than me and could pick up the math without much trouble.

Write games and learn as you go a long. For me personally (and this won't apply to everyone) I did the following....

1. Wrote noughts and crosses (tic-tac-toe) on some calculator in BASIC with just a single line LCD display
2. Wrote Othello for C64 in BASIC...the AI was completely rubbish...but the game worked, you could play Human vs Human or Human vs CPU and had a good UI
3. Wrote some random text adventures (not very good either....but real fun learning about language parsing)
4. Reversed engineered some commercial games to figure out how to do it right / faster
5. Wrote a shoot-em-up
6. Got a job in the games industry
7. Learnt from others
8. Did lot's of games

And now...many many years later....I'm still learning and love it.

To quote Rayne:

[color="#1C2837"]

Vague self-evaluations are worthless, since its incredibly rare when a person possesses both the knowledge and humility for honest self-evaluation.[color="#1C2837"]

Pay attention! For it is very good advice!

- I think I would be 5/10 on C++,

If you program for 8 hours a day, 7 days a week, for the next 10 years, then you'd be 5/10 in C++. Do not underestimate how insanely complicated C++ is!!
You can say you're 1/10 when you understand absolutely everything in a standard C++ textbook. The other 9/10 can only be learned through experience!

I've seen some amazing games written using nothing more than global variables and the worlds longest nested if/else statement. Yeah the code sucked, but it worked, and in the process the author learned that 'functions are a good thing for next time'. Programming is, and always has been, about the experience.

and SFML is very easy so I think I am an 8/10 on it since I havent memorized every function yet.

To be an 8/10 I'd expect you to be able to pull down the code repository for SFML, make changes to the source (fixing bugs or adding new features), and then submitting your patch back to one of the library maintainers.

Memorising functions is pointless, because:
1) Library Documentation exists so that you don't have to memorise the library.
2) Functions don't get called in isolation.

The second point is important. In order to accomplish X, which functions do you need to call, and in which order? Is it possible to call the functions in a more efficient order, whilst maintaining the same result? Where does the computational saving come from? And it does it pose risks you should be aware of? This sort of knowledge can only be gained through experience (and lots of it!)

- I use pointers very regularly and I know how use recursion. I understand polymorphism and inheritance but haven't used it in my projects.[/quote]
I know about pointers and recursion too!

void recurse(int* ptr)
{
recurse(ptr);
}

Just because you know about a language feature, does not mean you are using it correctly (or wisely). Get experience using language features. This will tell you HOW to use them and WHEN!

I don't even know what template meta programming is.[/quote]
It's an interesting academic exercise, that's best done in solitary confinement. It fails as soon as you add a team member.

I know a few algorithms and what is the Big-O?[/quote]
Big-O is a measure of computational complexity.

A very basic version of it that was very sloppily coded.[/quote]

^^This^^ is good. Write another sloppily coded game, but this time try to make it less sloppy

- I have written about 800 lines of code in my current 2D game project (which is why I am asking what I should do).
[/quote]

Add lots and lots of features until you get to about 15,000 lines of code. Make lots of mistakes along the way. When it's successfully become an unmaintainable spaghettified mess, refactor the better parts out into a library or two, and throw the rest in the bin. After you've done this 3 or 4 times, you'll have a better understanding of how a game fits together. Once you've done this 20 or so times, you'll appreciate that you can never get anything right in programming, you can just do it better next time....

What my engine is, is actually common code I think. Its not game specific at all. Its just a menu system, subscription system (where functions can subscribe to be called in the main game loop which is called in the Engine::Update() function), and the engine class basically handles the windows, events, and main window game loop (SFML while window is open loop).
[/quote]

No it's just code. It's common code when it's being used by 2 or more live projects.
[/quote]

Ok I am a 1/10 on c++ by your scale. And with pointers, I truely know how to use those the best out of c++. I use them everywhere in every one of my projects. Also right now I am going to try and make a little widget system for my game so I think that would and should be re-usable. Thanks for the reply.

Hey can you tell me what to do based on the above evaluation? Should I learn more? Jump into it? What should I do to learn more (what projects should i attempt), etc.

What kind of programs have you made so far? As lame as it might seem simple games like others have mentioned (tic-tac-toe, tetris, arkanoid) are great ways to get practice in writing runnable code. Also don't con volute your learning experience with the need for "cool" features. Keep things simple so you can finish more projects, and faster, thus getting more experience.

After finishing a game, and I mean finishing it, make it runnable on other people machines and complete from the point of starting the app to winning the game. Take 20 minutes and write up a summary of what you think was done well and what wasn't and why. Then do the project all over again, this time leave out the bad stuff and incorporate what you thought could've been done better.

When you're done with that do it a million more times.

Just pick a feature to add to your game and work towards it. You'll learn plenty by figuring out how to impliment a feature and then later you'll learn what problems the way you decided todo it has caused you

Programming, certainly when you are starting out, is continuous growth via experimentation and simply trying things out.

Ok thankyou both of you. I am going to go work on widgets, which will help with many menus and GUI's in the future. I am trying to make another game btw. That is what the widgets are for.

Once you've done this 20 or so times, you'll appreciate that you can never get anything right in programming, you can just do it better next time....

I really like this line. When I first started (and often still) I tried to make things perfect from the get go. Sometimes it can take alot of strength just to code something, while knowing in the back of your mind it could definitely be done better. Once you get over that hurtle though, writing code becomes alot faster. Sure you'll write stuff that will need to be fixed at certain points, but the idea is to get practice and learn from your mistakes rather than try to be perfect all the time.

Ok so this is what I think I will do. I will make a game. Then I will make a version 2 with many more features. Then I will make a version 3 with code and speed efficiency. After that, I will move onto my next game when I think I am done with the first and try to find common code to use.
EXAMPLE: So, right now I am going to make a platformmer. I will use sfml, box2d, and whatever else I need based on the extension. It will be very basic where you can just jump up over stuff to the goal. Version 2 will have npc's and powerups. Version 2.5 I will add various menu systems with the widgets I working on now. Version 3 will be when I clean up the code and try to make rendering, physics, and npc's run smoother and faster. Then I will start another game and try to find common code that I will use again for this one from my previous.

Am I on the right track? Is this what i should do for each game?

P.S: In games I have heard of things like state managers and some other things that really help the game run smoother. Where should I look or what should I read to find these?

[color=#1C2837][size=2]

P.S: In games I have heard of things like state managers and some other things that really help the game run smoother. Where should I look or what should I read to find these?[/quote]
[color=#1C2837][size=2]
Yes using game states makes your code much more readable and structured. I followed this tutorial to implement mine and I recommend that you read it as well

[color="#1C2837"]

P.S: In games I have heard of things like state managers and some other things that really help the game run smoother. Where should I look or what should I read to find these?

[color="#1C2837"] Yes using game states makes your code much more readable and structured. I followed this tutorial to implement mine and I recommend that you read it as well
[/quote]

Thanks for this. I am reading it now.