Art:
Yo! The name’s Christian and I’m here to bring the report for this blog update! For this run around, the team agreed that we need to figure out what we need to be pushing so we could have a demo of sorts in the coming weeks. After piling up what exactly we needed, one of the things included from the art department was environmental assets, or just quick figures that would make our land less bare other than the trees that we had from the prototype days. It didn’t matter if they were low poly, so we took that rather literally. Some of the objects that were included on the list and are so far completed are: crates, benches, small buildings, wooden fences and their respective gating, and tree stumps for a forest flair. Though the objects that were included on the list are in respect to the village, the hub world for Myco and his companions. My part of this came in the form of creating the fencing and the tree stump, without any sort of texture or flair so it would make things easier on our programmers to just drag and drop these assets within the project. As for the other objects mentioned, the plan there is to ensure the work is split up between myself, Tom, and Cris, so that these assets are used to make the town look way livelier than it is.
Furthermore, I also took in the respect of creating a grass shader in Unity. I mainly did this with several planes that were created in between making the stump and fencing but making the shader for it was rather—interesting. Firstly, I had to make the actual graphic for the planes and enable transparency on Unity so that it could read it properly. Secondly, I had to only ensure the top portion was moving so figuring out that via the vertex shader was quite the learning experience! With this at the programmer’s disposal, I also ensured that if they had to change the wind of the grass, it would be easy for them to do so, that way, they wouldn’t be locked to one direction. Plus, with the wind direction easily adjustable, this could prove for some more realistic effects so all in all I’m definitely proud of what I achieved! The results of this are shown in the gif provided below.
Overall, our main focus is to have some base material to work with. We do this just to make sure everything is going all according to plan in terms of development before going down the line to increase the quality, make it more appealing, etc. Appeals are not our main priority for the time being, as all we would like to focus on is making the game playable, readable to understand, and make it feel as though life is flowing through. We can figure out how to pretty things up down the production line but the most important thing is getting the level ideas down.
Update by: Christian Morris
For progress on our enemy models, the rotted mushroom enemy is now fully UV mapped and rigged. During this milestone this mesh was updated with a rig and animation constraints. This model is ready to be brought into Unity and set up with an animation for attacks once we figure out how to get animations to play. With the process I have set up with our models, I’ll be having our models set up for later parts of the production pipeline next semester such as texturing.
Update by: Cris Derrow
Programming:
On the programming side of things, the bulk of the work we have completed since our last blog update has centered around the combat system. This included making updates to the File I/O system, some new additions to the static game data, a series of damage algorithms, and the logic behind the conditions in the gambit system.
In order to keep our character data stateless, I had to find a way to pre-boot the ability scriptable objects onto the PlayerCharacter objects when the game loads. By pulling from the save game .json file, we can get the names of the abilities that a character has learned. In this instance, Myco knows the ability Biolumen.
So in our startup script, it crawls through .json and creates the PlayerCharacter objects into the StaticGameData and adds the relevant AbilityScriptableObjects onto the Abilities property of each PlayerCharacter.
Now that we have our save data in our static runtime data to be used anywhere.
Speaking of the StaticGameData, we now have a few additional properties in place to store data such as the Active party members and a set of enemies to be used in combat when a battle is triggered. This is our way of persisting our data between scenes.
In the actual CombatManager script, we now have a huge chunk of specific implementation for different damage types. A rawDamage variable is calculated depending on the ability used and the offensive stats of the actor, it then is reduced by varying amounts based on the damage type and the defensive stats of the target. All of the various ratios used for the different damage types and mitigations are tuneable individually. For the final milestone this semester, we won’t be bothering with actually making these damage types have their own identities quite yet. Here’s a sample of the mitigation calculations for a single damage type:
Finally we went through the conditions logic for the enemy “gambit” system. This gambit system defines a set of actions and conditions that the code will check through to determine an enemy's action on a given turn of combat. The current conditions it can check against include a random % chance, an allied enemy, player character, or self health being above or below a certain threshold, the turn count of the specific instance of combat, and a default fallback action in case no other conditions are met. This system is modular and we can add more conditions if we find that these options don’t provide for interesting enough enemy AI.
Update by: Trevor Wamhoff