Download Ragnarok Protocol

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

***Ranarok Protocol Download***

#GameDevPH #UE4 #GoaToInteractive

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 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. 

[Engineering] Project Einherjar's Game Engine

     

     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.

Thanks for your time guys! We will be posting more updates soon....