Tuesday, December 13, 2016

Tackling the Beast That was Unreal Engine 4

Sorry for not posting for a while. I have been spending my time just trying to familiarize myself with the Unreal system and learning a lot of the functionalities of the tools available to me through Unreal.

First off, I had to familiarize myself with the Unreal editor engine in general. Before this project, the only thing that I really knew how to use was Unity. Unity is another game engine that allows you to edit and create levels and functionality. Basically it is a great tool to make video games, just like Unreal. But the fun part is that Unreal and Unity are about as similar as apples and oranges. Sure! They are both fruit (or game engines,) but the way you go about editing your level and the components of that level are vastly different. In Unity you have prefabs. In Unreal you have BluePrint Classes. Both are nice for different reason, and essentially the same tool, but the way you use them is very different. After I familiarized myself with creating BluePrints thanks to the UE4 official tutorials that I posted earlier in my blog, I started familiarizing myself with the scene and the other components that make up a scene in a game. In Unity, everything is a GameObject. If it is in the scene, then it is simply a GameObject. now, you could attach different components to it, like a sphere collider and a sphere mesh. And then suddenly instead of a empty game component (which only holds its world location within a transform) you know have a sphere that can collide with other meshes and can also be seen. Essentially with Unity, everything in the scene is at its very core a GameObject with different components added to it that let it be and let it do different things. And if you wanted to make it do something, like spawn a monkey if a trigger was entered, you would simply add as script to that trigger and access it OnCollisionEnter function. Having come from that background, it made Unreal a little difficult to grasp at first. For starters, everything is not essentially the same thing at its core. There is no base class like GameObject that you just add components to in order to build a specific kind of GameObject. You do have Actors however, which are their own thing. but they are not the same thing as Triggers, Lights, or other components. They are each their own thing and own class atomically. From a coding standpoint, this changes the game quite a bit. Finally, the last difference and probably the most significant is how scripting (coding) works in these engines. Within Unity, you can tackle your problems with C# or JavaScript. Most use C# because it is a hard-typed Object Oriented language, which is ideal for game programming. These are both done by writing your code line by line and getting references to different GameObjects within the scene. The beautiful thing about these scripts is that once you have written it, you can just drag it onto any GameObject and it will have the same functionality there as it does on the original GameObject. Unreal is... different. Unreal uses visually based programming using nodes. And instead of having a script as an individual component that you can add to GameObjects here and there as you please, they are tied to their BluePrint class, which means you have to include any Actors or other components that you want to be in the script into the BluePrint class as well. If you want to copy that funtionality, you have to copy the nodes from within the BluePrint, and then paste them in to your new BluePrint, and then re-attach the references to the components within the new BP.



This

Image result for UE4 nodes

compared to this...

Image result for C# Unity

Very very different.


More on the coding...
I learned how to make BluePrint classes, how to trigger events like BeginPlay, Hit, OnBeginOverlap, and OnEndOverlap.I learned that Unreal has a built in system for applying damage to objects and actors. I learned how to shoot fireballs by adding impulses, making the actor (which was a custom made BP class) move forward, spawning a particle effect to make a trail, ending the spell and emitting particle effects to cause an explosion, learning how to create and edit particle effects so that I could represent the different spells that I made. I taught myself about a bunch of the different functionalities, like how to access the objects that are being overlapped by a trigger and how to target them. Basically, the only thing that transfers from and programming that I am familiar with to Unreal is the logic part of things. How you access that logic, and make things happen based on that logic is all called different things than I knew, and is all implemented in different ways than I am familiar with. So I was able to teach myself how to first use the Unreal Editor and its tools that it offers me. And then I learned a completely new programming language and was able to do some pretty cool stuff in it.

But enough talking about it! I'll show you what I was able to accomplish after getting this far in the posts to come. Time to see what our project was and how we did it.

No comments:

Post a Comment