@@building_better_worlds Today I will post second video about combat locomotion with motion matching. Then I’ll return to melee AI. But I’ll get back to motion matching again to create parkour system like one in last Assassin’s Creed games. I’m trying to find animation that I will be allowed to share, but there is not much of them.
If making a new project. it is good idea to make 2 child blueprints of the CBP. NPCBASECharacter and PlayerBASECharacter. Add common functionalities in NPC/Player in parent blueprint(CBP) and player specific and NPC specific functionality to their each BASE. Then when creating NPC/AI characters, make them children of NPCBASECharacter, so that they all use shared main functionality from CBP (most animations), and NPC/AI specific functions from NPCBASECharacter, and you can add additional character specific code for their own BP. Also by having PlayerBASE, you can create different child blueprints, for 3rd person, First person or VR for example, as long and they all use PlayerBASECharacter for locomotion and basic player functionality. For example you can have PlayerVR, which is child of PlayerBASECharacter, which inherits all animations from normal 3rd person (or first person, just by changing camera location in 3rd person), but you can override hand animations with VR in child blueprint, and you have VR character with fully working leg animations.... Anyways... the point is that by using Inheritance and separating player/npc codes to different BASE child blueprints, you can better organize your code and have main functions directly inherited from parents. This helps reusability and makes it easier to scale up. It also keeps your character blueprints mostly clean, as the main code is done in parents. This way you can for example add a lot of NPC characters and they already have all NPC functionality automatically from the parents. This "functionality" means also parent BP variables, functions, gameplay tags etc, which are also inherited(but all variables still have character specific values). For some of you this might be obvious, but I just thought I put this here, because after learning this, it was much easier for me to create well organized code and character structure for any game.
@@KenlieroGames Hi. Thank you for this great comment! That’s something that I have already setup. Especially on NPC/AI characters. You can find more about character inheritance in my project here ua-cam.com/video/INyOqpQ6ZFk/v-deo.html&feature=shared. For player characters I’ll probably create specializations of current player blueprint.
Really glad you'll be covering motion matching on this series!
@@building_better_worlds Today I will post second video about combat locomotion with motion matching. Then I’ll return to melee AI. But I’ll get back to motion matching again to create parkour system like one in last Assassin’s Creed games. I’m trying to find animation that I will be allowed to share, but there is not much of them.
You are just awesome! Finally starting to enjoy game development again.
@@JeebZ-3D Thank you!
Just following your tutorials and really liking it, thank you for sharing your knowledge!!!
Thank you.
If making a new project. it is good idea to make 2 child blueprints of the CBP. NPCBASECharacter and PlayerBASECharacter. Add common functionalities in NPC/Player in parent blueprint(CBP) and player specific and NPC specific functionality to their each BASE. Then when creating NPC/AI characters, make them children of NPCBASECharacter, so that they all use shared main functionality from CBP (most animations), and NPC/AI specific functions from NPCBASECharacter, and you can add additional character specific code for their own BP. Also by having PlayerBASE, you can create different child blueprints, for 3rd person, First person or VR for example, as long and they all use PlayerBASECharacter for locomotion and basic player functionality. For example you can have PlayerVR, which is child of PlayerBASECharacter, which inherits all animations from normal 3rd person (or first person, just by changing camera location in 3rd person), but you can override hand animations with VR in child blueprint, and you have VR character with fully working leg animations.... Anyways... the point is that by using Inheritance and separating player/npc codes to different BASE child blueprints, you can better organize your code and have main functions directly inherited from parents. This helps reusability and makes it easier to scale up. It also keeps your character blueprints mostly clean, as the main code is done in parents. This way you can for example add a lot of NPC characters and they already have all NPC functionality automatically from the parents. This "functionality" means also parent BP variables, functions, gameplay tags etc, which are also inherited(but all variables still have character specific values). For some of you this might be obvious, but I just thought I put this here, because after learning this, it was much easier for me to create well organized code and character structure for any game.
@@KenlieroGames Hi. Thank you for this great comment! That’s something that I have already setup. Especially on NPC/AI characters. You can find more about character inheritance in my project here ua-cam.com/video/INyOqpQ6ZFk/v-deo.html&feature=shared. For player characters I’ll probably create specializations of current player blueprint.