Switching from other engines

This guide is for you already experience in game development.

Updated about 4 years ago Edit Page Revisions

This guide is for you already experience in game development. Especially if you're already published game built with any other engine and now you're about to switch to Unreal Engine. Or perhaps your team simply gonna spend a week's evaluation this engine, check if it's a good fit for your team and next projects.

This is not a "how to begin" for newbies.

Programmers

If a given programmer is already familiar with C++, switching to Unreal Engine should be relatively simple and pleasant. Engine's core is basically an extensive C++ library tailored for developing multiplatform video games.

The beginning is definitely for programmers who used different languages like C#. Don't worry, they don't have to learn all the low-level details of C++. Unreal C++ in big parts feels like an advanced scripting language. The engine provides a ready-to-use programming environment, tooling.

Read about the Programming section of the article on differences between Unity and Unreal. It describes a lot about Unreal C++.

Blueprints

If you didn't utilize visual scripting in your previous engine, or it wasn't as ubiquitous as blueprints... well, designers and artists will be happy to script, prototype and implement a lot of things using blueprints.

But...

Don't trust marketing saying "blueprints allows to make a game without coding". Visual scripting is coding. Don't let non-programmers go wild without the supervision of engineers. Don't let them believe they could implement things in blueprints for years without learning a few basics concepts of programming/engineering. It's not voodoo magic, and they don't need to learn C++. They should, however, learn a few essential things.

  • Fundamental Blueprint Practices - short article describing the common issues with blueprints in a project. Easy to avoid, if not ignored.
  • Let engineers explain non-programmers concepts like object-oriented programming and clean system architecture (don't end up with half of the game implemented in single blueprint), memory management.
  • The best approach is to implement systems and tools in C++, but leave all small scripting in blueprints. Visual scripting properly used should give non-programmers freedom of prototyping, implementing small features and game events. Programmers shouldn't spend time on dirty prototypes in blueprints, these can be later reworked as C++ system - after prototype got accepted as something you want in the game. Let programmers focus more on systems and editor tools. Although they should understand blueprints and know how to use existing engine systems.

Production setup

  • Consider using Perforce for the version control system. 99% of Unreal project is composed out of binary files and nothing handles binary files with file locking better than Perforce. Read a brief description of Perforce.
  • Set up Continuous Integration System early.

Coming from Unity?