So getting to the main point, my questions are what does a game engine really need? How to structure the engine in a industry-standard structure? (I'm still a student, but I'm going to graduate soon...) And last but not least, how do we make a game using this engine in question?
The fundamental point of a game engine is that a game engine is just a concept. If you make a breakout clone then the code that relates to how the game itself interacts is usually what you would consider the "game logic" layer. For instance the code that says if a ball hits a wall it has to reverse velocity and bounce off the wall, that would be logic level code.
On the other hand, the code in the game loop that gathers input on how to move the paddle, then code that actually renders the ball and the bricks and all that, that could be considered engine level code.
The thing is there isn't any "rule" on how seperated these things have to be, many a beginner and even professional will happily make a ball class that should be game logic and they put a bunch of opengl drawing commands in it, that usually is bad in terms of engine seperation because it means that the parts of the game depend heavily on each other, and are coupled. If you want to change from opengl to directx suddenly instead of having to go into the "rendering subsystem" and change all the "draw a thing" code into directx, you'll instead be going into every single game object class and changing it, bad news!
The only real difference between that and something supermassive like unreal is:
-More parts: big engines tend to be generic, they tend to be designed to happily render different file formats, different shapes and sizes and materials and so on. They also tend to have more subsystems that you might not even use. For instance if you want to play full motion video in your game, you'll probably need a library for that. Most big engines have a lot of these features built in standard and extensively tested and performance benchmarked.
-More generic: big engines, even if they aren't sold, are often used to develop multiple games because they are seen as an investment by the team with programming time. If they spend two years making an engine and it makes three games with some minor modifications, they've saved perhaps a year of extra programming time for each title.
-More people and expertise: With size can often come advantage, between the years of experience of the engineers and money poured into big engines they tend to be a lot more tested and designed with performance in mind. For someone like an indie there isn't usually practical purpose to spending three years improving the framerate of your pong game, with a large 3d open world game with lots of shaders and nonsense, performance is critical, so they have a lot of people spend a lot of time on each subsection of the engine to make them perform as optimally as they can.
So what should YOU do? That depends on what you want to make. If your plan is to become a programmer for a living in the AAA industry it is definitely worth making your own projects. Experience is never wasted in programming, learn that lesson early. Using unity or something isn't a 'waste of time' but it will teach you -specific- things. You won't ever learn the fundamentals of making a game engine by using unity, like the game loop and the rendering libraries and stuff like that. Realistically if you get into the game industry as a programmer, or even as an indie, you will probably need to acquire that knowledge at some point.
It really comes down to goals, if you just want to design games then I would never recommend coding, even using an engine like unity might be too much "lower level" work for most people. On the flip side if you wanted to become specifically a programmer an learn the real meat and potatoes of how a game functions as a program, you might get a good start using an existing engine, but eventually you'll have to learn that lower level stuff.
