i would imagine it's easier to delve deep into UE since their source is actually available. I dont know if you can step into unity's code at all.

The power of unity is that you don't have to delve deeper, just start it up, make a script and start writing code. The weakness then is that all the components you code against are horribly bad/slow, so for a bigger game this approach wont scale, but if you are a programmer and just want to code a simple game unity can get you there in a weekend. First project I made in unity was a top down shooter with simple random map and powerups, took a weekend, I've tried using unreal but it is way harder to interface between code and assets and ui there.

Edit: My point here is that in unity you can easily write your own replacements since it is so easy to write new components in C#. This means you don't have to learn how unity did things, just write your own if you don't like what they did. The only exceptions here are physics and the renderer, you can't easily replace those.

> The only exceptions here are physics and the renderer, you can't easily replace those.

While physics is in the engine itself you can definitely replace or modify the render pipeline. Unity comes with a built-in legacy pipeline but nowadays you mainly use either the High Definition Render Pipeline (HDRP) or Unified Render Pipeline (URP) both of which are open source packages. Meaning they are modifiable. They are also both based on a common base class: Scriptable Render Pipeline, which you can extend to make your own render pipeline from scratch.

There's a great tutorial series for doing so here: https://catlikecoding.com/unity/tutorials/custom-srp/

In my own work I generally work with URP and modify it to suit our needs.

Source code access in Unity is available but very expensive, even for large studios.

Coming from a background of working with engines where the source is available it has been frustrating to me being unable to dig into or modify the engine. Especially when I'm at the mercy of some obscure engine bug. But most of the time I've managed to make do.

This advice is a bit generic - but look at either the official examples or tons of github projects that have C++ in them and try to understand how they work - that's the thing that worked for me.

Thanks! That's one good piece of advice actually. I'll try to find similar projects.

First of all, you have to manage your expectations and be mentally prepared for the fact that you will just not get most of the engine. UE is a massive project (and that is an understatement) and you will be a VERY good student if you just grasp the gameplay framework (core functionality in c++) and a few specific things (if you understand rendering, you may fiddle with the renderer, if you're an audio engineer, mess with meta sounds etc.). If you just look at the amount of code being pushed into the UE repo, you will soon realize that no single person will ever be able to grasp and contextualize even 10% of the engine. It's just not happening. With that out of the way, what I found incredibly helpful was the Ue4/5 cpp game courses on Udemy from Stephen Ulibarri.