Well, when I started with Unity I also only knew C++. You'll find that the syntax is almost exactly like C++. So instead of learning C#, do the tutorials and get familiar with the syntax but focus your efforts towards understanding the Unity API. Because the majority of your programming will be based on functions/variables that already exist within Unity.
Since I am not interested into making a game (ie: campaign, story, etc) I think that I'll try to make my very own engine. I already know OOP but I have no idea how to implement physics. Do I need some extra libraries/APIs/Tools or is it all about coding?
It really depends. There are API's like Box2D and Bullet that you could use to implement physics or you could code it yourself. When it comes to implementing physics you generally have two aspects to look at. Detecting a collision and resolving the collision. Now before you can start with your 3D physics you're going to need to do 2D.
Now there are thousands of ways to to implement a physics engine and even more ways to optimize them. I am not too experienced when it comes to physics and I don't want to give advice that is above my skillset so I will provide you with some links that I have used to implement physics. Most of the material is the same but covered in another way or maybe with more details, by studying all of these you'll hopefully be able to understand how a possible implementation could look. Hope it helps.
Firstly you are talking about two completely different disciplines found in game development: A programmer and a 3D artist. I am no artist so I won't be able to help you regarding the 3D modelling, but you need to decide what you are going to focus on. I am a programmer so I can give you some advice from my perspective.
Making a game engine without any previous experience will be more of a learning experience rather than actually finishing it and developing a game in it. If you want to improve as a programmer and love solving complex problems while maintaining a good architecture try and make your own game engine, BUT if your goal is to actually develop a game then using an existing engine is probably your best option. The reason I say this is because learning about all the different implementations, systems and methods in a game engine is a very long process and can be quite daunting to new programmers. However, since you specifically asked how to implement your own engine I will provide possible steps to take concerning both processes.
Using an existing engine:
There are a lot of other engines to choose from so doing a quick search on google will get you far.
Creating a custom engine:
The thing about game engines are that you won't find a tutorial anywhere that goes step by step in implementation, so a lot of research is involved. By researching modular systems found in a game engine you can learn more about the implementation of such a system.
Now there are a lot of engine systems that are not that important for a basic engine, for example: a memory management system. So without further ado here are some of the more critical systems found in a game engine:
- Input manager: You need some way to convert input from the user into logic that the rest of the engine can understand.
- Rendering engine: This is the system responsible for drawing all your objects, an API like OpenGL or DirectX is used to do low level communication with the hardware.
- Physics engine: Responsible for detecting and resolving collisions.
Now those are only the critical parts, you will maybe need a event/messaging system so that your different systems can stay decoupled, or a interpreter if you want a scripting system. I can go on, and on for quite a long time discussing resource mangers and state management systems but as I said those are all research topics.
Steps in the right direction:
If you are set on creating a engine the first thing you will want to do is learn an object orientated language like C++ and master it. You want to make sure that you understand inheritance and polymorphism as well as knowing your object orientated design principles.
Then start creating your own games using a library like SFML. Note that I said games, not game engines. SFML is nice because it already contains a rendering engine, input manager and various other systems that are useful for creating games without diving to deep into various systems. This will get you acquainted with main game loops and object hierarchies.
The one thing that SFML lacks is a physics engine. So your next step could be to implement a very basic physics engine that detects AABB (basically a box around an object) and then resolves it.
As your projects grow in size you might feel overwhelmed because everything feels like a big blob of code with new bugs popping up after every feature. This is a good indication that you need to start investing time in design patterns. These patterns are there to solve problems that occur a lot when programming in an object orientated language.
After a while a game engine will actually evolve out of your games (or this is how it worked with me!). But the thing is, as you dive deeper into the various systems it takes a lot more time to actually get something done. Remember, you actually get programmers that are "specialized" in a certain field like physics or graphics. For a single programmer to learn techniques spreading over multiple domains takes a s***load of time and dedication. The thing is I love game architecture and implementing all of the different features but because it takes so long I divide my time between making an engine and actually making a game. 2-4 hours a day I will spend on my engine and 2 hours I will work on a actual game inside Unity.
I hope I helped a little bit and remember this forum has great resources and a nice community if you ever get stuck on something.
EDIT: I gave very vague steps on how to start with a game engine. Shoot me a message at anytime if you want to know about more concrete steps you could take, this is of course after you mastered an OOP language