Download

Unity to Unreal Engine 4: MonoBehaviour Analogue & Migration Help

Sorry for what is undoubtedly a naive question: What is (if any) the analogue for GameObjects and MonoBehaviour in UE4?

I’m an artist migrating from Unity. If you’re not familiar with Unity, it’s absurdly easy to learn and to use, despite lacking a programming background. I learned C# over the last few years so C++ doesn’t seem enormously difficult on the surface (I’m sure I’ll discover it is) and I’m doing some tutorials, but I have absolutely no idea where to start in migration.

Is there some sort of analogue for writing components that attach to actors in the same way one writes MonoBehaviours and attaches them to GameObjects in Unity?

I’ve been watching some Blueprint tutorials and it seems quite powerful; Is the intent behind Blueprint to replace scripting for people like me who are making the shift from a script-based game engine? Or is C++ going to be a necessity if I want as much scope as C# in Unity offers me?

Blueprints is the way to go. It kinda relates to GameObjects and MonoBehaviour in Unity. But rather than putting Gameobjects in the world and then putting scripts on them, you create Classes(or Blueprints) before putting them into the world. That allows you to reuse your blueprints heavily. Kinda similar to prefabs with scripts in Unity.

So if you are an artist that needs scripts on his stuff, just use blueprints, it’s really, really powerful.

Even I, as a programmer, tend to use blueprints rather than c++ at the moment.

Awesome, thanks for the tip! I’ll drop the C++ tutorials for now and focus on Blueprints.

Blueprints are the “Scripting Language” of the Engine:

Actor = GameObject (This is the simplest of Objects and can be used for almost everything)
Pawn = CharacterController

Coming from Unity think of Blueprints as GameObjects with scripts already attached:

  1. Default Parameters (defined in the C++ Class they are inherited from)
  2. Attached Components (Meshes, Sounds, Particles, Light… anything really)
  3. Two Distinct Scripting Graphs:
    3A. Construction Script, does what it says on the tin. You use it to initialize your Blueprint, like position it, spawn other blueprints from it, play a sound anything really. The Default State.
    3B. Event Graph which could be compared to MonoBehaviour and is entirely event driven. This is what happens to this Blueprint and it’s objects when stuff happens in the game. The reactive part if you will.

Once you understand these concepts you will see a whole world of possibilities open up and you’ll never want to go back to Unity, so be warned.

Thanks for the detailed response!

And you know what, I’m watching these Blueprint videos and… Yeah, I ain’t running back to Unity any time soon. This is pretty **** badass!

Quick question, I ran through the Blueprint videos and they are great and I have used them a fair amount now(also coming from Unity). What is best way to reuse the event graph portion of the Blueprint but with a different mesh?

Ie. I have some monsters of different types but I want them to behave the same way. I don’t think I would want to duplicate the BP because then if I changed the event graph on one monster it would not replicate to the others?

Thanks!

EDIT: Or would I create a base monster blueprint with a placeholder mesh, then create separate Blueprints for each type of monster inheriting from that one and just change out the mesh?

Start here.
Simplest object in unreal is UObject. AActor is default level placable object. Pawn if default object that Can be controlled by PlayerController object. I strongly recommend reading documentation. System is pretty rigid in it assumptions of how it should be used and structured. But once you understand pattern you will appreciate how it works because it makes managing big projects very easy.

As for coding in C++, it is not actually that hard. You must understand and learn to never use “new” keyword, as well as learn to use pointers. C++ in UE4 is very forgiving as there is automatic GC, though manual object destruction is sometimes preferred. There are some quirks mainly tons of macros, and unreal specific templates like TSubclassOf, but It is nothing that can’t be dealt with.

I personally didn’t found C++ to be particular issue, even though my previous exeperince was simple command line application, and web development in C#.
I was able to create basics of RPG game, to the point I can now implement game mechanics in blueprints while C++ solves and hide more complex tasks. Like tracing, particle spawning, timers, events, dameging actors, destroying objects (in memory).

@up best way is to encapsulate this functionality in C++, as function.

You can as well create function in blueprint. When you derive another blueprint from blueprint where function is implemented it will be available in child bp.

That seems like a good way to go.

Thanks, BP is so much more powerful than the visual scripting tool I am used to I did not even realize it had that option until I tried it literally seconds after hitting enter on my post…doh.

This definitely sounds like the right path. One of the example videos ( the tools walkthrough from GDC: http://youtu.be/FcxA_xYnHZ8?t=2m20s ) shows them with a ceiling lamp Blueprint that a boolean variable toggles to a floor lamp (Blueprint probably hides one mesh, unhides the other). That could be done for the “quick and dirty” solution for now until you need better separation between the two.

Building on what others are saying: Definitely start with Blueprint. It’s meant to be the non-programmers programming language, and it seems to do an outstanding job at that. I think having Blueprint and not requiring code/compiling makes UE4 easier than Unity for non-programmers to get a project going (never thought I’d say that). See the example project games done completely in Blueprint.

You don’t even need a Placeholder, see: Add InstancedStaticMeshComponent

All i can say sir is that it’s pretty easy to catch up with blueprints. Really easy to learn.

As others have said, this is the way to go I think! The great thing about inheritance is that you can build a base class containing multiple components and the scripting that ties them all together, then create derived blueprints that make variations (different health/mesh/color, add some new meshes etc).

Thank you, yes I just watched the Introduction to Programming tutorial and I think I am getting it now. Understanding that BP’s are actually real classes was the light bulb that turned on for me, and then it made sense. Making simple stub classes in c++ first, then extending a BP from them so I can do simple stuff in the BP and complex logic in the code class, brilliant workflow. (ok rotating a pizza isn’t complex but the concept is expressed well :slight_smile: )