1.
- 스킬 사용
- 스킬이 가진 기본 피해량, 범위 등의 데이터를 RunData로
- RunData가 갖고 있는 효과 목록 검사 후 있으면 계산, 없으면 패스
- 최종 계산 후 피격자에게서 TakeDamage 호출
장점 // 직관적임(아닌가?), 동적 변화를 그대로 적용함
단점 // 매 번 계산함
2.
- 스킬 레벨업, 강화 등 변화가 생겼을 때 스킬별 대미지 계산 후 RunData에 저장
- 스킬 사용
- RunData에 미리 계산해둔 결과를 피격자에게서 TakeDamage 호출
장점 // 매 번 계산 안 해도 됨
단점 // 일시적인 버프, 치명타 유무, 스택 개수에 따른 대미지, 몬스터 타입에 따른 대미지 등등..
실시간으로 변화하는 경우가 많다면 별로 의미 없을 수 있음
3.
둘을 섞은 방식
- 스킬 레벨업, 강화 등 변화가 생겼을 때 스킬별 대미지 계산 후 RunData에 저장
- 스킬 사용
- 일시적인 강화 효과가 있는 경우,특정 대상에게 추가 피해, 치명타, 백어택 등 계산
- RunData에 미리 계산해둔 결과와 계산 후 피격자에게서 TakeDamage 호출
장점 // 유연함
단점 // 능지가 모자랍니다, 계산 순서 및 효과 적용 순서 등 기획 필요
2번 베이스에 짜잘한 것들만 추가 계산하는 방식으로 가야겠다..
1번도 은근히 나쁘지 않다고 생각해
그래용?
@211214 개인적인 생각이지만, 일단 데미지가 이상하게 출력된다면 데미지 계산식 근처만 살펴봐도 금방 디버깅이 가능하다는 장점이 클 것 같음. 계산을 많이 하는 건 맞더라도 그게 그렇게 치명적인 부하가 생길 것 같지는 않다고 생각해서
GPT도 성능 생각하면 2번방식이어야 하는데, 변화값이 필요한 시기가 생기면 1번을 병행해야하기 때문에 의미가 없어지고 3번 방식으로 가라고 하네.
음.. GPT쟝은 보기에서 골라주네 클로드는 3개 다 집어치우고 파이프라인시스템을 제시하는데.. BaseDamage -> Multipliers -> Additions -> Conditionals -> FinalDamage 꼴리긴하는데 좀 오버 엔지니어링 같아서 보류
@211214 데미지 공식 시스템화 하면 초기때 스트레스 테스트혀 / 몹 바글바글 소환해서 범위 무기 난사
으음 아주 먼 얘기인.. 클로드 하는 말 들어보면 2개월은 걸린다는데 다 쳐내고 기존 거 활용해서 기간 줄여야겟다
근데 데미지 계산 정도의 수준은 요즘 사양으로 백만분의 1초 걸리는 그런거 아님?
그럴 거 같긴 함
나는 3번으로 함. 스킬 클래스에서 데미지 퍼센트 값을 갖고 있고(스킬 레벨업 시 변경됨) 데미지계산 시 그 값과 함께 계산식에 따라 처리함.
스탯이랑 비슷한데, 나는 스탯 만들때 기본 스탯 -> 영구 스탯 -> 임시 스탯 이런식으로 순서 정해놓고 버프 적용 전용 메서드 따로 만들어서, (키값, 수치) 받아서 적절한 딕셔너리에 보관하고 호출 될 때만 재계산했음...