Download Ragnarok Protocol

Ragnarok Protocol is now available for download! Thanks for everyone who supported our game.

***Ranarok Protocol Download***

#GameDevPH #UE4 #GoaToInteractive

Thanks for Playing Ragnarok Protocol!

On behalf of GoaTo Interactive, we would like to thank everyone who supported and played Ragnarok Protocol during and before Incendium!  This has been a wonderful journey for the team.  Thank you everyone!

Incdendium Day 1

GoaTo Interactive would like to thank all of those who got the chance to play the game and give us feedback on how to improve our game.

Sorry for the low quality but here are some of the pictures that we were able to get during our first day!

Ragnarok Protocol

Catch Ragnarok Protocol on its last day tomorrow at the ARG Theatre, De La Salle - College of Saint Benilde Taft Campus!  We have freebies and goodies to give out!  See you there guys!

[Engineering] Skill Tree Breakdown

One of the many features in Project Einherjar is the ability to enhance the Valkyrie's abilities. In-game, this is done through the skill tree system. A staple in many RPGs skill trees are complex systems usually involving multiple branches in which the player can customize their character.

Being an RPG enthusiast myself, it was pretty fun programming this system. Here I will be discussing a bit of a breakdown on how our skill tree works.

One of the main things that are always found in skill trees are "leaves". Leaves are the individual skills themselves, which more often than not have a prerequisite to be unlocked. This is the first part of the skill tree system we made. The SkillLeaf class we made contained data like its name, the required points to purchase said skill and a list of prerequisites needed in order to be even able to purchase it in the first place. It also contained functions such as Unlock, which is implemented differently based on classes derived from this class. Each leaf also has references to its "parent" leaf and "child" leaves. Parent referring to prerequisite leaves, child referring to leaves that require it to be used.

The next part of a skill tree is the branch. Branches are what split the leaves inside the tree. One branch could all relate to a specific aspect of the character. Branches, at the start, actually only contain one leaf called the root. Root leaves are leaves that have no parent thus starting immediately available to the player for purchase. The branch is responsible for generating the rest of the leaves using only the root leaf. Each time the branch generates a new leaf, it checks if the newly loaded one has a child leaf and continues until a leaf loaded has none. We did this way so that we could easily rearrange the order of leaves on a branch without messing with a blueprint too much. Designers could simply change what child leaf a skill has to rearrange the branch. This system also supports mutli prerequisites but was unused in-game.

The last part is the actual tree itself. The tree is composed of branches and contains data such as current skill points. Perhaps the last complex part of the actual tree as it mostly served as a way to simply have a container for multiple branches.

To those curious, this was mostly done in C++. The skill leaf class was made in C++ but each skill leaf in game was implemented using blueprints.

[Engineering and Design] BiFrost System and Tether System Video Demo

As Incendium is fast approaching, this is the first time that GoaTo Interactive is releasing a video about these two systems.  

Making these systems really required great planning and thinking of what will be better for these two of the many features that Project Einherjar has. We did a lot of revisions for the past few months and currently we have this outputs based from many feedbacks and suggestions that our play testers and thesis adviser has given us.

Catch Project Einherjar at Incendium this coming July 22-23 and have a chance to experience the game.  Thank you for the support guys!

Road to Incendium: 5 Days Left

Incendium is fast approaching and we're increasing our pacing to make sure that we are able to deliver the best version of Project: Valkyrie!

Game Information

Throughout this week, we will be releasing more information about the game. This will be coming from all sides of the production. Today, one of our engineers released a post regarding one of the main features of the game, the Bifrost System. 

See more: http://www.projecteinherjar.xyz/2016/07/engineering-and-design-bifrost-system.html

Constant Update

The weekend is not a reason to stop improving the game! Everyone in the team are working full time to further polish the content of the game.

Few more days and you will be able to test out the game. Make sure to stay tuned and be there during Incendium!

[Engineering and Design] Bifrost System

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!

Hope to see you this week at Incendium!

Road to Incendium: 6 Days Left

Plans were cancelled today, but somehow, we did made significant progress in preparation for Incendium.

The Orignal Plan

We had a plan of staying at one of our developer's house to work together in one roof. However, due to some circumstances, we weren't all able to make it; leading to the decision to just cancel the plan. It was decided that all of us would just communicate online constantly and see to it that we complete our goals for today.

Marketing Collaterals

The production of the collaterals of Project: Einherjar starts today. The ideas for the materials that we will be bring on Incendium continues to overflow. We have to make sure that we choose the right collaterals that will maximize the promotion of the game. In the next few days, we will officially release the Title of the game along with the images of the collaterals that we have prepared for everyone in Incendium. Stay tuned to see those!

Major Updates

Further development on our Boss enemy also happened today. A new animation shall be ready before the day ends and a better behavior shall be seen in the next few days. Also, other features such as the Bifrost and Tether were polished today.

So far, the Team is on track with their goals before Incendium. Stay tuned to see if more updates regarding our progress in the last few days before the release of Project: Einherjar.

Road to Incendium: 7 Days Left

The team successfully passed the screening last July 12, 2016. This only means one thing... We're going to Incendium! Follow us on this mini blog series to know more about the steps that we will be taking as we go on the last crucial days before we release the game.

Incendium

So what is exactly is Incendium? It is an expo composed of student projects from the Game Design and Development Program of De La Salle-College of Saint Benilde. A wide range of projects from the Basic Programming Series up to the Capstone entries are seen here.

Screening Result

Three days ago, we had a screening for Project: Einherjar. Everyone in the team was anxious about the result of the screening. As we wait while our game was being screened, everyone was silent. It felt like it was the longest waiting time we had in our life. But as we received our result, we all lightened up. We still have alot to fix, but we made it!

Last Crucial Days

Yesterday, the team had a meeting on how we could address every feedback that we had from the panelists, our adviser, and those who play tested our game. We also discussed which collateral will we offer on Incendium.

7 Days Before Incendium

Our goal today is to fix every bug that was encountered by those who play tested our game. Also, we continue to modify the level according to the suggestions made by the panelists and our adviser. 

[Art] Einherjar - Dead Scientist

Description:


Artist:

1. John Alson Entuna - Sculptor, Modeler, Rigger, Skinner

Tools Used:

1. ZBrush 4R7
2. Autodesk Maya 2016


Art Pegs:

Screenshots: