Godot - 시작하기
직접 해 보며 배우고 Edgegap에서 첫 전용 서버를 배포해 보세요. 이 가이드가 끝나면 비용 없이 Edgegap으로 전용 서버를 배포하게 됩니다.
✔️ 준비
시작하기 전에 반드시 Edgegap에 무료 계정을 생성하세요 (신용카드 불필요).
개발 머신에서 몇 가지 필수 항목을 구성하세요:
Docker Desktop(또는 Docker CLI) 설치
공식 소스에서 Docker Desktop을 설치하세요 (계정이 필요하지 않습니다).
설치를 완료한 후 컴퓨터를 다시 시작하세요.
Edgegap의 Godot 전용 서버 Quickstart 플러그인 설치
이 플러그인은 Godot 4.x.x 이상 버전에서 테스트되었으며 이를 지원합니다.
옵션 1) ZIP에서 설치:
ZIP을 프로젝트의
addons폴더에 압축 해제하세요.
ZIP으로 설치한 플러그인을 업데이트하려면 이전 플러그인을 삭제하고 새 ZIP으로 교체하세요.
옵션 2) 소스에서 설치:
프로젝트의 다음 위치에 플러그인 저장소를 복제하세요:
addons폴더에 압축 해제하세요.
git clone git@github.com:edgegap/edgegap-godot-plugin.gitgit으로 설치한 플러그인을 업데이트하려면 플러그인 폴더에서 명령줄을 열고 다음을 실행하세요 git pull.
Project / Project Settings / Plugins에서 새 Edgegap Servers Quickstart 플러그인을 활성화하세요. 오른쪽 패널의 Inspector 옆에 "Edgegap"라는 새 탭이 나타납니다. 나중에 패널을 닫았다가 다시 열어야 하면 Project / Tools / Edgegap에서 옵션을 찾을 수 있습니다.
⚙️ 1. 계정 연결
☑️ 로그인하고 Output에 Edgegap 플러그인과 관련된 새 오류가 없는지 확인하세요.
✅ 이제 다음 단계로 진행할 수 있습니다.
🔧 2. 게임 서버 빌드
Windows, Mac 또는 Linux 기기를 사용하더라도, 당신은 서버를 Linux 런타임용으로 빌드해야 합니다, 왜냐하면 요즘 대부분의 클라우드 제공업체(Edgegap 포함)가 Linux에서 실행되기 때문입니다. 걱정하지 마세요. 이 플러그인으로 이를 수행하는 데 Linux 지식은 필요하지 않습니다.
☑️ 플러그인이 Linux 서버 템플릿을 올바르게 설정했는지 확인하려면 Export Templates를 검증하세요.
고급 사용자 - 선택적으로 사용자 지정 내보내기 템플릿. 주의! 이로 인해 빌드가 깨질 수 있습니다.
☑️ 프로젝트에 새 bootstrap 스크립트를 추가하여 전용 서버로 자동 시작되도록 하세요. 메인 씬 아래에 새 노드를 만들고, Inspector / Script / Load 아래에서 새 스크립트를 연결하세요.
이것은 프로젝트의 필요에 맞게 확장할 수 있는 최소 템플릿 스크립트입니다.
이것은 다음을 위한 bootstrap 스크립트의 맞춤 버전입니다. netfox forest brawl 샘플.
☑️ 설정에 만족하면 다음을 누르세요 서버 빌드, 프로세스가 끝날 때까지 기다리고 Output에 새 오류가 없는지 확인하세요. 이 단계를 완료하면 다음이 생성됩니다: 프로젝트에서 다음 폴더 아래에 새 빌드가 표시됩니다: build.
✅ 이제 다음 단계로 진행할 수 있습니다.
🐋 3. 서버를 컨테이너화
개발자 팀과 함께 작업하면 코드를 공유해야 합니다. 문제가 발생했을 때 듣고 싶은 마지막 말은 “내 환경에서는 잘 돼”일 것입니다. 게임 서버는 전 세계 수천 대의 서버 머신에서 안정적으로 실행되어야 합니다.
서버를 안정적으로 만들기 위해 Docker를 사용합니다 - 운영 체제 수준까지 서버 코드의 모든 종속성이 어디서 어떻게 서버가 시작되든 항상 정확히 동일하도록 보장하는 가상화 소프트웨어입니다.
시청을 권장합니다 "로컬에 설치하지 마세요" (비디오). Docker를 사용할 때 Dockerhub를 사용할 필요는 없습니다Docker ≠ Dockerhub. Docker를 프로그래밍 엔진으로 보고 Dockerhub를 앱 스토어로 생각하세요.
☑️ 먼저 다음을 누르세요 Docker 검증 버튼을 눌러 다음을 완료했는지 확인하세요 Godot.
Docker Desktop(또는 Docker CLI) 설치
공식 소스에서 Docker Desktop을 설치하세요 (계정이 필요하지 않습니다).
설치를 완료한 후 컴퓨터를 다시 시작하세요.
☑️ 다음 옵션을 구성할 수 있습니다(또는 기본값을 유지):
이미지 이름 은(는) 서버 빌드를 출하 전에 레이블링하는, 원하는 고유 식별자입니다.
보통 게임 이름을 포함하며, 예를 들어 “my-game-server”와 같습니다.
이미지 태그 는 이미지의 특정 버전을 가리키는 식별자입니다.
“빌드 아티팩트”라는 용어는 때때로 이미지의 특정 버전을 가리킬 때 사용됩니다.
타임스탬프는 태그에 좋은 옵션입니다. 예:
2026.07.30-16.25.00-UTC.
Dockerfile 경로 는 이미지의 레시피를 사용자 지정하는 데 사용할 수 있습니다.
지금은 기본 설정을 유지하는 것을 권장합니다. 나중에 섹션에서 더 읽어볼 수 있습니다 Godot.
선택적 docker 빌드 매개변수 는 Docker에 더 세부적인 사항을 추가로 지시하는 데 사용할 수 있습니다.
지금은 기본 설정을 유지하는 것을 권장합니다. 나중에 읽어볼 수 있습니다 Docker 문서에서 더 읽어보기.
소스에서 다시 빌드 자동으로 빌드하고 컨테이너화하여 다음 빌드 속도를 높이기 위해.
☑️ 설정에 만족하면 다음을 누르세요 Docker로 컨테이너화, 프로세스가 끝날 때까지 기다리고 Output에 새 오류가 없는지 확인하세요. 이 단계를 완료하면 다음이 생성됩니다: 로컬 머신에 새 이미지가 표시됩니다. 이는 Docker Desktop의 Local(기본값) 아래 Images 탭에서 확인하거나, docker CLI에서 다음을 실행하여 확인할 수 있습니다 docker images .
✅ 이제 다음 단계로 진행할 수 있습니다.
🧪 4. 서버를 로컬에서 테스트
업로드하고 배포하기 전에(약간의 시간이 걸릴 수 있음) 서버 이미지가 제대로 작동하는지 확인하기 위해 로컬(사용자 기기)에서 배포하고 게임 클라이언트를 연결해 보겠습니다.
☑️ 다음 옵션을 구성할 수 있습니다(또는 기본값을 유지):
서버 이미지 태그 이전 단계에서 만든 것.
플러그인으로 마지막에 빌드한 태그가 기본값입니다.
☁️ 이미지 이름 앞에 나타나는 것은 이 이미지가 업로드되었음을 의미합니다.
선택적 docker run 매개변수 는 여러 포트를 노출하거나 macOS 머신에서 이미지를 실행할 때 제공할 수 있습니다.
필요한 경우 컨테이너에 여러 포트를 게시할 수 있습니다. 단순히 다음 매개변수를 추가하세요
-p {내부 포트}/{프로토콜}각각에 대해, 예를 들어-p 8080/tcp -p 7777/udp서버 포트를 게시하고 매핑하기 위해8080TCP 연결을 위한 무작위 외부 포트와 동시에 서버 포트를7777UDP 연결을 위한 무작위 외부 포트에 매핑합니다. bootstrap 스크립트에서 서버 포트 구성을 찾으세요.ARM 아키텍처 머신(macOS M1, M2, M3 등)을 사용 중이라면 선택적 docker 빌드 매개변수에 이 선택적 매개변수가 포함된 것을 볼 수 있어야 합니다:
--platform=linux/amd64.
☑️ 설정에 만족하면 다음을 누르세요 로컬 컨테이너 배포, 프로세스가 끝날 때까지 기다리고 Output에 새 오류가 없는지 확인하세요. 이 단계를 완료하면 다음이 시작됩니다: 새 컨테이너가 시작되는 개발 머신에서.
자세한 내용은 Docker Desktop / Containers 또는 Docker CLI 명령을 참조하세요 docker ps .
☑️ 이제 다음을 수행할 시간입니다 Godot Editor 게임 클라이언트를 로컬 Docker 컨테이너에 연결하여 서버 이미지가 제대로 작동하는지 확인하세요. 클라이언트 연결 정보를 찾아 다음을 입력합니다:
localhost또는0.0.0.0(대부분의 경우 동일함)을 서버 IP 대신,Docker Desktop / Containers에서 찾은 무작위 외부 포트 값.
☑️ 로컬 서버 컨테이너에 연결하여 문제없이 플레이할 수 있는지 확인한 후에는 기기의 리소스를 다른 프로그램용으로 확보하기 위해 컨테이너를 삭제할 수 있습니다 🗑️
✅ 이제 다음 단계로 진행할 수 있습니다.
☁️ 5. Edgegap에 업로드
서버를 온라인으로 배포할 시간입니다! 이제 이미지가 플레이어를 성공적으로 호스팅할 수 있으므로 이를 Edgegap에 업로드하여 전 세계 어디에서나 실행할 수 있습니다. 이 가이드에서는 Edgegap의 컨테이너 레지스트리 (이미지 저장소).
☑️ 다음 옵션을 구성할 수 있습니다(또는 기본값을 유지):
애플리케이션 이름 Edgegap에서는 이미지 이름과 같게 하거나 사용자 지정할 수 있습니다.
지금은 이미지 이름을 복사하도록 선택했습니다.
애플리케이션 버전 Edgegap에서는 태그와 같게 하거나 사용자 지정할 수 있습니다.
타임스탬프는 앱 버전 이름에 좋은 옵션입니다. 예:
2024.01.30-16.50.20-UTC.여러 애플리케이션 버전이 동일한 이미지 태그를 가리킬 수 있습니다. 예:
v1.1.0및dev.자세히 알아보기 앱 및 버전 나중에.
서버 이미지 단계에서 Godot.
컴퓨터에 저장된 모든 이미지 이름과 태그를 찾으려면 Docker Desktop / 이미지.
☑️ 설정에 만족하면 다음을 누르세요 이미지 업로드 및 앱 버전 생성, 프로세스가 끝날 때까지 기다리고 Output에 새 오류가 없는지 확인하세요.
☑️ 이제 다음 위치로 이동합니다 대시보드, 여기에서 선택적 설정을 구성할 수 있습니다. 이 단계를 완료하면 다음이 생성됩니다: 새 애플리케이션 버전이 생성되고, 그리고 빌드 아티팩트가 태그 지정되어 Edgegap의 Container Registry에 업로드됩니다.
애플리케이션 버전 Edgegap에서는 태그와 같게 하거나 사용자 지정할 수 있습니다.
타임스탬프는 앱 버전 이름에 좋은 옵션입니다. 예:
2024.01.30-16.50.20-UTC.여러 애플리케이션 버전이 동일한 이미지 태그를 가리킬 수 있습니다. 예:
v1.1.0및dev.자세히 알아보기 앱 및 버전 나중에.
☑️ 이제 새 애플리케이션 버전의 포트를 정의하라는 메시지가 표시됩니다. 단계 Godot (기본값은 7777).
✅ 이제 다음 단계로 진행할 수 있습니다.
🚀 6. 클라우드에 배포
이 가이드의 마지막 단계로, 이 단계를 완료하면 전 세계 어디에서든 플레이어가 접속할 수 있는 Edgegap 클라우드에 서버가 배포됩니다.
☑️ 애플리케이션과 버전을 선택하세요 배포를 위해 이전 단계에서.
☑️ 준비가 되면, 누르세요 클라우드에 배포, 도달할 때까지 기다리세요 배포. 이 단계를 완료하면 결과적으로 새 배포가 시작됩니다 귀하의 Edgegap 계정에서.
☑️ 콘솔 출력에 새로운 오류가 없는지 확인하세요. 또한 다음이 배포 오류를 표시하지 않는지 및 귀하의 배포 가(이) vCPU 또는 메모리의 100% 자원 사용을 나타내지 않는지 확인하세요. 그렇지 않으면 새 플레이어 연결이 거부되거나 서버가 재시작 루프에 갇힐 수 있습니다. 문제 해결 단계는 아래를 참고하세요.
☑️ 이제 마지막 테스트를 수행하고 Godot Editor 게임 클라이언트를 클라우드 배포에 연결할 것입니다. 클라이언트 연결 정보를 찾아 다음을 입력합니다:
호스트 URL 서버 IP를 가리키는,
외부 포트 에 매핑되는 서버의 내부 리슨 포트.
Edgegap 클라우드에서 배포의 외부 포트는 임의로 선택되어 잠재적 공격자(해커)가 피해를 일으키기 전에 속도가 느려지고 탐지되도록 합니다.
테스트 시 VPN 비활성화 보다 현실적인 조건을 위해 그리고 저지연 배포를 받으려면.
☑️ 배포에 문제없이 연결할 수 있음을 확인하고 테스트를 마쳤다면, 배포 중지 다음 빌드를 위해 계정의 용량을 확보하려면.
문제가 발생한 경우, 배포의 대시보드 로그를 검사하세요.
문제를 해결할 수 없다면, 저희는 커뮤니티 디스코드 에서 도와드릴 수 있으며 기꺼이 지원하겠습니다.
🙌 Edgegap에서의 첫 배포를 축하합니다! 더 알아보고 싶다면 계속 읽어보세요.
👉 다음 단계
클라이언트/서버 구성이 작동하면, 반드시 프로젝트 복사본을 저장하세요 (git과 같은 버전 관리 소프트웨어를 사용하여) 문제가 발생했을 때 항상 작업 내역을 추적할 수 있도록.
서버 수명주기 및 검색 가능성과 관련된 주제를 더 알아보려면 계속 읽으세요.
도움이 필요하시면 디스코드를 통해 문의해 주세요. 실시간 게임 지원은 저희의 티켓 시스템.
배포 중지
매치가 끝나면(또는 플레이어가 나가면), 비용을 절감하기 위해 배포를 중지할 수 있습니다. 비어 있거나 부분적으로만 채워진 상태로 실행하면 불필요하게 비용이 증가할 수 있습니다!
Godot 스크립트 예제는 곧 제공될 예정입니다!
연결하세요 엔드포인트 저장소 배포 로그를 저장하려면, 그렇지 않으면 삭제됩니다!
주입된 변수
주입된 환경 변수에 접근하여 배포 ID, 서버 IP 주소, 서버 위치 등 유용한 정보를 읽을 수 있습니다. 각 배포에는 자동으로 다음이 포함됩니다:
Godot 스크립트 예제는 곧 제공될 예정입니다!
세션 자동화
배포를 수동으로 시작하고 URL과 포트를 붙여넣는 것만으로는 라이브 게임에 충분하지 않습니다.
다음 중 하나를 사용해 세션 관리 및 필요에 따른 확장을 위한 인기 게임 흐름을 자동화하세요:
짧은 라운드
온디맨드 매치
실력 등급 및/또는 사용자 지정 규칙
지속형 또는 라운드
소셜 지역 허브
자동 할당 및/또는 사용자 지정 검색
사용자 지정 백엔드:
라이브 게임 마이그레이션
Godot 스크립트 예제는 곧 제공될 예정입니다!
사용 최적화
서버 사용을 최적화하는 데 도움이 되는 몇 가지 팁:
틱 레이트가 높을수록 업데이트가 더 많아지고, 더 많은 CPU 사용량과 데이터 이그레스가 필요합니다.
Godot의 기본값은 초당 60틱이며, 빠른 템포의 슈팅 게임이나 지연 시간에 매우 민감한 게임에 잘 맞습니다. 다른 장르는 30Hz 또는 심지어 15Hz로도 충분할 수 있습니다.
더 높은 틱 레이트의 숨은 비용은 데이터를 (언)패킹하고, 서버 권한 속성과 절차를 다시 계산하는 데 필요한 더 많은 CPU 사이클(초당)입니다. 매치당 플레이어 수가 많거나(10명 이상), 충돌체가 있는 노드가 많거나, 복잡한 물리 시뮬레이션, 또는 봇 적/아군이 많은 게임이라면 신중하게 접근하세요.
네트코드 설정에서 다양한 틱 레이트로 게임 반응성을 테스트하세요. ENET의 경우 Project Settings / Physics / Common / Physics Ticks Per Second을 참고하세요.
올바른 네트워킹 프로토콜은 어떻게 선택하나요? 먼저 작동하게 만들고, 그다음 더 좋게 만드세요.
Godot의 내장 ENET과 기본 UDP 프로토콜은 가장 넓은 범위의 장치와 사용 사례 전반에서 성능과 호환성을 제공하는 훌륭한 기본 선택입니다.
일부 게임은 TCP, WS, WebRTC 또는 다른 프로토콜을 실험하고 싶을 수 있습니다. 이는 모바일 기기 및 콘솔과의 연결 안정성을 개선할 수 있으며, 특히 공용 네트워크(셀룰러, 기업망, e-카페, 호텔 와이파이 등)에서 효과적일 수 있지만, 분명 추가 개발 노력이 필요합니다. 이것이 대상 사용자에게 정말 중요한지 스스로에게 물어보세요.
중요한 업데이트가 우선적으로 전달되도록 여러 프로토콜을 병행하는 것은 일부 장르(예: MMO)에서 플레이어 경험을 개선할 수 있지만, 추가 개발 노력이 많이 들고 프로젝트에 엄청난 복잡성을 더할 수 있습니다.
전투는 신중히 선택하세요, 게임 개발에는 도전 과제가 부족하지 않습니다.
이미지 사용자 지정
또한 빌드 크기 최적화, 불필요한 종속성, 또는 더 복잡한 시작 프로세스 때문에 이미지에 더 많은 제어가 필요한 사용자를 위해 자체 Dockerfile 추가도 지원합니다. 단계에서 사용자 지정 Dockerfile의 경로를 선택적으로 제공할 수 있습니다 Godot. 이제 몇 가지 "직접 해보기" 팁과 모범 사례를 공유하겠습니다.
항상 작동하는 서버 빌드로 작업하고 있는지 확인하세요.
문제가 커스텀 Dockerfile과 관련되었다고 가정하기 전에, Unity 서버 빌드를 시작할 수 있는지와 Unity의 빌드 과정에서 예외나 오류가 발생하지 않았는지 확인하세요.
업로드하기 전에 항상 로컬에서 테스트하세요.
이미지를 로컬에서 테스트하면 업로드가 끝날 때까지 기다리는 시간을 크게 절약할 수 있습니다. 또한 Edgegap 리소스를 필요로 하지 않기 때문에 완전히 무료입니다 ✨.
로컬에서 테스트할 때 내부 포트를 올바르게 설정했는지 확인하세요:
기본 사항을 숙지했는지 확인하세요. 모든 Dockerfile에는 몇 가지 필수 명령이 필요합니다:
FROM {image}는 베이스 이미지입니다. Unity 프로젝트의 경우 보통 장기 지원되는 Linux를 사용하지만, 어떤 Linux 기반 베이스 이미지라도 괜찮습니다. 이러한 이미지는 보통 dockerhub에 저장된 공개 이미지입니다. Dockerfile 참조는 여기. Dockerfile 참조는 여기.COPY {source} {destination}호스트 머신의 리눅스 서버 빌드를 이미지 내부로 복사하여 나중에 시작할 수 있게 합니다. Dockerfile 참조는 여기.USER {user}는 다음에 와야 합니다 useradd (ubuntu) 명령 또는 이에 상응하는 것으로, 모든 것을root로 실행하지 않는 것이 더 안전합니다. Dockerfile 참조는 여기.CMD {command}는 마지막 줄이 될 것이며, 대부분StartServer.sh또는 일종의 시작 스크립트를 호출하여 모든 설정이 완료된 후 서버가 올바르게 초기화되도록 합니다. Dockerfile 참조는 여기.다음을 사용하지 마세요
VOLUME- 이렇게 하면 Edgegap에서 로컬 스토리지를 마운트할 수 없습니다. 대신 우리의 Endpoint Storage 기능을 고려하고 S3 버킷을 사용하세요. 자세한 내용은 Endpoint Storage,EXPOSE 7777/UDP는 필요하지 않습니다! 이것은 실제로 컨테이너 외부에서 내부 서버 포트를 사용 가능하게 하지 않으며, 개발자에게 주는 힌트일 뿐이고 포트는로컬에서 테스트할 때
docker run <image> -p 7777/udp,로 게시되어야 하거나 Edgegap Port Mapping.
매개변수 선언은 가능한 늦은 시점까지 지연하세요. 서버 빌드 시간이 길기 때문에 구성 가능성(Configurability)이 조합 가능성(composability)보다 우선입니다. 이 접근 방식을 Dockerfile 명령에 적용하여 더 빠르게 빌드하고 업로드하세요.
시나리오: 배포 단계, 버전, 게임 모드, 맵, 서버당 플레이어 수, 백업 빈도 등과 같은 매개변수를 정의해야 할 때.
나쁜 해결책: 매개변수 조합마다 별도의 이미지를 만드는 것. 이 방법은 이미지를 재빌드하는 데 모든 시간을 소비하게 하며 이로 인한 이점은 거의 없습니다.
더 나은 해결책 - 구성 매개변수를 적시에 대체하세요:
배포 매개변수 - 배포 직전에 제공되는 것 - 매치메이킹 선택자는 환경 변수로 전달되거나, 배포 시점에 환경 변수를 전달하는 커스텀 세션 관리 시스템 등,
버전 매개변수 - 앱 버전의 모든 배포에 공유되는 것 - 배포 단계, 아티팩트 태그, 서드파티 비밀 및 엔드포인트 등; 그리고
하나의 단일 이미지 - 시작 시 모든 구성 옵션을 포함하고 로드합니다.
Edgegap 배포에서 데이터베이스를 실행하지 마세요.
Edgegap 배포는 장기 실행 프로세스를 위한 것이 아니며, 장기간 실행 후 별도의 통지 없이 종료될 수 있습니다. 이러한 방식으로 실행되는 데이터베이스(분산형일지라도)는 종료되어 되돌릴 수 없는 데이터 손실을 초래할 수 있습니다. 데이터베이스가 필요하다면 서드파티 DBaaS를 고려하세요.
다음 사용을 고려하세요 관리형 클러스터(Managed Clusters) 데이터베이스 및 장기 실행 서비스 호스팅을 위해.
마지막 업데이트
도움이 되었나요?