# REPORT: Alex Obatake ## ROLLUP * **RISKS**: * **OBJECTIVES**: * **INITIATIVES**: * **TASKS**: * **NEED**: * **ACCOMPLISHMENTS**: * **KEY DECISION** * **CAREER GOALS** * Framework: https://counterplay.atlassian.net/wiki/spaces/CGH/pages/1221754906/Engineering+Career+Framework * Individual Contributor (0%) vs Manager (100%) spectrum: 25% * Want 1: Systems, Plugins, and Architecture * Want 2: Working close to screen / leaf node * Want 3: Debugging * Dont 1: JIRA / Process * Dont 2: UI engineering * Title: Senior Gameplay Engineer ### Pending Topics ### 03/21/24 * Pulse check * Doing well ### 01/11/24 * Pulse check * Doing well ### 11/30/23 * Pulse check * Doing well ### 11/17/23 * Pulse check * Doing well ### 11/01/23 * Pulse check * Doing well ### 10/06/23 * Pulse check * Doing well * DarkWinter ### 09/07/23 * Pulse check * Doing well * A little stuck on CPGStat system changes ### 08/25/23 * Pulse check * Doing well * Enjoying balance of work ### 08/04/23 * Pulse check * Doing well * Lots of meetings * Allocation and management ### 05/19/23 * Pulse check * Doing well * Speed is inconsistent * Career goals ### 04/07/23 * Pulse check * Doing well ### 03/07/23 * Pulse check * Doing well * AI weapon migration * ItemHeld changes * Getting finished with first pass * Would like recommendations on how to test that the changes work properly * Overview of progress * Basic idea is having a primary slot tag and a set of secondary slots * No difference in behavior, but primary is more easily referenced * Hold changed to specify an item to stow, hold, and whether the held item is primary rather than just always stowing the primary * Grenade action * Trajectory replication needed? Right now we calc the trajectory on the server and send to the clients. This seems a bit unnecessary, but I wanted to confirm before deleting/changing it * Also the trajectory calculations are very convoluted and could probably be simplified, but they work so probably no need to change currently. * Task scheduling * Will continue to work on ItemHeld and then get weapon hiding working with grenade action. * After that, will probably move to brawler molotov * Tasks after the ItemHeld changes have not been added to Jira yet, but I can add them now if you want ### 02/21/23 * Pulse check * Good overall * AI weapon migration * Projectile actor changes going smoothly ### 01/07/23 * Pulse check * Instanced destructible config * How to deal with async code * Proj movement * How much original code to configify vs modify component directly * If we want to reuse, then configify, make config override * Maybe proj movement init function ### 01/10/23 * Pulse check * * Current priority: destructibles vs AOE redo * do AOE first since it should be a really quick fix * Can push to MS9 dev while stabilization is happening * Destructibles can be MS9 * IWYU clarification * Try to minimize includes in header * Foreward declare as much as possible * Include Gameframework/Actor.h if using actor * Move "hot" files to their own files * AI Weapon Migration approach * Configify ProjectileMovement vs grenade-like Proj actor subclass * Configify proj actor * Where should anim montage live, item vs action * Currently in attackdef * Put anim in action * Action table defines what action is used * Share action logic, can quickly * AI no switch weapons * Always have weapons equipped * Having two items is still concern * Explode makes APExplosion which makes damage over time * Config object with all actions * AI will look at it, pick attack, get action config * Action will spawn projectile, will bypass need to APweapon * Maybe make grenade into item? Also support actor as instigator * CPGProjectile is actor * Could still need * Maybe item to represent grenade in travel * Try to represent in one place rather than two * Support actors and items as instigators for hit events * Currently no ammo limits on AI * Overview of tracing archplan ### 01/10/23 * Pulse check * Everything is going well * DW destructibles * Integrated with hit handling systems * Documentation in progress * Proposed change * X * DW interactables * Old grapple traversal uses interactible from godfall, outdated * Allow punch interactible * Zanzibar, use this in pedestal * Hit interactible to trigger interaction * Interactible needs to be hittable * Interactibles are actors and actor components * Plugin is interactible component * One of BP_Interactible_Pedestal_X * Interatible component in CPGInteractible * No information passed through interaction, just yes/no * UpdateInteractSearch, updated when holding interact button * Search on tick or continue interaction * Find aim target interactible * Trace channel for interactibles * APInteractible aim collision profile blocks interactible trace channel * Old interactibles: has sphere collision * Generate overlap events: any overlapping collision will trigger events automatically * Interact can trigger from overlap or active interaction * Hits should be instant interaction * Potentially no showing UI on interactible, only punch * Runs interaction action to actually get input to do interact * Instigator = interactible * StartInteraction on playercontroller * CPGInteractorPawnComponent not yet implemented, but can implement * Player controller->start action -> start interaction on player controller -> to interaction component * Delegates and triggers fire everywhere * Interactible component triggers: trigger interactible coplete * Hidden trigger for encounters: on APInteractibleActor: ICPGEncounterInterface: * Encounter = represents the states: idle, in progress, completed, failed, aborted * trigger for all states except idle * So we have a unified way to understand anything with these states * character = encounter, loot = encounter, camp = encounter etc * Chains and heirarchies of encounters * Interactible idle, when interacted goes to in progress * Character is encounter: in combat is in progress, exit combat is abort, if die fire complete ### 11/29/22 * Pulse check * Everything is going well * Waiting on PR * Collin review tomorrow * Hit Handler * Things left to integrate * Power melee * Destructibles * Generate tasks for above and drop into current or next sprint * Goal: finish up hit handling & destructibles by EOY * Short live PR review * Integrate hit handler globals to udevelopersettings * Change to base 1 multipliers (50% increased = 1.5) * Change BInit and biscosmetic to enum * Rename HitAction to some ### 11/15/22 * Pulse check * Going well * Hit Handler runtime damage * Ensure common simplest cases of applying damage and hit reactions are easy to use even without config * Ability system conversion * Mid/late Nov plugin will be merged * Gameplay Actions overview * Action run on all instances * Action in sim proxy, no replication * If no recieved prediction, rollback * Check action can start * Ask if can start * init params (only origin instance) * OnInitialize * OnStartThis * -> Can Start Action * Dont instantiate until we know it can start * Override this function * OnStopThis * Action can stop itself * Actions can stop other actions * Ex: dodge can stop locomotion or locomotion can stop because of dodge * Usually one knows about other * * Params have initialization data * Action does not have to ask for data * Holds state needed to run entire action * No action RPCs, params should have all data needed * Other actions can stop new action from starting * Actions can have tag container, identifies action * Start/stop actions based on tags * Action is a composition of befavior * ex: Marked as disable: blocks all other actions except disable * Action rules know about others on action component * Can ask about other action components manually * Can also wrap within task * Moving away from strict action heirarchy * Moving towards modular functionality in action tasks + config * Action rules: precursor to config * Old pattern of behavior owns data * Always static data, assigned to action class * Use interface to get component * Config for action as hit handler subconfig * Look at hit result param * Params in handle must all be unique type * Brawler acitons: when hit does hit reaction action * Punch -> stagger is action * Action logs say when actions are blocked * Log log_gameplayaction * Action subconfig: parallel: action * ActionTagsParallelTo * Hit Reactions overview (if time) ### 11/01/22 * Pulse check * Going well * Hit Handling ### 10/25/22 * Pulse check * Going well * Handling git branches * fetch dev and merge into branch * Hit handling networking * Client auth, make path that takes hit context * Weapon and projectile depricated after AI weapon migration * Unsure if event key is needed, remove for now * New code path with hitcontext and hittype * Circular dependencies in plugins doesn't work * Make client auth listen to init with low prio * Handling wouldn't need to know * Create delegate/trigger in hit handling for replication * Components applied to anything that needs to handle hit rep * Characters only * Asks does instigator or target have clientauth component * Use that component owner to replicate hit * If both have component * victim is auth * player is auth vs ai * If hit between remotes, no reporting * Client runs all logic * ClientAuthhitComp sends hitContext to server * Authoritatice * Server runs from pre-apply through * Auth from client * Expect other players to detect hits themselves * In predictive mode, simulated hit * If client == server, system does nothing * If serverclient sees other's hit, expect other to send hit to me * If other detects hit, run self as auth then send to server as auth * On my machine, see serverclient's hit, run as client auth as simulated * Hit detector doesn't set hit auth level * Hit handling, client auth hit type needs to be extracted from client auth plugin * Only server can apply gameplayeffects * Hit handling and client auth doesn't send back down * Only sends up to server, server's individual systems send back down auth logic * ### 10/13/22 * Pulse check * Pace isn't as fast as expected * Learning UE is primary reason for slowdown * Destructible * Delaying PR until config is implemented * Config * Actor will temporarily reference config (instead of expected other way around) * Update tasks to reflect current work for destructibles * Add hit handler system to next sprint * Update Archplan to current plans * Let Collin know when I start on destructible migration so Hit Handling archplan can be made ### 10/04/22 * Pulse check * Destructibles code review * Networking review ### 09/29/22 * Pulse check * Starting to understand tasks * Review destructibles arch plan ### 09/26/22 * Pulse check * Eng process * 30/60/90 plan * 30 * Work closely with Tech Art to implement native destructibles system. * https://counterplay.atlassian.net/wiki/spaces/DW/pages/1904017428/ArchPlan+Destructibles * Contacts: Alan Lee, Eric Karl, Jonathan Massey * Improve and simplify gameplay code that interacts with destructibles. * Assist with hit handling systems. * 60 * Begin ramping up on AI systems. * Assist with AI weapon migration to new item systems. * 90 * Demonstrate understanding of multiple gameplay systems: AI, Items, Inventory, Guns. * Majority of work for AI weapon migration to new item systems completed.