October 2018 Week #4
This week we managed to have a lot of sweet progress.
This now includes all the humanoid animations and makes sure that all animations can transition to the correct ones efficiently. After this (and making sure everything works), I made a script to control these transitions, and to determine what animation to play. What animation is being played is determined by three string values, act1, act2 and act3. These 'acts' work in synergy to determine the correct animation. For example, if act1 is 'walk', act2 is 'crouch' and act3 is null, the 'CrouchWalk' (walking while crouched) animation will be played. Also note that this script, the 'AnimController' is and will be the only script that has permission to access the animator, and to change around animations, the other scripts can only do so by accessing the AnimController.
I concluded this is gonna be a pretty decent environment to work in. Cool.
Next up, I created a script for taking in input, control the character and play the right animations. It is called the PlayerController, and it sits on the Player GameObject itself, like the animator and the AnimController. The PlayerController partners up with Unity's built-in CharacterController to move the player around, apply gravity, have collisions and move up-and-down slopes or stairs.
Making this script was super-hard, and I had to take care of some serious math to pull this off in an efficient and optimal manner.
Graphics is something many people believe Unity sucks at, and even I kinda dislike the default Unity aesthetics. So I went ahead and made a colour corrector powered by the Unity Post-Processing Stack. I also did some Thanyok stuff and slapped it over the default everything, and made a custom-written pipeline plus some extra effects.
This is what everything looked like before:
And this is how everything looks like now, after the post-processing and the pipelines and Thanyok and all:
Visuals aside, I then continued making the PlayerController for the player, and that also in a way that is easy-to-manage and easy-to-override. In its current stage, the Unity inspector of the player looks something like this:
And, thank gods, it worked out fine. The basic movement functionality is all in. The player can now walk, run and jump. A CameraTPP script was also created for the camera so that it works with the PlayerController and the player can look around (i.e., the camera orbits around the player). If the player is idle, moving the camera won't affect the player; but as soon as you start moving the player will take of in the direction towards which the camera was facing. If you move the camera around while the player is moving, the player will automatically also rotate in the camera's direction on its Y. In other words, the camera is, at its core, just like the ones you see in modern third person games. It just needs a ton of work.
The following internal playtest recording demonstrates the PlayerController and the CameraTPP:
I am also working on a custom-written blueprint system in Blender so that it'll take less time to make certain types of models in Blender afterwards. That's tough.
That was it for this week. Now we're gonna test out that new blueprint thingy in Blender and finish up the PlayerController with all the actions we have made the animations for (crouching, going prone, aiming, etc.). If we get time, we'll also do the ragdoll stuff this week only... otherwise, we'll look into it next week. Anyways, thanks for your time and until next week, cheers.
ADITYA CHANDRA (Lead Developer)
I was able to pull off some awesome stuff too. For starters, the animation web for the humanoid character's animator was extended (and thus now it's even more scary):
This now includes all the humanoid animations and makes sure that all animations can transition to the correct ones efficiently. After this (and making sure everything works), I made a script to control these transitions, and to determine what animation to play. What animation is being played is determined by three string values, act1, act2 and act3. These 'acts' work in synergy to determine the correct animation. For example, if act1 is 'walk', act2 is 'crouch' and act3 is null, the 'CrouchWalk' (walking while crouched) animation will be played. Also note that this script, the 'AnimController' is and will be the only script that has permission to access the animator, and to change around animations, the other scripts can only do so by accessing the AnimController.
I concluded this is gonna be a pretty decent environment to work in. Cool.
Next up, I created a script for taking in input, control the character and play the right animations. It is called the PlayerController, and it sits on the Player GameObject itself, like the animator and the AnimController. The PlayerController partners up with Unity's built-in CharacterController to move the player around, apply gravity, have collisions and move up-and-down slopes or stairs.
Making this script was super-hard, and I had to take care of some serious math to pull this off in an efficient and optimal manner.
Graphics is something many people believe Unity sucks at, and even I kinda dislike the default Unity aesthetics. So I went ahead and made a colour corrector powered by the Unity Post-Processing Stack. I also did some Thanyok stuff and slapped it over the default everything, and made a custom-written pipeline plus some extra effects.
This is what everything looked like before:
And this is how everything looks like now, after the post-processing and the pipelines and Thanyok and all:
Visuals aside, I then continued making the PlayerController for the player, and that also in a way that is easy-to-manage and easy-to-override. In its current stage, the Unity inspector of the player looks something like this:
And, thank gods, it worked out fine. The basic movement functionality is all in. The player can now walk, run and jump. A CameraTPP script was also created for the camera so that it works with the PlayerController and the player can look around (i.e., the camera orbits around the player). If the player is idle, moving the camera won't affect the player; but as soon as you start moving the player will take of in the direction towards which the camera was facing. If you move the camera around while the player is moving, the player will automatically also rotate in the camera's direction on its Y. In other words, the camera is, at its core, just like the ones you see in modern third person games. It just needs a ton of work.
The following internal playtest recording demonstrates the PlayerController and the CameraTPP:
DIWANGSHU KAKOTY (3D Artist)
Let's look at the models now, shall we? My week-long holiday period gave me a lot of time for gamedev stuff. I made some awesome 3D assets for us to use. I made a D.M.R. (based on the Russian Dragunov (S.V.D.) rifle), a cargo truck, an awesome Molotov cocktail (with a cool attached cloth component) and a sticky bomb among others. Here are some of 'em:
I am also working on a custom-written blueprint system in Blender so that it'll take less time to make certain types of models in Blender afterwards. That's tough.
That was it for this week. Now we're gonna test out that new blueprint thingy in Blender and finish up the PlayerController with all the actions we have made the animations for (crouching, going prone, aiming, etc.). If we get time, we'll also do the ragdoll stuff this week only... otherwise, we'll look into it next week. Anyways, thanks for your time and until next week, cheers.
Comments
Post a Comment