All in All

So overall, I probably spent about 4 to 6 hours a week on this for the 4 weeks we were in school for this project. And then the last week, because it was crunch time and we were putting the final touches on everything, I spent close to 10 hours a day on Friday, Saturday, and Sunday trying to finish everything up. and then Monday and Tuesday I spent a total of 36 hours in the lab, mostly trying to fix the build errors that we were getting. And then a few more hours Wednesday and Thursday. Overall, I spent about 90 hours in the lab working on this project.

An overview of what I accomplished:
We developed an idea and pitched it.
Pitch failed so we developed a new idea and pitched that one. It succeeded.
Me and Andony worked out how we would make the game system.
I did a tutorial on UE4 blueprints to give me a head start. ( And some extra credit too ;) )
I learned how to use the UE4 editor, and the differences between it and the Unity editor.
I learned how the mechanics of UE4 work and how they are different than Unity.
I taught myself a new programming language (C++.)
I taught myself a new programming style (Visually Based Programming as opposed to writing lines)
I taught myself how to use the VR handsets and how to reference them and use them in BP's.
I created and coded 6 original spells on my own.
I worked to fix the build error codes and try to figure something out for a long while.

So basically, the learning curve was high for me on this one. But I and my team feel that I have risen to the occasion and done an extraordinary job.

All said and done, I know that I have worked hard and diligently. I know and can honestly say that I have given it my very best, and given it my all. Even when I wanted to quit and this project tried me, I stayed in and kept going.

I am grateful for the opportunity to prove myself to my peers, my team-members, and to my professor Jeff. I know my work is good and I am proud of what I have accomplished.

Thank you Jeff for this opportunity, and for the valuable lessons that I have been taught through this class. There is no better method of teaching than an experiential teaching.  

(also, please don't forget about the extra credit. You asked me to remind you in the blog.)

The Lesson Learned

So, there was a HUGE lesson to be learned in all of this. It was a really painful lesson to learn to, seeing as we are still trying to fix it. But essentially we should learn to communicate better with our team members, always have back-ups, have some more back-ups for the back-ups just in case, and probably have back-ups for those as well. Also, dont wait until the day before to try to create an executable. I have learned that even if you don't get errors when you run the game, anything wrong will rear its head once you try to build, so go ahead and build every now and then just to make sure. It would also be a good way to keep track of progress and be something that you can give to your client so that they can have tangible evidence of the work you have done so far.

Chain Lightning

Finally, I have saved the best for last. This one is most definitely my favorite. I think that it is the most logically interesting to have implemented and I am honestly quite proud of myself for figuring this one out.

Here is the video!

Spawn Person

This one was fun to do just because you could spawn a person out of thin air simply by pressing a button. It was pretty simple to do just because the AI were also BP classes, so I could just call a spawn actor by class node. The interesting part about them was, the first time I did it I still had the scale of the transform on .2 for each of the dimensions. So when you spawned them there was a tiny little person running around trying to fight for you. It was pretty funny. But I fixed that and made them normal and that was the only real hiccup I had with that BP class.

Orbital Strike

Alright, so this one is pretty cool. I really enjoyed making this one because I basically had to make another spell for it. Essentially, you cast out your spell and where ever it hits, it calls down a strike from above. The spell it calls down though is what is cool because it chases the target down no matter where they go. So I made a tracking spell! And then I implemented it in this way, because this of course is way cool.

Here it is in video form! No point in wasting time reading, right?

Large AOE

This one was much the same as the last spell that I showed y'all. Once I had figured out the logic I decided to have a little fun with it and make it a much bigger effect that dealt more damage and looked like a different spell. This was the hard part. Instead of making a bigger explosion, I wanted to make it look like there was a curse that had been put on the Actors. This was mostly inspired by the dark souls curse effect. I made red particle effect that looked similar to the one that they use in Dark Souls and then put an added spin on it myself by adding a particle effect to each individual actor that looked like cursing words spinning around their dying bodies. Pretty cool, huh?

Here is a video where I explain it all and show it more in depth.

Small Area of Effect (AOE)

Now that I had created a single spell, I started getting the feel for this whole BP class thing and started having some fun with the spells I was making. So in this one I figured I would make a pretty decent AOE spell, just in case your aim is a little bad, or you wanted to hurt more than one enemy at a time. Just in case if I am leaving someone hanging, an area of effect smply means that instead of applying damage to just one target, it apply's damage to all targets within a certain volume.

Here is a video where I explain how I did this.

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!"

Adding Construction Script Customization (Tutorial #8)

In this tutorial we learned how to set the Construction script in a Blueprint. What this does is allows us to edit certain things about the Class Blueprint form the editor by setting the nodes to be publicly editable.

Using Inputs to Control a Class Blueprint (Tutorial #7)

In this tutorial, I learned how to add the functionality of allowing a player to press a button on the keyboard to execute a function, and toggling their ability to do that, as well as toggling other things upon entering and exiting the trigger.

Here is a screen shot of the new and improved Blueprint for toggling the light and the help text.

Adding Functionality to Our Class BP (Tutorial #6)

In this video, we added the same functionality to our class BP that we did to the light in the scene earlier. Except, now that we have done this within a class BP, the light source, model, and scripting can all be duplicated in the scene at will without having to redo everything.

Creating a Class Blueprint (Tutorial #3, #4, and #5)

A class Blueprint allows you to duplicate the same objects and functionality and scripts. This is is wonderful because you can create a Blueprint (BP) that does exactly what you want it to on whatever object it is that you want, and then you can click and drag that Class BP from your content browser into the scene and it is ready to go. Essentially it is the same thing as a prefab for Unity, except in UE4 it is much more clean cut and pipelined.

You can create a class BP in many ways, but the most common and straight forward one is to right click in you content browser and select the Blueprint Class option underneath "Create Basic Asset" as shown below.

From there you can make your class BP from within the class BP window. You can add assets to this window and design what game objects you want to make up your class BP. All you fave to do is click and drag the asset into the "Add Component" section, or click on "+ Add Component" and search for one. Here, we imported a lamp model, and a spotlight. we also added a collider, which will act as our trigger volume. This is not shown in the image below.

Delaying a Trigger (Tutorial #2)

The second video showed me how to create an event off of a trigger. A trigger is basically a volume, or a 3D shape, that will detect whenever another object in the scene is overlapping it. The events are called from a reference to that volume with the node names of "OnActorBeginOverlap" and "OnActorEndOverlap." Essentially it is the "OnTriggerEnter" and "OnTriggerExit" functions in Unity. We also learned how to create and use the functionality of a "Delay" node. Here is a image of the improved BluePrints.



Another cool funtionality we explored in this video was that multiple events can call the same function. Here you can see both "OnActorBeginOverlap" and "OnActorEndOverlap" are connected to the same function.

Learning to use the "Delay" node was helpful because it helped represent how Unreal Editor 4 (UE4) could call functions.  In UE3, you could call multiple actions (now known as functions) from the same event. The bad part about this was that there was no way to know what order those actions would happen in. It could activate the actions in a different order each time, and there was no way to control it either.

But in UE4, functions are all called in order from left to right. It is kind of like a daisy-chain way to go from one action to another. It is called Sequential Firing. So all Blueprints in UE4 have to go this way.

Here is a video that shows the result of the light being toggled on an overlap enter or exit, along with a delay before the function is called each time.

Let There Be Light! (Tutorial #1)

In this first tutorial we go over the basics of navigating the scene, adding objects to the scene, and manipulating the transform of objects within the scene. We also made our first Blueprint. The goal of the Blueprint is to simply turn on a light that has been added to the scene at run-time.

First we put a point light into the scene, and then we turn it off by making the lights "Visible" attribute set to false.

|

|

V

Pretty enlightening stuff.

After that, we created the Blueprint. by having the light selected, we were able to create a reference node to this specific point light. Afterwards, we were able to create a node to toggle the visibility of the light by clicking and dragging off of the reference to the light. The advantage to creating a node this way is that you are only able to create nodes that are legally allowed to execute off of the node it dragged it from. Finally we connected the nodes to toggle the light with the node that executes at the beginning of run-time called "Event BeginPlay."

Here is the Blueprint.




And here is a video of it working!

Learning Something New

Howdy guys,

So I am completely new to the Unreal game engine, I have never used it to program or develop scripts before. The unique thing about unreal is that instead of using typed scripts for programming the game, it uses a mechanic called "Blueprints." Blueprints are a visual based scripting system. They look something like this.



So since I am completely new to this software, game engine, and scripting mechanic, I am going to be doing some basic tutorials just to help me get a hold of the wheel. This next section of post is going to be the highlights from my tutorials so that y'all can see the journey I will make with Unreal. Hopefully my progress will be at-least as successful as a baby going from "Baby's first time sitting up" to "Baby's first steps." Who know's maybe I'll even get to run some day.

EDIT: The Tutorials I am going to be following along are provided by the official Unreal Youtube channel. The link for the first lesson I am doing is below.

https://www.youtube.com/watch?v=EFXMW_UEDco&list=PLZlv_N0_O1gY35ezlSQn1sWOGfh4C7ewO

Explaining the Device Operator

In this video, I explain how the player is able to interact with any of the objects in the scene that have the ability to be interacted with. This is done using a script with an "Operate" function.

In short, when the player clicks the primary mouse button, a raycast is cast from the center of the screen. If the raycast hits a collider, it creates a reference to that objects transform. it then sends a message to the script attached to the transform with the name of a funtion. In this case its "Operate". When this happens, it executes the function and this is how we interact with objects!

Explaining the Candle Game

In this video, I explain how the candle game manager listens and detects once the puzzle is complete, and how the other scripts of the game add the functionality for it. This puzzle gives you 8 candles, one of which is already lit. The goal of the puzzle is to light all of the candles using the one that you were given. Once all candles are lit, the puzzle is complete.

All in all, the manager listens to each of the wicks for each individual candle and determines if it is lit. If all wicks are lit, it registers that the puzzle is complete. You can light a candle with another one if it is already lit. This is done through detecting collisions and toggling the flame/light particle effect from inactive to active.

Explaining the Skull Game

In this video I explain the logic and code for the skull game manager, and also the scripts that give the puzzle its functionality. This puzzle gives you 4 skulls, and each have a unique symbol painted on them.

Summed up, the manager listens to a script on a trigger collider. each trigger collider represents a correct location for a specific skull to be placed. Each skull has a unique ID within the code, and each trigger is looking for a specific ID. Once a skull with the correct ID sits within each of the corresponding triggers, the skull game manager registers as being complete.

Explaining the Floor Game

In this video, I explain the floor game manager, and the other scripts that add the functionality to this puzzle.

In short, the manager script listens to a script that is attached to each of the floor buttons. Once the floor buttons are all the correct color, the game manage will register that this puzzle has been solved.

General Game Architecture

In this video I explain the basic architecture of the game and how each of the different puzzles is managed in the big picture.

A Late Start

Howdy!

I meant to be posting my work to blogger as I went throughout the semester, so I am going to do so now. I am going to separate the content of this blog basically into two sections, one for each of the projects that I am doing. For the first project, we were supposed to virtually recreate an Italian chapel using Unity. In the second project we are supposed to create a point based game, with a central point that you can see from anywhere on the map.

My part in these project is to design the architecture of the code and to write it. Basically, I make the actually game part of the projects happen, using the models, materials and other assets that the art students made for the project. I will mostly just be posting the scripts that I write, and some videos that will show what they do and how.

That's all for this post, until next time!