Hi, I'm really interested in making video games and I've been reading a lot of beginner posts on this website and a lot of people ask what game engine they should use to make their games. A lot of people name engines, but a lot of people also say that you should make your own. My question is what really is a game engine and how do you make one?

Please note unless you think it would be a lot of fun to make an engine... You could easily find yourself spending years making an engine without ever making a game. Or you could make a game with an existing engine in a week or less. Just make sure you're happy with your priorities.

My question is what really is a game engine and how do you make one?

A game engine is a system for making games—an application, or more commonly a library, providing services such as audio & video output, controller input, timing, physics, and so on. How do you make one? You don’t. If you want to make a game, you should make a game. You will not accomplish that goal, nor really improve as a software developer, by creating middleware without specific goals and requirements in mind.

Just pick an engine (or less—a basic graphics+audio+input library such as SDL is fine) that’s compatible with your style of thinking and/or your preferred programming language. Use it to make something. If you encounter limitations, take the time to understand and work with them. Working under constraints will help you think more creatively. Keep a diary of these situations and maybe next time try a different engine.

You can learn a lot by making an engine—about systems programming, graphics, audio, input, API design, and infrastructure in general—but it’s best to fight on a single front. Want to make a game? Take advantage of the work that others have done. Interested in engine design? Do it as a learning exercise. And anyway, you can learn all of those skills in other ways, incidentally, in the process of creating useful software.

For your first game project? Forget it. Just write a game, get familiar with the key concepts, spend time learning the libaries you will need to use regardelessly (DirectX, OpenGL), if you really plan on writing a game engine at some time. If you plan on using some libaries to make things easier for you, like SharpDX for graphics or SFML for input etc... , then start with using them in your first game projects and get familiar with them. I wouldn't totally agree with "Don't write a game engine" in the way that this sentence often is put, but I do have to confirm that writing one for your first projects is just ludacris. The reason being, that your first games code will suck. It will, there is no way around it. Writing an engine means writing code that is somewhat meant to last and reused, and if you don't know what you are doing you'll end up writing an engine that is so convoluted and horribly designed that writing everything from scratch would be easier than using it in future projects.

So now that you've written a few games and grown more and more on coding and game programming concepts, if you are still willing to write your own engine, be aware: Its not a task that will make things easier and faster for you. It will always take more time to write your own rendering architecture and graphics facilities than to use an existing solution (like Ogre3D, Irrlicht, etc... I'm not even talking unity or something like that). If you want to really just write games, eigther continue to code them, probably reusing some of your old code, or switch to something like Unity/Unreal/CryEngine and such. I'm not saying that the results of you writing a game engine might not be practical, but you have to see it as an in-depth learning experience, and not something that will save you time on making games. If that is your goal, again, screw the idea of making your own engine. Its never going to pay off. By the time you've probably gotten your engine to a point where its almost finished, even if you'd spend 8 hours a day just coding on it, the technology you used will already be outdated and you'd have to start over.

If you still want to make a game engine, because it doesn't make you uncomfortable that you are basically wasting your time doing so, than I can only give you an advice, sort of like you've already been told: Don't just write an engine, write a game to support it. Ideally, I'd divide your work into two layers: The engine layer, and the game layer. Treat the engine layer with care, spend some time thinking about the design, and keep in mind its the code you want to keep using for multiple projects. Dont hesitate to write code in that layer somewhat quickly to get it to work, but always make sure to come back and refactor it. Now that game, whatever you are working on at the same time, you should treat like just that: A one-time throw-away project. This is the only realy advantage I can see from writing your own engine alongside with a game: You can hack the gameplay/game logic as dirty as you want, because you've already put every bit of code that will be reused in the engine. So on the games side, just write code as fast and ugly as you please, once you're finish, only the engine you've written alongside is going to be carried on.

Which brings me to my final important point in this approach, always start coding from the games side. Don't just "I think I could use that feature at some time, I'm going to put it in the engine", but instead think about what feature your game is going to need next. Think about whether it is supposed to be reusable. This of course depends what your goal is: Do you want to have a RTS-specific engine, or something more general like Unity? In the former case, there'd be probably more code that goes into the engine, while in the latter one most genre-specific code would probably only last in the game. Keep in mind anyway, you can always use the game to experiment and move code that has prooven to work over in the engine, if you want to.

Just some thoughs of top of my head resembling my own experience coding an engine, hopefully some of it helps.