That’s actually a bad idea. You’ll want portable code that will run at least on windows, linux and mac. Doing that yourself will be royal pain.
The best idea is to grab a library or framework that will abstract away platform-specific initialization code and then concentrate on writing the rest of the engine.
I’d suggest to just start with opengl. Learning C++ will take few years.
Better yet learn C++ with SDL and OpenGL. Boilerplate code necessary to create and use the OpenGL context in an application is significantly easier using SDL than it is using platform-specific APIs like Win32. Additionally it eases the process of handling audio, input, threads, etc.
By curiosity, except for the fun and learning experience why would anyone want to develop his/her own game engines? What features can this give that is not possible in a current game engine? Why spend so much time creating a game engine to make a game instead of use the time to make the game?
I do not get it!
That’s a bit of an overstatement…
More knowledge is always a good thing. Creating your own tools has its advantages and disadvantages. The upside is that you have a lot of control, and you can build your game very performant and efficient, you don’t have to build things in that aren’t used. Downside is you have to build all the little things that you do need, and maintaining is an ongoing challenge given regular platform changes.
We had about 2(ish) internal engines a few years back. While they were super performant, (still in some way more than Unity for certain things), they were inconstant development, new features often got sidelined for overhauls to support updated devices. Particles, for example, were driven by xml, not exactly an efficient development pipeline. When we finally gave Unity a shot for a production game, within a year we adopted it across the board. Ultimately, it allowed us to put most of our focus directly into the games, and not the engine. Unity is dedicated to keeping all the platforms playing nice, and provides not only a solid base, but extensibility of the editor still allows us to have a very customized pipeline. I have helped build a couple of engines in the past, but these days, I really want to build games.
Nope. Might be an understatement, though.
Basic syntax can be learned in a few days. Wrapping your head around the language and its capabilities will take few years. I’d say 3 to 5 years. The language is very complex, and there’s popular belief that “nobody on the planet knows entire C++, (including Bjarne Stroustroup)”. There’s some truth in that belief.
Fortunately, as can be seen by how useful and popular it is, you don’t need to know the entire language.
Maybe if you spend 2 hours a week working with it. Much, much faster if you start actively developing in it.
Maybe if you’re using a very small subset of it in extremely limiting conditions without ever bothering to look at it in depth.
Also, it is always possible to write a mess. You know, like “I can program in any language as if it was fortran”.
Or, framed alternatively, “if you deliberately avoid the parts that are so complicated that they take people decades to learn and eons to debug?” 
In that case, it would be reasonable to ask why the heck are you using C++ to begin with.
The point of C++ is power and control it gives over every aspect of program. This language pays off after you spend a lot of time, develop some sort of discipline, and study it in detail. However, if you, say, throw away 75% of language, you won’t benefit from it much, so why bother with it in that case?
If you know any language - ie know how to program - then C++ isn’t a monster. I was easily able to make a few games on it even publish one of them to appstore before Unity days.
I probably got a basic hang of things in a few days. After a couple of weeks I was able to do anything I wanted. The key thing is - I was probably doing things that weren’t the best way to do do them as I had no formal training in it. But it was fun, I was capable and had I stuck with it instead of moving onto Unity, I’d probably have grown my experience project by project.
C++ isn’t this fearsome beast any more than C# is and there’s plenty of mystery to be had with C# too. TLDR don’t panic and internet noise makes things seem more scary than they are.
Engines? I have made a really good one for 2D in C++. I’ll talk about that. I had some pretty clear ideas from the get go what I wanted it to do: I wanted it to take care of everything that it could reliably do without human input such as draw call sorting, vbo handling and so on - so all I needed to do was type DrawImage(params…) and it took care of it.
So before leaping into 3D engines, let us see some clear goals. Perhaps you’d like to use DX11 and move some quads around? Should be a suitable starting point.
What if you already know java?
It’s a fantastic library for non beginners too L4D2, FTL, tons of great games made with it. Having the full support of valve behind it is nice too if you plan to deploy to Steam.
There’s no reason you can’t try writing your own engine from scratch, just be aware that, depending on how feature-complete you want it to be, it can be an insane amount of work. You would need to develop a solid understanding of the following:
That’s a LOT of complex concepts to learn!
Bear in mind also that the process flow needs to be considered, which is easily the hardest part. Drawing a 3D scene is actually quite straight forward, there are loads of tutorials out there ranging from simple rendering to deferred shading and advanced techniques like SSAO and even real-time global illumination.
The problem is how do you integrate that renderer into the wider solution, providing an integrated API that means you can actually build a game? That is where most of your time will be taken up.
Err. Where did you get that idea?
Valve have nothing to do with libSDL, last time I checked. l4d2 runs on source engine.
The SDL site proclaims loudly and proudly that Valve uses it. That is of course not the same as what is implied by putting “full support” behind something.
It does run on the Source engine. They claim that Source uses SDL for a bunch of its stuff.
Edit: Correction / clarification.
It is the other way around.
Engine like source or unreal can use SDL as an abstraction layer between operating system and engine. So, engine runs on it.
…
I checked the web and do not see any mention of SDL being “officially supported” by Valve. It has been used in many games over years, but I’ve never heard of something like Valve backing the project.
If you want to learn opengl, in my opinion this is the best tutorial :
There’s material on the subject all over on the Net. Books on it as well.
I’d suggest defining just a simple base for the beginning such as a collision system or managed rendering system. Of course, it all depends on how low you go. These days I wouldn’t drop down lower than something like DirectX or openGL, openAL. All three of those are solid in my experience.
There are many great reasons to do such a project. Ranging from picking up a deeper understanding of what is going on under the hood in something like Unity to being able to develop a system that is more logical and efficient for you to work with.
I’d also like you to consider checking out Monkey X or heck even use Unity itself to make your own engine. You don’t need to jump to C++ to do it. The main thing is figuring out what you want your engine to do. Sketch it out. What pieces does it have? Identify dependencies. Define your goals. What HAS to be in your engine and what would be a nice EXTRA to stick in your engine. To me design and clear goals are always the most important thing. You can then implement in anything.
So as you can see in the end it really depends on your goals. If you’re after raw graphics bliss then find the best opensource graphics engine and use it. Or use CryEngine or whatever it is that people consider have the best graphics. Then build your own game engine around it.