Switching From Unity To Unreal

So I decided to switch to Unreal. I explained my decision in a lot of detail and I don't have much to add to that. The main reason I decided to switch was project architecture and productivity. I can't afford wasting time on creating or managing a framework. The issue is that programming in Unity is very limiting to me. Almost all programming is done in components or scriptable objects. There's no clean, direct access to the engine or game loop. The prefab system is clunky and sometimes buggy. Unity also relies heavily on an event driven architecture. While there are some benefits to this style, I notice that as a project expands it becomes less structured, more difficult to understand, maintain, and extend. It can also decrease performance, increase coupling, and make it difficult to design blocking operations, which are very useful and sometimes necessary in certain situations. Unreal also uses events, but not more than necessary.

I've mostly just been porting C# scripts from the old Unity project to C++ (my first language) in Unreal. I've had to make a few changes to the architecture since not everything is 1:1, but most of the logic is useable.

I also figured out an algorithm for calculating both the entry and exit point of a line intersection. This is almost trivial for a single component, but I wanted intersecting components to be treated as one continuous intersection. The solution took a few iterations to figure out, but it's actually pretty simple.

We have a start location and an end location. We want all collection of all hits from the start location to the end location, marked as being either 'entry' or 'exit'. We can then iterate through that data to calculate the 'intersection depth' (0 being the same as the initial intersection depth, 1 being the initial plus an additional component being intersected, etc) at that hit. Based on the intersection level at the start location, this can tell us when a continuous intersection is entered and when it is exited. So we start by casting a ray from start to end, detecting all hits. Then, we cast another ray from end to start. This generates two lists of hits, the 'entry' hits and 'exit' hits, so to speak. Now, we want to store all this hits in order of distance, keeping some identifier for whether it's an entry or exit hit as well as some way to reference the hit result. There's a way to iterate through the two lists in an interleaving fashion to efficiently combine them into a single list ordered by distance. A simpler, less performant way is to just combine the two lists and sort them by distance. Finally, store a variable for intersection depth and iterate through this collection, incrementing for entry hits and decrementing for exit hits. When you adjust for the initial depth, 0 will be no intersection and anything above 0 will be an intersection, continuous or not.

You can use this data in many different ways. If you want the first continuous intersection, you can just find the hit result associated with the first 0 (if it exists, that will be the entry hit) and the hit result associated with the second 0 (if it exists, that will be the exit hit).  Anyway, that's my method for detecting continuous component intersections. I'm not sure if I'll end up using it in the game, but I was originally thinking about it to help with tracing through volumes.