어떻게 게임 서버 비 즈 니스 논 리 를 빠르게 씁 니까?

0. 배경
서버 프레임 워 크 디자이너 가 만약 에 디자인 을 잘 하면 이런 몇 가지 상황 을 고려 하면 게임 서버 의 논리 적 선명 도 든 업무 논 리 를 쓰 는 프로그래머 든 매우 우호 적 이다.게임 서버 의 업무 논 리 를 많이 썼 기 때문에 한 게임 기획 이 제기 한 수 요 를 서버 업무 논리 개발 에 귀납 하면 몇 가지 상황 을 처리 해 야 한다.
1. 비 즈 니스 논리 템 플 릿
다음은 코드 템 플 릿 을 보 여 줍 니 다. 어떤 언어 개발 이 든 대체적으로 유사 합 니 다.

--     

-- tbPlayer     
tbPlayer = {
    dSocketId = 0,
    time_rec  = {    --     
        birth        = 0,
        login       = 0,
        offline     = 0,
        dailyResets = {[{H,M}] = V, ...}
        weeklyReset = 0,
    },
    sysA = tbAInfo, --    
    sysB = tbBInfo, --    
}

--         
tbAInfo = {
    lastTime = 0, --        
}


function born(tbPlayer)
    -- todo   
    --      ，     
end

function loadData(tbPlayer)
    -- todo     
end

function saveData(tbPlayer)
    -- todo     
    --   ？  
end

function onLogin(tbPlayer)
    -- todo        
end


function offline(tbPlayer)
    -- todo       
    --   /  
end

function sendOnLogin(tbPlayer)
    -- todo       
    --    dailyReset         
end

function dailyReset(tbPlayer, tbTime={dHour, dMinute})
    -- todo     
    -- 0 ，         
end

2. 데이터 구조
일반 게임 복 은 데 이 터 를 메모리 에 직접 저장 하 는 것 으로, 어떤 방법 은 즉시 저장 하 는 것 일 수도 있 고, 어떤 것 은 정시 에 저장 하 는 것 일 수도 있다.전통 적 인 사이트 개발 과 유사 한 것 도 있 는데 업무 논리 에 데이터 가 필요 할 때마다 데이터 베 이 스 를 꺼 내 고 수정 한 후에 저장 합 니 다.게임 유형 이 많 기 때문에 서로 다른 게임 은 서로 다른 지구 화 전략 을 사용 하 는 것 이 흔 하 다.이상 에서 말 한 세 가지, 재 프로젝트 에서 필 자 는 모두 본 적 이 있다.
게임 업무 의 데이터 구조 디자인 에 대해 개인 적 인 경험 을 말씀 드 리 겠 습 니 다.우선 시간 과 관련 된 데 이 터 는 다음 과 같다.

birth 건 호 시간

login 접속 시간

오프라인 오프라인 오프라인 시간

daily Resets 매일 리 셋 시간, 여러 시간

weekly Reset 매주 리 셋 시간

대부분의 업무 논 리 는 상기 몇 시간 을 중심 으로 진행 해 야 한다.이 몇 곳 을 잘 처리 하면 프로그래머 의 개발 효율 을 대폭 높 일 수 있다.daily Resets 와 weekly Reset 시간 기록 은 매일 리 셋 되 고 매주 리 셋 되 는 논 리 를 실현 하기 위해 서 입 니 다.매일 리 셋 할 때 주의 하 셔 야 합 니 다. 여러 시간 이 있 을 수 있 습 니 다.새벽 0 시 는 매일 리 셋 을 하 는 가장 흔 한 시간 이다.하지만 유 저 를 돌 보 며 휴식 을 취하 거나 서버 의 0 시 스트레스 를 줄 이기 위해 일부 또는 전 부 를 다른 시점 으로 초기 화 하 는 게임 도 있다. 예 를 들 어 새벽 3 시, 새벽 5 시 등 이다.매주 리 셋 되 는 경 우 는 비교적 적 고 여러 개가 존재 하 며 보통 월요일 오전 0 시 를 선택한다.
많은 게임 들 이 전기 7 일 남 겨 두 기 위해 많은 일 을 하고 번호 짓 는 시간 도 이런 곳 에서 필요 하 다.물론 이것 은 매우 유용 한 필드 로 업무 논리 든 게임 데이터 분석 이 든 모두 번호 작성 시간 이 필요 하 다.
온라인 시간 은 가장 흔히 볼 수 있 는 시간 입 니 다. 일반 게임 은 게이머 가 온라인 에 있 을 때 만 논 리 를 처리 합 니 다.유저 가 일단 오프라인 상태 가 되면, 유저 데 이 터 를 처리 하 는 경 우 는 드물다.유저 가 다시 접속 할 때 까지 기 다 려 야 데 이 터 를 처리 하고 계산 할 수 있 습 니 다.그 유저 들 이 접속 하지 않 고 실행 해 야 할 데 이 터 를 보충 합 니 다.예 를 들 어 매일 메 일, 매일 보상 이런, 우 리 는 정말 매일 게이머 데 이 터 를 데이터베이스 에서 꺼 내 처리 하지 않 을 것 입 니 다. 그리고 게이머 가 접속 할 때 까지 기 다 렸 다가 온라인 이 아 닌 시기 에 발생 하 는 일 을 연산 하지 않 을 것 입 니 다.이러한 처 리 는 모두 게이머 들 의 지난번 접속 시간 에 의존 하여 계산한다.
오프라인 시간 은 온라인 시간 만큼 많이 쓰 지 는 않 았 지만 적지 않 았 다.
3. 흔 한 논리
3.1 건 호 born
유저 의 모든 것 은 건 호 에서 기원한다.건설 번 호 는 일부 기초 장비, 기초 속성 등 데이터 초기 화 를 해 야 합 니 다.
3.2. loadData 와 saveData 의 지속 성
게이머 가 로그 인 할 때, 우 리 는 데이터 베 이 스 를 게임 서버 의 메모리 로 꺼 내야 한다.데이터 가 바 뀌 면 서버 충돌 로 데이터 가 손실 되 지 않도록 데이터 베 이 스 를 저장 해 야 한다.그러나 매번 변화 가 생 길 때마다 저장 을 한다 면 데이터베이스 에 대한 압력 이 클 것 이다.성능 과 데이터 안전 을 저울질 하기 위해 서 는 정기 적 으로 저장 하거나 정기 적 으로 일부 데 이 터 를 저장 하여 즉시 저장 하 는 등 저장 전략 을 제정 해 야 한다.서로 다른 데이터 의 중요 도가 다 르 기 때문에 서로 다른 저장 전략 을 사용 할 수 있다.
3.3. 유저 온라인 onLogin 과 sendOnLogin
왜 윗 선의 조작 을 onLogin 과 sendOnLogin 두 함수 로 나 누 어야 합 니까?이들 의 차 이 는 전 자 는 데이터 예비 처 리 를 하 는 데 쓰 인 다 는 것 이다.방금 말 한 것 처럼 매일 메 일 아, 매일 그 처 리 를 보상 합 니 다.후 자 는 재 데이터 예비 처리 가 실 행 된 후에 이 업무 논리의 협 의 를 동기 화 하 는 것 이다.데이터 전처리 와 프로 토 콜 을 동기 화 하 는 것 은 매우 필요 하고 편리 하 다.또한 어떤 시스템 이 다른 시스템 에 의존 하면 이 시스템 의 onLogin 작업 은 다른 시스템 의 onLogin 뒤에 두 어야 합 니 다.
3.4. 유저 오프라인 과 단선 중 오프라인 과 reconnect
게이머 들 의 오프라인 은 흔히 비상 식적 인 조작 이 존재 하기 때문에 오프라인 은 일반적으로 협의 가 동기 화 되 지 않 고 데이터 처리 만 있다.오프라인 은 클 라 이언 트 socket 과 끊 긴 곳 에 두 고 처리 합 니 다.오프라인 에서 도 보관 여 부 를 결정 할 수 있다.특히 주의해 야 할 것 은 모 바 일 게임 에서 끊 기 는 것 은 매우 쉽다 는 것 이다.그래서 단선 중 련 을 고려 해 야 합 니 다.즉시 재고 여 부 는 사실 단선 재 접속 디자인 과 관련 이 있다.게이머 들 의 데 이 터 를 한 동안 저장 하면 1 분, 30 분 등 오프라인 작업 은 모 바 일 게임 에서 크게 줄 어 들 것 입 니 다.오프라인 원가 에 따라 스스로 고려 할 수 있 습 니 다.그러나 조작 은 없어 서 는 안 된다. 단지 실 행 된 수량의 문제 일 뿐이다.
4. 마무리
이상 은 개인 경험 을 총 결 한 업무 논리 개발 장면 입 니 다.다만 단순히 비 즈 니스 논 리 를 흔히 볼 수 있 습 니 다. 네트워크, 로그, 프로 토 콜, 지구 화 등 게임 서버 의 프레임 워 크 디자인 은 논의 되 지 않 습 니 다.이것들 이 야 말로 게임 서버 디자이너 의 큰 머리 다.
기억력 이 좋 은 것 은 썩 은 붓끝 만 못 하 다.