Hm, that sounds like a very atypical tutorial.

Is it a "from scratch" type tutorial, which will get to arrays later?

If it doesn't get to arrays later (I would expect fairly soon), it kinda sounds a like a tutorial which might expect a bit more programming knowledge than you have already. In which case, you might be able to find a more suitable tutorial or reference before continuing where you are right now.

Hm, that sounds like a very atypical tutorial.

Is it a "from scratch" type tutorial, which will get to arrays later?
If it doesn't get to arrays later (I would expect fairly soon), it kinda sounds a like a tutorial which might expect a bit more programming knowledge than you have already. In which case, you might be able to find a more suitable tutorial or reference before continuing where you are right now.

It's the programming practice and principles using c++ tutorial by Bjarne

I'm curious, why the move "back" from "modern C++" to C with classes?

I use a mixture of both styles.
Modern C++ styles are great for RAII, resource management, clean code with solid invariants, easy composition of objects, etc....
C-styles are great for the KISS and YAGNI principles, non-bloated code (smaller, very simple, isolated systems with minimal dependencies) that's easy to maintain or even re-write.

e.g. a model loader might be a 'modern' C++ class, that implements some kind of resource loader interface, and can be plugged into some kind of opaque file-system interface.
However, inside the model loader, the internal data-structures that make up a "model file" might just be plain old C structures that can be memcpy'ed around the place.
Actually, for simplicity, I don't share any code between my engine's model loader, and the tool that creates model files -- instead a specification document of these data-structures is all that's shared. A C# model convertor program can write out these binary structures to a file, and then the engine can load such a file and just cast the loaded memory block to a particular type of struct. Without any kind of parsing/deserializing step, the model file's structures are immediately ready for use

A lot of people are doing similar things with their "component systems" these days, where components are just plain-old-data, allocated in large arrays. You can then have large chunks of fairly typical looking C++ code that interact with these big arrays of plain C data.

With the responses i've gotten, [making an engine] doesn't seem scary.

People's responses are going to be extremely irrelevant, because you are not in the same situation as other people. Other people have different definitions of what an engine is, different experience levels, different skill-sets, different games to be made, different support networks and colleagues, different amounts of free-time and different expectations.
The best thing to do is start off with a big list of all the things you need to do, then pick one item and break it down into another list of tasks that need to be done to build this thing. Then for each task, break it down into another list of steps of how you'd achieve it.
Along the way of doing this, you're probably going to encounter a lot of tasks where you'll need to learn some new knowledge in order to complete them (e.g. how to use a std::vector).
As long as you've got a huge list of tasks that involve learning and discovery like this, you can't really come up with any kind of sensible time-frame or expectation of what your results are going to be like.

Great to see you made a game engine using a bunch of what i want to use too (c++, lua, physx, directx, fmod) ... and in a year.

For full disclosure though -- before I wrote my own engine in a year, I spent 4 years practicing using every feature of the GoldSrc game engine while studying, a year building a game engine around the Gamebryo graphics engine professionally, spent 4 years making my previous hobbyist engine, tested out endless open-source and publicly available engines in my spare time, and worked as a graphics programmer on half a dozen commercial games (using 3 different proprietary engines)... Then after all that, I'd learned enough to be extremely confident in making my own commercial-quality engine from scratch in a short time-frame.

Hm, that sounds like a very atypical tutorial.

Is it a "from scratch" type tutorial, which will get to arrays later?
If it doesn't get to arrays later (I would expect fairly soon), it kinda sounds a like a tutorial which might expect a bit more programming knowledge than you have already. In which case, you might be able to find a more suitable tutorial or reference before continuing where you are right now.

It's the programming practice and principles using c++ tutorial by Bjarne

I've switched books. I'm now using jumping into c++ and it explains things a bit more clearly.

With the responses i've gotten, [making an engine] doesn't seem scary.

People's responses are going to be extremely irrelevant, because you are not in the same situation as other people. Other people have different definitions of what an engine is, different experience levels, different skill-sets, different games to be made, different support networks and colleagues, different amounts of free-time and different expectations.The best thing to do is start off with a big list of all the things you need to do, then pick one item and break it down into another list of tasks that need to be done to build this thing. Then for each task, break it down into another list of steps of how you'd achieve it.Along the way of doing this, you're probably going to encounter a lot of tasks where you'll need to learn some new knowledge in order to complete them (e.g. how to use a std::vector).As long as you've got a huge list of tasks that involve learning and discovery like this, you can't really come up with any kind of sensible time-frame or expectation of what your results are going to be like.

Great to see you made a game engine using a bunch of what i want to use too (c++, lua, physx, directx, fmod) ... and in a year.

For full disclosure though -- before I wrote my own engine in a year, I spent 4 years practicing using every feature of the GoldSrc game engine while studying, a year building a game engine around the Gamebryo graphics engine professionally, spent 4 years making my previous hobbyist engine, tested out endless open-source and publicly available engines in my spare time, and worked as a graphics programmer on half a dozen commercial games (using 3 different proprietary engines)... Then after all that, I'd learned enough to be extremely confident in making my own commercial-quality engine from scratch in a short time-frame.

I needed others opinions for a reason (3 forums).

I did break down the engine features and there is one i haven't asked about because unlike other parts of an engine, this feature is not in any existing engine so google searching yields no related results.

As for the time frame issue, it's mostly what i'm learning from. For example, i used 5 books to try and get past arrays(2 books), vectors(1 book) and functions(2 books). If i had found this jumping into c++ book earlier, i won't have been asking about std::vectors because it explains things more clearly than the other 4 books even though it has less pages than the programming principles book.

There are some things you put in your post that i'll probably never do.

I might have to learn physics sooner than later so that's a good thing.

I know the engines i'll work on and the games i'll make before making mine so if the learning goes smoothly, i don't have much problems. And there are 353 days (8424+ hours) left in 2014.

I did break down the engine features and there is one i haven't asked about because unlike other parts of an engine, this feature is not in any existing engine so google searching yields no related results.

May I ask what feature this is? (that doesn't exist enywhere else)

I did break down the engine features and there is one i haven't asked about because unlike other parts of an engine, this feature is not in any existing engine so google searching yields no related results.

May I ask what feature this is? (that doesn't exist enywhere else)

Since i'm the one that'll make it, i'm still deciding the name.

...

Since i'm the one that'll make it, i'm still deciding the name.

I doubt axel1994 was asking for the name of the feature, but was instead was interested in a brief high-level description of what the feature is -- the same I tried asking for earlier in the thread.

This doesn't need to spoil the feature if you're concerned about someone "stealing" it -- it could be just a high-level statement like "it's a new rendering system based on radioactivity", "it's an AI system for making groups of people accurately simulate people getting on a bus and how they relate to the other passengers", "a new way of dynamically altering terrain based on erosion".

It could also be more technical -- "something to allow the developer to automatically texture, set up UV coordinates, etc. any given 3D model (regardless of complexity) within 1 minute".

What slightly confuses me is how you seem to certain that none of the current engines support it, given your current knowledge of programming.

While a feature might not be a bullet point on an engine's feature list, it might be possible to implement using the engine regardless.

Since i'm the one that'll make it, i'm still deciding the name.

I doubt axel1994 was asking for the name of the feature, but was instead was interested in a brief high-level description of what the feature is -- the same I tried asking for earlier in the thread.

This doesn't need to spoil the feature if you're concerned about someone "stealing" it -- it could be just a high-level statement like "it's a new rendering system based on radioactivity", "it's an AI system for making groups of people accurately simulate people getting on a bus and how they relate to the other passengers", "a new way of dynamically altering terrain based on erosion".
It could also be more technical -- "something to allow the developer to automatically texture, set up UV coordinates, etc. any given 3D model (regardless of complexity) within 1 minute".

What slightly confuses me is how you seem to certain that none of the current engines support it, given your current knowledge of programming.
While a feature might not be a bullet point on an engine's feature list, it might be possible to implement using the engine regardless.

Well, you are right about the stealing part.
This is what it is: "something to allow the developer to automatically texture, set up UV coordinates, etc. any given 3D model (regardless of complexity) within 1 minute" and automatically model it etc.
Do you think any engine that had that will not want game devs to know?

The design of the engine, who it can be used by, what the engine can create with/without coding, what it can teach and its price and some other stuff, is what will make it different.