Sunday, July 24, 2016
Saturday, July 23, 2016
Friday, July 22, 2016
Thursday, July 21, 2016
[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.
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.
Tuesday, July 19, 2016
[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!
Sunday, July 17, 2016
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
Saturday, July 16, 2016
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.
Friday, July 15, 2016
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.
Sunday, July 10, 2016
Sidebar
Search
-
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. ...
-
Today we were able to record our new set of audios for Project Einherjar which will be used for the game. Some of the voice recordings con...
-
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 adju...
-
One of the many features in Project Einherjar is the ability to enhance the Valkyrie's abilities. In-game, this is done through the skil...
-
Incendium is fast approaching and we're increasing our pacing to make sure that we are able to deliver the best version of Project: ...
-
You guys may be wondering what Game Engine are we using in developing Project Einherjar? Well GoaTo Interactive is proud to s...
-
Plans were cancelled today, but somehow, we did made significant progress in preparation for Incendium. The Orignal Plan We had a p...
-
The team successfully passed the screening last July 12, 2016. This only means one thing... We're going to Incendium! Follow us on ...
-
GoaTo Interactive is a 5-person team of Game Design and Development students from De La Salle-College of Saint Benilde. The team h...
-
As Incendium is fast approaching, this is the first time that GoaTo Interactive is releasing a video about these two systems. Ma...
Popular Posts
Categories
Pages
Search Our Website
-
▼
2016
(16)
-
▼
July
(15)
- Thanks for Playing Ragnarok Protocol!
- Incdendium Day 1
- Ragnarok Protocol
- [Engineering] Skill Tree Breakdown
- [Engineering and Design] BiFrost System and Tether...
- Road to Incendium: 5 Days Left
- [Engineering and Design] Bifrost System
- Road to Incendium: 6 Days Left
- Road to Incendium: 7 Days Left
- [Art] Einherjar - Dead Scientist
- [Design] The Brainstorming Process
- [Engineering] Project Einherjar's Game Engine
- [Sound] Audio Recording
- [Art] Valkyrie 3D Model
- About the Developers
-
▼
July
(15)