Josh Petrie의 문자 대 상태 시스템 과 같은 솔루션 에는 이점 (작은 저장 크기, 모든 게임 사본에서 작동)이 있지만 게임 디자인 및 상태 시스템은 본질적으로 암호 시스템에 결합됩니다. 암호 나 상태 또는 디자인 및 시스템 전체에 대한 변경 사항은 모두 다릅니다.

훨씬 간단한 해결책은 평소대로 저장 시스템을 구축하고 상단에 암호 시스템을 추가하는 것입니다. 이것은 저장에 암호를 저장하고 (파일 이름으로 두 배가 될 수 있음)로드시 ​​암호를 검증하는 것만 큼 간단하거나 주위에 많은 암호화 라이브러리 중 하나를 사용하는 것만 큼 간단합니다.

이 답변에 혼란이있는 것 같습니다.

1) 작전은 단순히 저장을로드 할 수있는 암호를 요청했습니다 … 암호 가 저장 될 필요는 없습니다 .

2) 오늘날 많은 게임에는 상당한 저장 용량이 필요합니다. 퀴즈 게임을 위해 10MB 파일을 생성하는 내부에 빠른 저장 /로드 시스템을 구축했습니다! Josh Petrie의 저장 시스템은 유효하지만 매우 제한적입니다. 즉, 저장 시스템이 중요하지 않은 즉시 모든 관련 데이터를 유지하려면 암호의 길이가 엄청나게 길어야합니다.

예를 들어 보스가 30 명이면 어떻게됩니까? 20 개의 업적? 우리는 업적을 절반 쯤 밟고 있습니까? 그는 몇 레벨입니까? 우리는 건강, 생명, 동전, XP를 위해 몇 비트를 따로두고 있습니까? 스냅 샷이 레벨 사이에 있지 않지만 레벨을 반쯤지나 가면 어떻게됩니까? 플레이어, 적, 발사체, 파괴 / 변경 지형의 위치가 갑자기 저장해야하는 많은 상태에 추가됩니다.

참고로 30 자 알파벳과 10 자 암호를 가정하면 약 50 비트의 정보를 저장할 수 있습니다. 게임 / 엔진이 단일 객체의 위치, 회전 및 스케일링을 저장하기 위해 최대 320 비트를 사용하는 것은 드문 일이 아닙니다. 물론, 적은 비용으로 더 많은 일을하기 위해 모든 종류의 최적화 트릭을 수행 할 수 있지만 궁극적으로 게임을 재미있게 만드는 데 전념하는 시간을 낭비하고 있습니다.

답변