I decided to give myself a break from web-based development/programming to get back to game programming. I use to provide web-development services under subcontracting but I got out of it roughly four years ago due to my lack of passion for web-development. The passion was slowly destroyed by my passion to make and program games.
Beretta 92FS - Facing the sky for better lighting in this dark test map
It’s time to go back to the weapons and tackle a problem I honestly didn’t predict like I should have but I was so concentrated in all the mechanics before going right into producing another promotional video/demo that I simply didn’t have the time to predict this potential problem. Multiple weapon types or styles.
Functionality is extremely similar between all weapons, it’s only the small details that have to change, such as a semi-auto fire mode only for pistols instead of fully automatic like a rifle. However, there is one huge difference between even a pistol and a rifle. The arms, hands, and their positioning. Drastic differences. For first person view this isn’t much of a problem since each weapon can define it’s own animation sets but third person is a different story. You don’t change the player just because they changed a weapon.
The way I’m going about this so far is just by swapping out the Pawn animation sets based on the weapons style (Pistol, Rifle, Submachine, Lightmachine, SniperRifle, Shotgun, and Melee) and may possibly even swap animation tree’s for more flexibility. I have this swap taking place immediately when the weapon is replaced (usually through equipping and unequipping). There are still tests that need to be done to ensure this method works properly without further improvement but I have my plans set to a different task at the moment.
Beretta 92FS Third Person
Beretta 92FS Third Person Aiming
This issue I didn’t notice until I started adding the new Beretta 92FS and it had it’s own set of animations (including it’s own animation set for organization purposes and what proposed the weapon type/style changes discussed above). There are/were several mechanics that relied on timing before performing another action. An example would be firing the weapon and then returning to weapon idle (weapon idle is “injected” so no matter what type of idle; walking, iron-sight aiming, etc., going back to idle works perfectly fine). It technically needs to wait until the end of the firing animation before going back to idle or you’ll notice a hiccup or snap when switching animations.
My overall plan is to eliminate timers all together (except for a few that rely on timers, such as reloading, or equipping weapons) and rely on a few things. In place of “SetTimer” I use instead “AddDelayedAction(AnimationName, FunctionName).” This custom function simply works with a dynamic array which is then used within the “OnAnimEnd” event and then triggers the correct action based on what animation has ended. This makes these delayed types of actions reliable since they are executed at the correct time and it’s no longer guessed with timers.
No more time to blog now, I have to get this weapon class rewritten, because there is more I have to do than what I’ve explained, but the hardest part is finished (the overall planning on how to eliminate this situation).
