[Academic] CAPSTN1 - Ragnarok Protocol | Alson Entuna

Ragnarok Protocol is our game for CAPSTN1 which we've been developing for almost 3 months now and it was really a fruitful experience working with this project. This journey has been a very challenging one for me and the team. I'm so proud of what my team has accomplished and I'm eager to see them further improve in the next CAPSTN!

Cudos GoaTo Interactive! Also thank we would like to say thank you to our adviser Sir David Ramos for all the advises and the coaching he did during the development of our game. Thank you so much Sir on behalf of GoaTo Interactive! We couldn't have done this without your help.

About Ragnarok Protocol

“In a society where man can no longer exist without the aid of machines, there is an extreme need for a materials and tools to maintain this kind of technologies. As one of the Valkyries of the Valhalla Research Company, you are tasked to find these materials and tools, and on the way, find worthy humans to be preserved and later turned into an Einherjar- a Cyborg Warrior. Battle against machines and cyborgs and exploit their weak points by uncovering them.”

Ragnarok Protocol is an Action Role-Playing Third Person Shooter game with elements of Platforming. You, as the player, will control the Valkyrie. She's a cyborg equipped with a gun that can contain different types of bullets which are useful in most situations.

Cinematic Trailer:

Ragnarok Protocol - A Thesis Project from John Alson Hechanova Entuna on Vimeo.

The game is being developed for Windows using Unreal Engine 4. The recommended system requirement to play the game is:

	*Minimum System Requirements*	*Recommended System Requirements*
OS	Windows 7 32bit or 64 bit	Windows 8.1/10 32bit or 64 bit
Graphics	Intel HD Graphics 4000 series with 2GB Memory	NVIDIA GTX 650TI and above or any RADEON equivalent with 2GB Memory
CPU	Intel Core 2 Duo or any AMD equivalent	Intel Core i7 – 3770K or any AMD equivalent
Memory	4 GB RAM	8 GB RAM
Storage	10 GB	15 GB

Roles Played in Production

1. Tech Lead
2. Programmer
3. Co-Producer
4. Character Artist - Modeler, Rigger, Skinner
5. Online Manager (Website)
6. Technical Artist

Tools Used:

Unreal Engine 4.11.2
Autodesk Maya 2016
ZBrush 4R7
Visual Studio 2015
VS Online Team Foundation

Systems Developed:

1. Character Control System
2. Save and Load System - Checkpoint, Save Point
3. Mesh Shaders - Environment, Character, Props, Enemies, Adaptive Shaders
4. BiFrost System
5. Tether System
6. Cinematics
7. Bullet and Einherjar Unlocker
8. Player HUD
9. Einherjar Website
10. Persistent Data (Game Instances)
11. Audio Engineer (Engine Integration)

Awards and Nominations -GameOn! Competition by the Game Developer's Association of the Philippines (GDAP)

Best in Game Play - GameOn! 2016

1. Best in Game Art - Nominated
2. Game of the Year - Nominated

Read Benilde's Story here: Benilde ICT Post
Read Manila Standard's Article here: DOST Holds Game Design Oscars' Night

GoaTo Interactive

1. Paul Aguilar - Designer, Co-Producer, Project Lead
2. Alexandra Arcega - Environment Artist
3. Alson Entuna - Technical Lead, Programmer, Character Artist, Co-Producer
4. Josh Ignacio - Programmer
5. Jed Pascua - Art Lead, Environment Artist

Adviser: David Ramos

--------------------------------------------------------------------------------------------------------------------------

Voice Actors:

1. Melody Bertes - Valkyrie
2. Nickey Ronas - Odin

Here are some of the voice recordings that are in Ragnarok Protocol

--------------------------------------------------------------------------------------------------------------------------

You guys may be wondering what Game Engine are we using in developing Project Einherjar? Well GoaTo Interactive is proud to say that we are using the Unreal Engine 4 in developing our game. We'll be using version 4.11.2 for the development.

We've already been developing systems for the game inside the engine itself. It's pretty hard at first since we had to grasp the C++ interface of Unreal Engine and wire them in alongside Blueprints for more flexibility. Yes, our game is built under C++ but we're also using Blueprints for our Game Designer to prototype faster gameplay elements. Making systems for re-usability was tough since we had to learn different systems and implementations that Unreal has. Like say for example even though Unreal Engine is a Component Based Design Engine it's quite different from Unity.

Here's an example of what is the scripting environment of Unreal Engine 4

Whenever you create a script in UE4 you will be given an option on what type or parent class do you want your script to have. These parent classes or type perform and act differently but they still have similar scripting environments. Like say for example whenever you want to make "prefabs" like in Unity you may either want to choose an Actor rather than an Actor Component. These two are different from each other because on the way they are instantiated. Actors can be instantiated in a level in Unreal while on the other hand, Actor Components are like scripts in Unity wherein you could attach them to Actors to perform different tasks. If you want to make characters or AI, you may want to choose Pawn or Character as your parent class. I know it starts to get complicated but in short Pawns are objects that can be possessed by a controller. So basically if you want to create AIs you may want to use Pawn. Character is a Pawn but is usually used by players and is controllable by players. Here's something that will make your head dizzy,,, Pawns and Characters are Actors. They basically inherit from Actor. The way they differ from Actors is that they have these special components pre-built inside of them. Some of these are movement and navigation controllers which might come in pretty handy for the programmers to make simple behaviors to complex ones.

Here's a hierarchy of the objects in Unreal in their website. You may want to check them out here when you're already used to develop in Unity. Link Here.

Oh before I continue, whenever you make your project in UE4 with C++ you will need VS Community 2015 and the way UE4 compiles your code is pretty different compared to Unity. Why? Remember in Unity wherein whenever we save a script it will automatically compile right and apply changes to your game? Well that's different from Unreal. In Unreal you'll have to make a build out of your solution. It's pretty much old C++ way of making games wherein you have to build everything and do a lot of things before it actually applies to your game. Also, whenever you have to delete source code in your game you have to go to a lot of process. It's not like Unity wherein you just have to delete the script but rather you have to remove it from the actual solution then delete it from the source folder then recompile the solution for it to be applied. Yes, it requires a lot of process but you'll get used to it.

Every time you have new scripts added to your project, let's say your teammate just committed a new code in your repository, you'll have to generate new VS Projects since source control / git ignores any changes made in your .sln file so you'll have to regenerate these files again on your own.

Yeah, you'll get used to it guys.

Let's move one. So if your familiar with Unity's scripting environment in C# you'll pretty much be familiar a bit with Unreal because they have similar structures when it comes to code. So what do I mean by similar? Well remember void Start(), void Update(), void OnTriggerEnter(Collider other) in Unity? Yes, Unreal also has that in similar. Unreal uses BeginPlay(), Tick(float deltaTime), and OnActorBeginOverlap(). It's pretty much the standard that game engines have wherein you have initializers/constructors and per frame executions.

Here's a sample.

Unity

C++

Blueprints

I won't be tackling about how to program in Unreal but I'll just give a little bit of insights on what it is inside Unreal Engine's scripting environment. If I have time I may be posting some implementations that we have in Project Einherjar.

Unreal has static classes wherein you will directly have access to your Main Character, Camera, Game Controller, Game Modes, Game Instances, and many others. You could read more about these frameworks here. It's a deep concept but it might come in handy when you develop games. Oh just a fun fact about Unreal... You might be always encountering castings in your scripts because their prefab system is totally independent from each other. So like say you have a parent class called Fruit and you made a child class called Apple and Orange and you added different variables inside them. Apple and Orange are not the same when you want to access specific variables that only exists individually in these child classes (I hope you're familiar with OOP) but they're similar in terms of parent classes where they are typeof Fruit. Lol... I'm trying to explain it as easy as I can in words.. sorry for that...

Moving on...

What made me interested in Unreal is about their nested prefab system that I guess Unity is probably already been working on in their upcoming versions of Unity.

Their prefab system is totally different from Unity's. They have special editors for prefabs and it's hard at first to understand them. For short, they're treating each and every component as individual objects so every time you add a component in your Blueprint Class these components are treated as objects wherein you could also use them to do specific actions. If you look closer to the picture above you may notice that there's a separation between scene components and actor components. Scene components are components that you could also add to your Blueprint Class. Oh wait.. Blueprint Classes are like prefabs in Unreal. Sorry I forgot to mention that. Also if you look closer to the encircled ones, they're called child actors. This is the nested prefab that I was talking about. Nested prefabs, on my understanding, is a special way that let's you create or add prefabs inside prefabs itself without breaking the up another prefab itself. The orb and the sentry gun are different prefabs that we've added to this main prefab, the AI. Hmmm how could I make this simple... Basically think of this one... Whenever you create prefabs in Unity and want to combine them in other prefabs, you end up creating a new one right? Like whenever you combine prefabs in Unity you ended up breaking the connections/links to the prefabs. (Ok, I tried my best to simplify it.. Sorry...). In Unreal, child actors are separate entities that can act independently. This is why I found this system of Unreal interesting.

Also the last one I wanted to share to you guys is the UMG system that Unreal uses for their UI. UMG is Unreal Motion Graphics which is one of the UI systems that they have. Here in this system you'll have access to tools that let's you create UIs in Unreal. If you're familiar with Visual Basic, you would probably find it familiar because the interface is really similar.

The neat thing about UMG is that Unreal is treating it as a separate entity. Basically in the UMG Editor you have your own scripting environment wherein you could bind functionalities to the UI. It's really powerful and really is handy for programmers because it's totally a separate object and doesn't require any dependency.

You have your own SE here and it's similar to Blueprints as well. The only difference is that it only contains Construct and Tick. Of course you don't have any collision events in UIs right? lol...

Well that's pretty much all about it.. Developing in Unreal is really a wonderful experience and takes a lot of time to get used to. I'm not saying Unreal is better than Unity but we only decided to use Unreal because we wanted something new and to really test out what we learned for the past couple of years as Game Development students in Benilde. Unreal is really a powerful engine and as long as you supply great design and gameplay mechanics to your game, you would probably have a successful game.

--------------------------------------------------------------------------------------------------------------------------

Here's a little briefing about how I was able to implement some of the system in Project Einherjar

How did we pull off the Bifrost System?

Well this was actually hard at first since we have to think of a way to make the bridge adjust and update its rotation per frame because Matters can be either Rooted, Movable, or Body Parts. At first we decided that the bridge should spawn in between the two matters when they're tagged so we had to use the distance and midpoint formula.

So in the case of the Bifrost System, we have to find a way for the Bridge to spawn in between the two matters but... Due to constant feedback from our adviser and some other testers that were able to play the early builds of Project Einherjar, we decided to make an effect wherein the first tagged Matter will be the spawn point of the Bridge then will be making an effect where it will look like the bridge is going towards a point.

I can't fully remember what mathematical formula I used in this effect but it has to do something with the ration of the distance between these matters and calculating its target scale for the bridge, So this calculation is a per frame basis because as mentioned above we're not really sure what the Matter Type is so we have to compute the target scale of the bridge every frame.

Before we even get to the spawning part, the Bifrost system works when you have the Bifrost Bullet. This bullet can be found in a specified location in the level. You can switch between different bullets in the game. So with the use of the Bifrost bullet of course you'll also be able to use the BiFrost System/Ability.

How this works is simple... When you set the current bullet to the Bifrost Bullet, you'll be able to detect Matters which highlights the object whenever you aim your cross-hair to it. It will have an outline effect which is pretty much similar to the toon shader concept in Unity.

It's a shader that we made that activates whenever the object detects that the player is aiming towards it. When the player shoots a bullet to the matter object, it will be releasing a lock on mesh that will indicate that the matter is already tagged.

The Bifrost requires at least 1 pair of matter being connected and whenever our system detects that a new pair has been generated then it will spawn another bridge between these pair. So, Yes you can spawn infinite number of Bifrost bridges as long as your Energy can sustain the cost per Bifrost Bullet. Yes don't worry we have upgrade systems :)

The most challenging part of doing the multiple spawning of bridges every new pair generated was how to keep track of the LAST object tagged because this last object will be the first object to be used in the succeeding bridges. So if you're familiar with Linked Lists then this will be our solution.

Here's a video about linked lists if you're interested

So the main concept of this algorithm is that we have a pointer that points to another element in the list and points to another element whenever the bridge successfully spawns itself. Also I've added a fail safe system that whenever the Matters are not in the same area the pointer will reset itself to the previous pointed element in the array of Matters. There's also limit wherein when the Bifrost Bridge stays too long it will automatically despawn itself and fades its shader and removes the capacity of the Valkyrie to walk through it. In this implementation, we're just reversing the process of the computation of the target scale and position of the Bridge and finally inverse all of the data to get this effect wherein the last tagged object will be the first object which the bridge will despawn itself to.

I can't post that much with the implementation of the BiFrost system but this is mainly how the design of the current system is. Stay tuned for more design and engineering posts from our team!