---
# System prepended metadata

title: 'REPORT: Alex Obatake'

---

# 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.