23. FSM
여러 스테이트 사이를 오가는 조건을 정의
실제 구현에서는 스테이트별 수행을 포함
매 프레임 Update, Draw, Input, …
스테이트 시작, 종료 루틴 등
24. 아마 이렇게?
class IdleState : IState {
public void Update(...)
public void Input(...)
public void Draw(...)
public void OnEnter(...)
public void OnExit(...)
}
82. 처리 대상
값을 유형별로 분류
각종 게이지
HP
MP
소모, 채우기
상태효과
버프
디버프
걸기, 풀기
각종 스탯
공격력
방어력
적용, 변조
83. 처리 대상
많다..
각종 게이지
HP
MP
스태미나
분노게이지
획득 동전
획득 점수
남은 총알
킬 수
상태효과
장비 아이템
쿨타임
피버
광폭화
공속 변경
기절
DOT 대미지
지연 회복
자연 회복
각종 스탯
공격력
명중률
크리티컬 배율
크리티컬 확률
방어력
회피율
반사율
보유 스킬
스킬 레벨
이동 속도
행동 가능
84. 처리 대상
많다..
상태효과
스탯 변경
장비 아이템
쿨타임
피버
광폭화
공속 변경
기절
각종 스탯
공격력
명중률
크리티컬 배율
크리티컬 확률
방어력
회피율
반사율
보유 스킬
스킬 레벨
이동 속도
행동 가능
상태효과
점진적 영향
DOT 대미지
지연 회복
자연 회복
각종 게이지
HP
MP
스태미나
분노게이지
획득 동전
획득 점수
남은 총알
킬 수
85. 설계: 게이지
초기화: Row 별로 이름, min, max, 시작 값
Init(“HP”, 0, 100, 100);
변경: 이름과 변경치를 받아서
Modify(“HP”, -20);
이벤트: 값 변경, min, max 도달 때마다 FSM 으로
86. 설계: 스탯
초기화: 유형별로 정수, 실수, 또는 bool 값으로
Init(“Atk”, 100)
Init(“이동가능”, true)
변조: 배율 또는 +-로 변조된 값 인기
bool 값은 &&로 변조 (잘 모르겠음)
149. 기획과의 거리
시스템의 목적
• 기획자의 요구를 검열 X
• 읷관성 있고 더 기민한 지원 O
규칙에서 벗어난 하드코딩 필요함
-> 프로그래머는 시스템으로 흡수하도록 노력
기획자의 의도와 지향점을 충실하게 수집하고
시스템에 반영핬야..
150. 기획과의 거리
기획 모델과 완젂 읷치하는 시스템과 언어는 위험
기획은 언제나 변할 수 있다
시스템 설계를 시작하는 시점에는
기획도 아직 덜 자랐음을 이핬
적극적으로 요구사핫을 수집하되,
적젃한 정규화와 직교성이 필요
151. 『도메읶 언어』
“여러분의 프로젝트를 문제 도메인에 가까운 곳으로
옮길 방법들을 궁리핬봐야 한다고 생각한다.
더 높은 추상화 수준에서 작업함으로써 사소한 구현의
세부사핫들을 무시하고 도메읶의 문제들을 푸는 읷에만
정싞을 집중할 수 있다.”
- 실용주의 프로그래머 12절 <도메인 언어>