소개: 좋은 프로젝트 Zomboid Mod는 작고 테스트 가능한 아이디어로 시작됩니다.
Project Zomboid 모딩은 종종 제작법 추가, 무기 균형 재조정, 생존 특성 생성, 전리품 동작 조정, 삶의 질 상호 작용 추가 등 사소해 보이는 아이디어로 시작됩니다. 그러면 작업이 확장됩니다. 올바른 폴더 구조, 정확한 메타데이터, 예상되는 컨텍스트에서 로드되는 스크립트, 항목 또는 레시피 정의, 변경 사항을 테스트하는 방법, 멀티플레이어 저장에서 모드가 다르게 작동하는 이유를 알아내기 위한 계획이 필요합니다.
어려운 부분은 루아 뿐만이 아닙니다. 게임플레이 아이디어를 통제된 모딩 워크플로로 바꾸는 것입니다. 범위를 정의하고, 필요한 게임 데이터를 식별하고, 한 번에 하나씩 변경하고, 로그를 읽고, 깔끔하게 테스트하고, 각 개정을 문서화합니다. AI는 연구, 계획, 가설 디버깅 및 테스트 준비를 가속화할 수 있습니다. 현재 Project Zomboid 빌드를 이해하고, 게임 내 파일을 검증하고, 서버 및 워크샵 규칙을 준수하는 것을 대체할 수는 없습니다. 이 가이드는 신규 제작자와 복귀 제작자에게 아이디어에서 유지 관리 가능한 모드까지 실용적인 경로를 제공합니다.
Project Zomboid 모딩이란 무엇입니까?
프로젝트 좀보이드 모딩 게임에서 지원되는 모드 구조, 데이터 정의, 적절한 경우 Lua 스크립팅 및 Steam 창작마당과 같은 승인된 배포 채널을 사용하여 Project Zomboid에 대한 사용자 정의 콘텐츠 및 게임플레이 변경 사항을 합법적으로 생성하는 것입니다. 모드는 현재 빌드와 제작자가 사용할 수 있는 API에 따라 아이템, 레시피, 특성, 직업, 샌드박스 옵션, UI 동작, 월드 콘텐츠 또는 게임플레이 시스템을 추가하거나 수정할 수 있습니다.
실행 파일을 수정하거나, 치트 방지 또는 서버 규칙을 우회하거나, 자산을 훔치거나, 모드를 허용하지 않는 서버에서 불공정한 이점을 얻는 것이 아닙니다. 책임 있는 모드는 변경 사항이 무엇인지 명확하고, 대상 빌드와 호환되며, 공유되기 전에 테스트되어야 합니다.
| 차원 | 프로젝트 좀보이드 모딩 | 일반 게임 개발 |
|---|---|---|
| Environment | 게임 지원 모드 폴더, 데이터 파일, Lua 및 모드 도구 | Game engine and complete source project |
| Typical output | 아이템, 제조법, 특성, 시스템, 지도 또는 삶의 질 기능 | 독립형 게임 또는 독점 기능 |
| Main constraint | 현재 게임 빌드, 모드 API, 로드 순서 및 서버 호환성 | 엔진 아키텍처, 플랫폼, 예산, 생산 범위 |
| Validation | 로그, 클린 저장, 싱글 플레이어 및 허용된 멀티 플레이어 테스트 | 파이프라인, 자동화된 테스트, QA 및 배포 구축 |
💡 Key idea: 안정적인 모드는 단순히 한 번 로드되는 모드가 아닙니다. 여기에는 정의된 범위, 명확한 종속성, 안전한 업그레이드 동작 및 플레이어가 실제로 생성할 상황에 대한 테스트 경로가 있습니다.
프로젝트 Zomboid 모딩 기본 사항: 구조, Metadata, Data 및 Lua
동작을 작성하기 전에 모드를 이해하기 쉽게 유지하는 4가지 레이어를 이해하세요. 정확한 폴더 이름과 지원되는 파일은 게임 빌드에 따라 다를 수 있으므로 이전 튜토리얼을 맹목적으로 복사하는 대신 최신 공식 문서와 기존 호환 모드를 참조로 사용하세요.
Mod identity and metadata
메타데이터는 모드를 식별하고 플레이어에게 설명하며 로드 및 배포에 필요한 정보를 설정합니다. 안정적인 내부 아이덴티티를 조기에 활용하세요. 나중에 부주의하게 이름을 바꾸면 저장, 종속성 및 업데이트가 복잡해질 수 있습니다.
Data definitions
아이템 정의, 레시피, 특성, 직업, 전리품 관련 구성, 샌드박스 옵션 등 많은 기능이 게임 데이터를 통해 표현됩니다. 이러한 파일을 일회용 구성이 아닌 게임플레이 디자인의 일부로 취급하십시오.
Lua scripts
Lua은 모드에 데이터 정의만으로는 표현할 수 없는 논리가 필요할 때 유용합니다. 스크립트의 범위를 좁히고, 해당 동작에 대해 함수 이름을 지정하고, 관련 없는 시스템을 하나의 파일에 혼합하지 마십시오. 작고 명시적인 스크립트는 게임 업데이트 후에 디버그하기가 더 쉽습니다.
Assets and localization
텍스처, 모델, 사운드, UI 요소 및 번역된 텍스트에는 안정적인 이름, 명확한 소유권, 게임에서 찾을 수 있는지 확인하는 테스트 등 스크립트와 동일한 원칙이 필요합니다. 허가 없이 자산을 사용하지 마십시오.
| 층 | 대답할 질문 | 일반적인 실패 |
|---|---|---|
| Metadata | 게임과 플레이어가 이 모드를 명확하게 식별할 수 있나요? | Incorrect or unstable mod identity |
| Data | Does each definition match the current game 형식인가요? | Typo, wrong identifier, or outdated field |
| Lua | 이 논리는 언제 실행되고 어떤 상태로 변경됩니까? | Wrong event, nil reference, or duplicated work |
| Assets | 파일 이름이 올바르게 지정되고, 참조되고, 라이센스가 부여되어 있습니까? | Missing path or unavailable resource |
| Compatibility | 어떤 빌드, 종속성, 저장 및 서버가 지원됩니까? | Undeclared dependency or breaking update |
Lua을 작성하기 전에 프로젝트 Zomboid 모드를 Plan하는 방법
폴더가 아닌 플레이어를 향한 약속으로 시작하세요. "이 모드를 사용하면 초기 목공 작업의 반복 과정을 덜 반복적으로 만들 수 있습니다."는 "5가지 레시피를 추가하고 싶습니다."보다 더 나은 출발점입니다. 그런 다음 플레이어가 무엇을 할 수 있는지, 모드가 적용되는 기존 시스템은 무엇인지, 절대 변경해서는 안 되는 것은 무엇인지, 새로운 저장에서 성공을 측정하는 방법을 정의합니다.
작은 예를 들어, 제한적이고 명확하게 설명된 제작 혜택을 제공하는 생존 특성을 상상해 보세요. 이를 6가지 결정으로 분류합니다. 플레이어 효과를 정의합니다. 해당 캐릭터와 게임 상태를 식별합니다. 데이터 또는 Lua이 동작을 소유하는지 여부를 결정합니다. 제외 사항 및 멀티플레이어 고려 사항을 나열합니다. 저장/로드 및 재설정 기대치를 정의합니다. 구현하기 전에 테스트 케이스를 디자인합니다.
이는 모든 빌드에 대한 복사-붙여넣기 솔루션이 아닌 개념적 의사 코드입니다.
WHEN: a supported character state is evaluated
IF: the character has the approved trait
AND the feature is enabled by the current settings
THEN: apply the defined, limited crafting benefit
show clear feedback where appropriate
preserve normal behavior for everyone else
TEST: new save, existing save, disabled setting, multiplayer policy, reload그 계획은 숨겨진 선택을 가시화합니다. 또한 일반적인 모딩 실수를 방지합니다. 먼저 광범위한 후크를 추가한 후 모든 플레이어에게 영향을 미치거나, 너무 자주 실행되거나, 재로드 후 예측할 수 없는 동작을 발견하는 경우입니다.
프로젝트 Zomboid 모딩 디버깅: 로그, 로드 순서 및 정리 테스트
실패를 범주로 분리하면 대부분의 디버깅이 더 쉬워집니다. 모드가 게임에 나타나나요? 로드되나요? 데이터 정의가 해결됩니까? Lua 이벤트가 실행되나요? 이 동작은 이전 저장에서만 작동합니까, 새 저장에서만 작동합니까, 아니면 다른 모드가 있을 때만 작동합니까? 세 개의 파일을 동시에 변경하지 말고 오류가 사라지기를 바랍니다.
로그는 나중에 고려하는 것이 아니라 개발 프로세스의 일부입니다. 첫 번째 관련 오류를 읽고, 관련된 파일과 줄 또는 식별자를 식별하고, 특정 설명을 테스트하는 가장 작은 변경을 수행합니다. 가능한 경우 깨끗한 테스트 프로필을 유지하거나 제어된 저장을 유지하십시오. 호환성 확인 시에는 테스트에 꼭 필요한 모드만 사용하고, 해당 모드의 버전과 로딩 순서를 기록해 두세요.
- 모드가 활성화되어 있고 해당 ID가 의도한 설정과 일치하는지 확인하세요.
- 나중에 증상을 추적하기 전에 로그에서 가장 먼저 유용한 오류를 확인하세요.
- 상태 지속성이 중요한 경우 새 저장과 기존 저장을 별도로 테스트하세요.
- 호환성 테스트를 위해 로드 순서와 선언된 종속성을 확인합니다.
- 가능한 가장 작은 구성으로 재현합니다.
- 먼저 싱글 플레이어를 테스트한 다음 멀티플레이어 환경만 허용하세요.
통제력을 잃지 않고 프로젝트 Zomboid 모딩을 위한 Using AI
AI는 계획 및 문서화 오버헤드를 줄일 때 가장 가치가 있습니다. 대략적인 기능 요청을 모드 요약으로 바꾸고, 저장 호환성에 대한 질문을 제안하고, Lua 조각을 일반 언어로 설명하고, 로그 메시지를 디버깅 가설로 바꾸거나, 집중적인 회귀 체크리스트를 생성할 수 있습니다. 현재 게임 빌드에 대한 신뢰할 수 있는 문서는 아닙니다.
AI에게 가정을 보여달라고 요청하세요. 이벤트, API, 속성 또는 폴더 레이아웃을 권장하는 경우 해당 조언을 현재 Project Zomboid 참조 및 로컬 테스트와 비교하십시오. AI는 자신있게 오래된 API를 발명하거나 로그 발췌문을 잘못 읽을 수 있습니다. 테스트되지 않은 변경 사항을 출시할 이유가 아닌 시작 가설로 반응을 다루십시오.
| 모딩 작업 | 유용한 AI 기여 | 창작자의 책임 |
|---|---|---|
| Feature planning | 플레이어 목표, 범위, 제약 조건 및 극단적 사례를 명확히 합니다. | Choose the feature worth maintaining |
| Lua 검토 | 제어 흐름을 설명하고 테스트할 질문을 식별합니다. | Verify APIs and run the script in-game |
| Log triage | Group likely causes and next checks | Read the actual log and reproduce the 발행 |
| Compatibility | Draft a dependency and regression checklist | 현재 빌드, 저장 및 허용된 서버 설정을 테스트합니다. |
| Release notes | Organize player-facing changes and known limits | Keep claims accurate and versioned |
EasyClaw을 프로젝트 Zomboid 모딩 에이전트로 사용하는 방법
EasyClaw은 채팅창뿐만 아니라 데스크톱 기반 AI 에이전트이기 때문에 여기서 유용합니다. 에이전트에게 "이 로컬 모드 프로젝트에 작은 제작 특성 기능 추가 및 테스트"와 같은 목표를 지정하면 작업을 계획하고, 승인된 기술 및 데스크톱 도구를 사용하고, 로컬 파일을 검사하고, 승인한 작업 문서를 작성 또는 업데이트하고, 결과를 확인하고, 발생한 상황을 보고할 수 있습니다. 제작자는 Project Zomboid 클라이언트, 현재 API, 소스 변경 및 최종 릴리스 결정을 계속 제어할 수 있습니다.
EasyClaw은 명시적인 승인 없이 Project Zomboid 실행 파일을 수정하거나, 서버 정책을 우회하거나, 제한된 서버에 가입하거나, Steam 창작마당 항목을 게시해서는 안 됩니다. 실질적인 역할은 합법적인 모드 생성 관련 작업을 실행 루프로 전환하는 것입니다. 이해 → 계획 → 검사 → 실행 → 검증 → 보고. 즉, 채팅, 편집자, 파일 탐색기, 로그, 스크린샷, 릴리스 체크리스트 간의 복사가 줄어듭니다.
1. Create a dedicated Modding Expert Agent
모든 작업에 하나의 일반적인 대화를 사용하는 대신 다음과 같은 전문 상담원을 만드세요. “Project Zomboid Mod Maintainer.” 그 책임은 모드 폴더 검토, 변경 계획 초안 작성, Lua 및 데이터 파일 읽기, 로그 증거 수집, 테스트 준비 및 릴리스 노트 작성으로 제한될 수 있습니다. 로컬 파일 작업, 브라우저 조사, 문서 처리 및 승인된 데스크톱 작업에 대한 관련 기술을 첨부하세요. 이는 일반 보조자에게 매번 프로세스를 재발견하도록 요청하는 대신 에이전트에게 안정적인 역할을 제공합니다.
2. Save stable project rules in MEMORY.md
에이전트에게 MEMORY.md에 로컬 모드 경로, 대상 프로젝트 Zomboid 빌드, 지원되는 종속성, 명명 규칙, 파일 레이아웃 규칙, 테스트 저장 위치, 로그 위치, 릴리스 노트 형식 및 "테스트 준비 완료"의 정확한 정의 등 지속 가능한 프로젝트 정보와 SOP만 작성하도록 요청하세요. 이후 세션에서는 에이전트가 해당 메모리를 먼저 읽으므로 동일한 설정을 다시 붙여넣을 필요 없이 "최신 제작 변경 사항 검토"와 같은 요청이 올바른 프로젝트 컨텍스트로 시작됩니다.
임시 버그 세부정보나 일회성 실험을 영구 메모리로 저장하지 마세요. 현재 작업 보고서에 보관하세요. 메모리는 다음 주에도 여전히 유용할 규칙을 유지해야 합니다. 예를 들어 "백업 없이 안정적인 모드 파일을 덮어쓰지 마세요", "기존 저장 전에 깨끗한 저장을 테스트하세요" 또는 "모든 호환성 보고서에 빌드 번호와 종속성 버전을 기록하세요" 등이 있습니다.
3. Define safety boundaries in SOUL.md
SOUL.md을 Modding Expert의 운영 경계로 사용하세요. 소스 파일을 변경하기 전에 에이전트에게 묻고, 저장 삭제 또는 릴리스 아카이브 덮어쓰기를 금지하고, 다중 파일 편집 전에 백업을 요구하고, 승인되지 않은 게시를 금지하고, 서버 정책 또는 자산 라이선스 질문이 불분명할 때 중지하도록 요구할 수 있습니다. 이는 "조심하세요"라는 모호한 지시보다 더 유용합니다. 에이전트에게 허용되는 작업, 금지되는 작업, 확인이 필요한 작업을 알려줍니다.
4. Give the Agent an execution-contract prompt
강력한 EasyClaw 프롬프트는 트리거, 입력, 허용된 작업, 유효성 검사 및 예상 출력을 설명합니다. 예를 들어:
Goal: Review the current crafting-trait change in my local mod project.
Inputs: The mod folder, the latest log, and the test checklist in the project docs.
Allowed actions: Read files, summarize Lua and data changes, create a dated backup,
update the test checklist, and draft a bug report.
Do not: Change game files, delete saves, publish to Steam Workshop, or overwrite source
without asking me first.
Verify: Confirm referenced files exist, identify relevant log errors, and list tests that remain.
Output: A short change summary, risk list, exact test steps, and files requiring my review.이는 일반적인 요청을 재사용 가능한 실행 계약으로 전환합니다. 에이전트는 호출할 스킬을 결정하고, 승인된 데스크톱 작업을 수행하고, 필요한 파일과 출력이 존재하는지 확인하고, 다음 단계에 유용한 보고서를 반환할 수 있습니다.
5. 반복적인 점검을 기술 및 RPA 워크플로로 전환
워크플로가 안정되면 반복되는 작업을 재사용 가능한 기술 또는 RPA 자동화로 전환하세요. "mod 프리플라이트" 워크플로는 현재 버전을 수집하고, mod 폴더를 검사하고, 변경된 파일을 릴리스 체크리스트와 비교하고, 최신 로그를 읽고, 날짜가 지정된 테스트 패키지를 만들고, 알려진 위치에 보고서를 저장할 수 있습니다. 모델은 워크플로를 설계하고 예외를 처리하는 데 사용됩니다. 반복 RPA 실행은 기록된 단계를 따르므로 일상적인 실행에서는 모델 토큰을 반복적으로 사용하지 않습니다.
각 자동화의 범위를 좁히고 검토 가능하게 유지하세요. 안전 우선 자동화는 증거를 정리하고 체크리스트를 준비합니다. 저장 내용을 자동으로 변경하거나 소스 파일을 대량 업데이트하거나 콘텐츠를 게시해서는 안 됩니다. 자동화를 즉시 중지하려면 /stop을 사용하고, 새로운 작업 컨텍스트가 필요할 때는 /reset를 사용하고, 메모리에 있는 안정적인 규칙을 삭제하지 않고 긴 프로젝트 대화를 줄이려면 /compress을 사용하세요.
6. Run and monitor work from a remote channel
데스크톱 에이전트와 승인된 원격 채널이 연결되면 컴퓨터가 없는 동안 WeChat, Feishu, DingTalk, Telegram, WhatsApp, Discord, Slack 또는 QQ에서 작업을 보낼 수 있습니다. 예: "모드 프리플라이트를 실행하고, 최신 로그를 읽고, 차단기만 보내주세요." EasyClaw은 승인된 로컬 워크플로를 실행하고 증거 또는 보고서를 해당 채널에 반환할 수 있습니다. 채널 대화에는 별도의 컨텍스트가 있으므로 Discord 명령이 데스크탑 대화에서 자동으로 기억된다고 가정하는 대신 MEMORY.md에 교차 채널 프로젝트 규칙을 저장하십시오.
Example: EasyClaw을 사용하여 프로젝트 Zomboid 모드 변경 실행
적당한 수준의 제작 품질 기능을 추가하고 싶다고 가정해 보겠습니다. 먼저, 프로젝트 Zomboid Mod 유지 관리자 에이전트에게 플레이어 값, 정확한 제한, 구성 기대치, 기능이 기존 저장을 위한 것인지 여부를 알려주세요. 에이전트는 MEMORY.md의 안정적인 프로젝트 규칙을 읽고 요청을 변경 계획으로 전환하며 주의가 필요한 소스 파일, 데이터 정의, 종속성 및 테스트 사례를 식별합니다.
계획을 승인한 후 에이전트는 로컬 파일 기술을 사용하여 지정된 프로젝트 파일을 검사하고, SOUL.md에서 허용하는 경우 날짜가 지정된 백업을 생성하고, 제안된 Lua 또는 데이터 변경 사항을 요약하고, 정리 저장 테스트 체크리스트를 준비할 수 있습니다. 그런 다음 자체 출력을 확인합니다. 참조된 파일이 존재하는지, 필요한 확인 사항이 문서화되었는지, 관련 로그 오류를 찾았는지, 여전히 사람의 검토가 필요한 작업은 무엇인지 확인합니다. 생성된 스크립트가 성공적인 모드인 것처럼 가장하는 대신 결과를 보고합니다.
다음으로, 제어된 설정에서 직접 게임 테스트를 실행합니다. 결과, 스크린샷, 로그 발췌 내용을 EasyClaw로 다시 보내세요. 에이전트는 확인된 결함을 잔액 문제 및 지연된 아이디어와 분리하고 날짜가 지정된 테스트 보고서를 업데이트하며 가장 작은 다음 조치를 생성합니다. 이 루틴이 안정화되면 동일한 시퀀스가 재사용 가능한 RPA 프리플라이트 워크플로가 될 수 있습니다. 원격 채널에서 데스크탑으로 돌아가기 전에 비행 전 보고서를 준비하도록 요청할 수 있습니다.
| 단계 | 크리에이터 액션 | EasyClaw 실행 | 검증포인트 |
|---|---|---|---|
| Define | State player value and boundaries | Reads durable rules and creates a mod brief | Is the feature focused and allowed? |
| Plan | Approve scope and permitted actions | Maps files, dependencies, risks, and tests | Are inputs, outputs, and non-goals explicit? |
| Prepare | Review proposed source changes | 파일 검사, 승인된 백업 생성, 체크리스트 초안 작성 | Do required files and reports exist? |
| 시험 | Run a controlled in-game test | 증거, 로그노트, 회귀사례 정리 | Does behavior match the acceptance criteria? |
| Iterate | Approve the next change or release | 보고서, 릴리스 노트, 반복 가능한 SOP 업데이트 | Is the next action evidence-based and safe? |
모드를 공유하기 전 Project Zomboid 모딩 체크리스트
- 모드에는 명확한 목적이 있으며 관련 없는 실험을 묶지 않습니다.
- Metadata, 식별자, 종속성 및 지원되는 빌드 정보가 정확합니다.
- Data definitions 및 Lua 파일은 현재 예상되는 형식을 사용합니다.
- 클린 저장에서 기능을 테스트하고 예상 결과를 기록했습니다.
- 첫 번째 관련 오류 또는 경고에 대한 로그를 확인했습니다.
- 저장, 다시 로드, 비활성화 설정 및 종속성 동작을 이해합니다.
- 멀티플레이어 호환성은 허용된 테스트 후에만 주장됩니다.
- Assets은 원본이거나, 허용되거나, 적절한 라이센스를 받았습니다.
- Release notes은 과장하지 않고 변경 사항, 호환성 및 알려진 제한 사항을 설명합니다.
FAQ
결론: 더 나은 프로젝트 Zomboid 모딩은 더 나은 반복에서 비롯됩니다
Project Zomboid 모딩은 통제된 반복 작업입니다. 최고의 모드는 집중된 플레이어 문제에서 시작하고, 현재 지원되는 구조를 사용하고, 가정을 명시적으로 만들고, 깔끔한 테스트, 유용한 로그 및 정직한 호환성 메모를 통해 신뢰를 얻습니다. Lua은 중요하지만 범위, 데이터 소유권, 종속성 규율 및 실패를 조사하는 반복 가능한 방법도 중요합니다.
AI는 이러한 작업에 대한 계획 및 검토 작업을 단축할 수 있으며, EasyClaw은 제작자가 브리핑, 파일 맵, 테스트 사례, 로그 노트, 피드백 및 릴리스 문서와 같이 세션 사이에 일반적으로 사라지는 컨텍스트를 유지하는 데 도움이 됩니다. 현재 Project Zomboid 참조나 게임 내 유효성 검사를 대체하지 않습니다. 이는 제작자에게 두 가지 모두에 도달할 수 있는 보다 체계적인 방법을 제공합니다. 목표는 맹목적으로 모딩을 자동화하는 것이 아닙니다. 모든 개정을 더 쉽게 이해하고, 테스트하고, 유지 관리할 수 있도록 하는 것입니다.