Fireball

In this post I will explain how I made the Fireball BP class. This was the first spell that I made. I started with this one because it was the most simple. I thought that this would be a good way for me to learn how to do this sort of thing in unity and just get my bearings as far as coding with BluePrints goes. It took me a while to understand how to make it do what I wanted, but I finally figured it out and it helped me get a leg up on the other spells.
This is the full BP class. I will explain it further in the video.

The video, as promised.

My Medium for Casting Magic

So to make the magic happen, I used the Unreal Engine's programming software to create Blueprints for the spells. But that was my first hurdle that I had to solve. How was I going to implement casting different spells in a smooth way? By creating an input node that gets input from the controllers for the Vive, I was able to implement a system that would pass an integer to the BluePrint, then based off of what integer was passed to the system I would pick the spell to cast.

Here I have an image of all the nodes it took to create this BluePrint. I will talk through the logic for this BP step by step through this video.

My Job in This Project... WIZARD!

My job with this project was to be completely in charge of spells. So basically I got to let my imagination run free, and if I could figure out how to do it, I got to make my own magic! It was pretty cool because I was virtually creating magic through my code, and it felt like I was trying to discover this "magic" for myself as I worked out the logic of the code. Honestly one of the most fun programming problems that I have had to solve. I really enjoyed doing these.

Unfortunately, casting magic missiles in Unreal isn't as easy as rolling a D4. (Get it? DnD reference) Because I am a bit handicapped when it comes to the Unreal system, It took a bit of time to create the visual effects I wanted to have with the spells, thankfully Parker helped me figure some of it out. It also took me quite a while to figure out how to implement a lot of what I wanted to do.  But through tons of time, research, googling, time, trial and error, time, luck, teaching myself, and time I was able to figure out how to do everything that I set out to accomplish!




The list of spells that I wanted to (and did) accomplish plus more! Feels great to complete %110 percent. Originally I had only set out to finish the first 5, but I finished a little early on my stuff and was able to crank out the chain lightning spell in the last leg of the project. Out of all of these spells, the chain lightning is by far my favorite because of the logic that goes into implementing it and how unique it is.

1. Fireball (single target)
2. Large Explosion (AOE damage)
3. Curse (larger AOE damage)
4. Orbital Strike (homing magic missiles)
5. Summon Companion (Spawn friendly AI to be your body guard)
6. Chain Lightning(incrementally spawned AOE)

I will do a post for each of these spells, where I will explain the logic and the visual effects for each of them.

Sci-Fi V. Fantasy!!

Our pitch for our game project was an interesting take on something that our professor had said in class. We had been talking about different genres and how you can mix them well in games sometimes, and how you can also have a poor mix of game genres. We had been having a discussion about science fiction and fantasy and how it would be weird and not natural to mix the two together in a game. And so we decided that we would give it a go and see what we could accomplish!

Essential the plight of the user is this. You are a magician, and you and your magic buddies are in your magic castle that is sitting in the middle of this field that is on top of this magical floating rock that is surrounded by magical floating islands with hidden magical items on them. 

Then suddenly, a giant metallic spaceship comes out of jump-speed right next to your island. Other, smaller ships start flying out of the hanger of the mother ship and they start dropping robot units onto your island. You realize they are trying to make their way to your magical library all the way at the top of your tower (stereotypical, we know. But what did you expect? They're wizards!) to steal your magical books and claim some magical knowledge of their own. You must protect your books (Nerd) and save the rest of the universe by preventing these already powerful robots from claiming your magic and becoming unstoppable!

So we did sci-fi vs. fantasy! The ideas of the mechanics of the game is that you are a magic caster and you can cast spells by performing certain gestures with your motion controllers within a VR. The robots would attack at night and you could summon help with your magic to help you out, and use your over-powered magic skills to defend your goodies. During the day you would catch a breath while you tried to rebuild your defenses or go find some hidden powerful magic items to aid you during the next wave of attacks. If you survived 10 days and 10 nights of onslaught, you will have vanquished all of their robots, and their ship will self destruct because it is no longer manned and you get to keep all your magic! And make a ton of money off of selling the scrap metal as well! 

Oh, and I guess that means you win the game too. 

This is what we are shooting for with our game.

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

compared to this...

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.

'Twas the Night Before Finals

and all through the lab, 

not a person was sleeping, not even a tad.

The monitors were all humming on the desk here and there,

in hopes that Jeff Price would not soon be there.

The students were all sitting in front of their screens,

while visions of A's existed only in their dreams.

And Andony with his Monster, and I with my coffee,

tried to combat how the code made us groggy

and across the room, the artist were working

and to my surprise I saw Gabriel smirking

away to her moniter, I flew like a flash

looked over her shoulder, and then I gasped

The screen was showing the newly made scene

gave the lustre of reality, clear and pristine

when, what my HTC Vive should show,

but a beautiful castle, with clouds below!

With a bunch of robots, so lively and quick

I knew in a moment, I must give them a kick

more rapid than eagles, the waves just came

and I fought for my castle, and earned me a name:

Now Colby! Now Dustin!

Now Chris! Now Gabriel!

Now Parker! Now Evan!

Now Andony! Now Brett!

Through-out the whole night!

Until the sun calls!

We'll work away! Work away!

Work away all!

Level Editor Component Workflow (Tutorial #9)

In this last video, we highlighted everything that we have learned so far. Then we learned that you can make a class BP by creating all the assets within the scene view instead of the class BP view. You just add a new actor, add and set the assets as you want them. Script it how you want. Then you can select the whole thing and save it as a class BP. This converts it to a class BP and you can then take that class BP and create instances of it where ever you want in the scene and even in different scenes.

And that concludes the tutorials for the Unreal Engine "Introduction to Blueprints!"