Meeting my Unreal Engine mentor

This week marked a milestone in my Game Programming Foundations course at CG Spectrum: my first mentorship session with Firas Hosn, who leads the Unreal Engine modules.

Having worked at Silicon Knights, Ubisoft, Build A Rocket Boy, and Splash Damage across AAA titles like Call of Duty, Watch Dogs, Far Cry, Splinter Cell, and Too Human, Firas brings decades of experience to the virtual classroom.

Going into the meeting, I’ll admit I was a little starstruck – but I’d also prepared a notebook full of questions about Unreal Engine versions, Blueprints versus C++, and how large-scale games actually get built.

Here’s what I learned.

Engine Versions & Compatibility

My first question was the one every developer grumbles about eventually: what actually breaks between Unreal Engine versions?

The answer lies in binary serialization. Unreal’s .uasset files are binary blobs, and their format changes between engine versions as the underlying libraries are added, removed, or restructured. New releases come regularly – minor versions throughout the year, major versions every few years – but backward compatibility only flows one way. Older engine versions simply can’t read assets created in newer ones.

What surprised me most, though, was Firas’s answer about what studios actually run in production. Despite the constant drumbeat of new releases, games in development generally stay on older engine versions. Studios only upgrade when it’s genuinely necessary, because an engine update mid-production can mean re-validating enormous amounts of content. It’s a useful reminder that the “latest and greatest” isn’t always what ships.

Blueprints vs. C++

Coming from a C# background, I couldn’t resist asking whether Unreal’s Blueprint system is essentially reflection over C++ code – effectively visual scripting wired into the engine’s type system. Firas confirmed it: the same fundamental idea as C# reflection, though Unreal’s implementation is somewhat more limited in scope.

The more interesting question was the ratio in practice. Firas had seen a game built entirely in Blueprints – no C++ at all—and notably, it was one of the best games that’s ever come through the course.

I followed up on this later in my course Slack channel and was pointed toward Alex Forsythe’s writing on the topic. The consensus: both get used in real projects, Blueprints carry a modest performance overhead compared to C++, but neither is objectively “better” – they’re tools with different strengths.

As someone who instinctively distrusts visual scripting, hearing that a Blueprint-only game could be genuinely excellent was a useful corrective to my bias.

Large Maps & World Streaming

Games like Sea of Thieves present an obvious engineering puzzle: how do you manage a world that size?

The answer is sub-levels and streaming. Large maps are split into smaller sub-maps, and Unreal’s level streaming lets those chunks load and unload dynamically – with crossover areas stitched between them so players never notice the seams.

This was the answer that most changed how I picture game worlds. What looks like one continuous ocean or continent is really a collection of discrete regions, carefully orchestrated behind the scenes.

Split-Screen Implementation

I asked about split-screen multiplayer – a feature that feels almost antiquated nowadays but still matters for local co-op.

In Unreal, you specify the number of viewports in project settings and the engine automatically divides the screen accordingly. That said, it doesn’t handle “crazy numbers like seven splits.” There’s a practical limit built in.

It’s refreshing to know the engine handles this infrastructure for you. Not every engine abstracts this cleanly.

Perforce & Version Control

I wanted to know about Perforce as a Source Control Management tool, and how it compares to Git or SVN. Perforce is functionally similar to other SCMs, but it has file locking for binary assets – which matters deeply in game development.

For readers coming from software backgrounds: Git can’t merge two concurrent edits to a .uasset file. File locking prevents that conflict before it happens, which is why many studios still prefer Perforce for game projects despite Git’s dominance in other domains.

How Engines Differ

Are the underlying systems - audio, physics, rendering - the same across engines?

Yes and no. Library dependencies are mostly identical across engines; most wrap the same third-party tools. What separates Unreal from competitors isn’t reinventing these systems, but packaging them together exceptionally well.

Team Structure in Game Studios

Finally, I asked about how teams are organised. Generally, studios are split by discipline: art, programming, audio, each with their own teams.

But at some places (Naughty Dog, for example) teams are split by feature instead. One team owns combat, another owns narrative, and they cross disciplines.

How a studio organises humans turns out to be as important as the tech stack.

Thanks to Firas for answering all my questions! I’m really looking forward to learning more about Unreal Engine and game development in general throughout the rest of the course.

If you’re starting your own journey in game dev, my advice: talk to people who’ve shipped games. The difference between textbook knowledge and production reality is bigger than I expected!