이 페이지는 다른 엔진에서 온 엔지니어들이 처음 몇 주 동안 가장 자주 필요로 하는 Roblox의 기본 사항을 다룹니다. 각 섹션은 핵심 아이디어를 설명하고 자세한 가이드에 대한 링크를 제공합니다.
일반 용어
- 게임: 플레이어가 게임의 시작 장소를 통해 참여하는 장소의 모음입니다. 데이터 저장소, 비밀, 분석 및 게임 내 구매는 모두 게임에 국한되며, 이를 경험 또는 유니버스라고도 부를 수 있습니다.
- 장소: 게임 내의 장면 또는 구역으로, 고유한 데이터 모델을 가지고 있습니다. 각 서버는 하나의 장소를 실행하며, 플레이어를 장소 간에 이동시키려면 텔레포트가 필요합니다.
- 자산: 이미지, 메쉬, 사운드 또는 애니메이션과 같은 전 세계적으로 고유한 자산 ID를 가진 업로드된 콘텐츠입니다. 모델 및 애니메이션과 같은 일부 자산 유형은 제자리에서 업데이트할 수 있지만, 이미지 및 사운드와 같은 다른 자산은 새 자산을 업로드해야 합니다.
- 스크립트: 데이터 모델에 인스턴스로 저장된 코드입니다. 스크립트를 복사하면 전체 독립 복사가 생성되며, 소스 파일에 대한 참조가 아닙니다.
게임과 장소의 관계에 대한 자세한 내용은 게임과 장소를 참조하세요.
데이터 모델 구조
데이터 모델은 장소를 구성하는 인스턴스의 트리입니다. 최상위 서비스는 각각 특정 목적과 복제 동작을 가지고 있습니다:
| 서비스 | 여기에 속하는 것 |
|---|---|
| Workspace | 장소의 단일 3D 세계입니다. Studio에서 이를 편집할 때, 서버의 세계 뷰를 편집하며, 그 일부는 각 클라이언트에 복제됩니다. |
| ReplicatedStorage | 클라이언트와 서버가 항상 필요로 하는 모듈, 클라이언트 코드, 효과 및 기타 인스턴스입니다. |
| ReplicatedFirst | 다른 모든 것보다 먼저 클라이언트에 복제되는 콘텐츠로, 일반적으로 로딩 화면입니다. |
| ServerStorage | 클라이언트가 지속적으로 접근할 필요가 없는 서버 전용 인스턴스입니다. 예를 들어, 작업 공간에 교체할 맵이 있습니다. |
| ServerScriptService | 서버 전용 스크립트 및 모듈입니다. |
| StarterGui | ScreenGuis 및 각 플레이어에게 복사되는 기타 UI입니다. |
| StarterPlayer | 플레이어와 캐릭터를 위한 스크립트 및 설정입니다. 그러나 더 큰 프로젝트는 일반적으로 코드를 ReplicatedStorage에 보관합니다. |
탐색기의 계층 구조는 주로 조직적입니다:
- 부품은 부모에 대한 변환이 아닌 월드 스페이스 변환을 사용합니다. 부품을 서로 연결하려면 제약 조건을 사용해야 하며, 가장 일반적으로 WeldConstraint를 사용합니다. 자세한 내용은 기계적 제약 조건을 참조하세요.
- Attachments는 부모 부품에 상대적으로 위치하기 때문에 예외입니다.
- Models는 전체 모델을 이동하고 회전시키기 위한 기준점으로 PrimaryPart를 사용합니다.
스크립팅 모델
대부분의 경우, 두 가지 종류의 스크립트만 필요합니다:
- 다른 스크립트가 require()로 로드하는 값을 반환하는 ModuleScript입니다. 모듈은 공유 라이브러리, 함수 및 데이터를 위해 사용합니다.
Legacy 실행 컨텍스트와 LocalScripts는 피하세요. 이들의 동작은 배치된 위치에 따라 달라지므로 코드를 조직하기가 더 어려워집니다. 권장 위치에 대한 내용은 스크립트 유형 및 위치를 참조하세요.
서버 스크립트는 클라이언트에 복제되지 않습니다. 모듈은 클라이언트가 접근할 수 있는 컨테이너에 있을 때 클라이언트에 복제됩니다. 서버 전용 모듈은 ServerScriptService 또는 ServerStorage에 보관하세요.
네트워킹 및 복제
Roblox는 클라이언트-서버 모델을 사용합니다:
- 서버가 인스턴스에 대해 수행하는 변경 사항(속성, 속성 및 태그 포함)은 클라이언트에 자동으로 복제됩니다.
- 엔진은 서버와 클라이언트 간에 물리 시뮬레이션을 분배합니다. 클라이언트는 자신이 소유한 부품을 시뮬레이션하고 위치와 속도를 서버에 전송합니다.
클라이언트와 서버 간의 통신을 위해 원격 이벤트 및 콜백을 사용하세요:
- RemoteEvent와 RemoteFunction은 신뢰할 수 있고 순서가 보장됩니다.
- UnreliableRemoteEvent는 신뢰할 수 없고 순서가 보장되지 않으며, 메시지가 누락되어도 문제가 되지 않는 빈번한 업데이트에 사용됩니다.
- 원격은 기본적으로 보안되지 않습니다. 항상 서버가 클라이언트로부터 받는 데이터를 검증하세요.
서버 권한
경쟁 게임의 경우, 서버 권한은 서버가 물리학 및 게임 플레이에 대한 권한을 가지며, 클라이언트는 자신의 캐릭터와 인근 물리 객체를 예측합니다. 클라이언트가 잘못 예측하면 롤백하고 다시 시뮬레이션합니다.
입력
입력 작업 시스템으로 입력을 처리합니다. InputContext 인스턴스에서 점프 또는 스프린트와 같은 작업을 정의하고, InputBinding 인스턴스를 사용하여 키, 버튼 및 터치 컨트롤에 바인딩합니다. 서버 권한을 사용할 때, 각 InputContext는 엔진이 소유한 플레이어를 알 수 있도록 Player의 자손이어야 합니다. 한 가지 접근 방식은 ReplicatedStorage에 컨텍스트를 보관하고 서버 스크립트에서 각 플레이어에게 복제하는 것입니다. 자세한 내용은 입력 작업을 참조하세요.
스트리밍
인스턴스 스트리밍은 플레이어가 세계를 이동할 때 작업 공간의 일부를 각 클라이언트에 로드하여 모든 장치에서 로드 시간과 메모리를 낮춥니다.
- ReplicatedStorage의 인스턴스는 플레이어가 참여할 때 전체가 복제되며, 스크립트가 실행되기 전에 안전하게 접근할 수 있습니다.
- 작업 공간의 인스턴스는 스트리밍되어 들어오고 나갑니다. 클라이언트 코드는 아직 로드되지 않은 인스턴스를 처리해야 합니다.
- 제약 조건으로 연결된 인스턴스는 함께 스트리밍되어 물리학을 안정적으로 유지합니다.
각 Model은 스트리밍 방식을 제어하는 ModelStreamingMode를 가지고 있습니다:
| 모드 | 동작 | 적합한 경우 |
|---|---|---|
| Default | 부품이 개별적으로 스트리밍되므로 모델이 부분적으로 로드될 수 있습니다. | 정적 환경 조각 |
| Atomic | 부품 중 하나가 필요할 때 전체 모델이 한 번에 스트리밍됩니다. | 캐릭터, 차량 및 기타 개별 동적 객체 |
| Persistent | 항상 스트리밍되고, 절대 스트리밍되지 않습니다. | 항상 표시되어야 하는 로비, 메뉴 및 랜드마크 |
| PersistentPerPlayer | Model:AddPersistentPlayer()로 추가한 플레이어에게는 지속적이며, 다른 모든 사람에게는 원자적입니다. | 일부 플레이어가 항상 필요로 하는 콘텐츠 |
텍스처, 메쉬 및 오디오와 같은 자산도 런타임에 스트리밍됩니다. 이미지는 처음에 낮은 해상도로 로드된 후, 장치와 화면에서의 크기에 따라 개선됩니다.
데이터 지속성
DataStoreService는 세션 간에 플레이어 데이터를 저장합니다. API는 저수준이므로, 저장 시스템을 설계하기 전에 데이터 저장소와 플레이어 데이터 및 구매를 읽어보세요. 이 가이드는 비율 제한, 세션 잠금 및 안전한 구매 처리와 같은 일반적인 함정을 다룹니다.
데이터 저장소는 게임에 국한됩니다. 테스트 데이터를 프로덕션에서 제외하려면 개발을 위해 별도의 게임을 사용하세요. 자세한 내용은 환경을 참조하세요.
일반 작업 해결
인스턴스 간 행동 재사용
복사된 스크립트는 독립적인 복사본이므로, 필요한 모든 인스턴스에 동일한 스크립트의 복사본을 넣는 것을 피하세요. 대신, CollectionService로 인스턴스를 태그하고, 모든 태그된 인스턴스에 행동을 부착하는 하나의 스크립트를 ModuleScript로 작성하세요.
사용자 정의 캐릭터 사용
캐릭터는 플랫폼 아바타, 사용자 정의 외형의 플랫폼 리그 또는 완전히 사용자 정의된 리그를 사용할 수 있습니다. 기본 스폰 시스템을 유지하되 캐릭터를 교체하려면, StarterPlayer에 StarterCharacter라는 이름의 모델을 배치하세요.
기본 제어 스크립트 재정의
Roblox는 각 플레이어에게 기본 카메라 및 제어 스크립트를 추가합니다. 이를 교체하려면:
- Workspace.PlayerScriptsUseInputActionSystem을 활성화하여 기본 플레이어 스크립트를 StarterPlayer 아래로 이동합니다.
- 기본 카메라 및 제어 스크립트가 추가되지 않도록 StarterPlayer.CreateDefaultPlayerModule을 false로 설정합니다.
- 자신의 카메라 및 제어 스크립트를 추가합니다.
셰이더와 유사한 효과 만들기
Roblox는 사용자 정의 셰이더를 지원하지 않습니다. 대신:
- 발광 표면을 위해 SurfaceAppearance 또는 Neon 재료를 사용하세요.
- 교차 효과를 위해 ForceField 재료를 사용하세요.
- 특별한 경우에는 EditableImage 및 EditableMesh로 동적 텍스처와 기하학을 생성하세요.
성능
Roblox의 성능은 주로 추가하는 콘텐츠와 각 프레임에서 스크립트가 소요하는 시간에 따라 달라집니다. 목표 하드웨어에서 정기적으로 테스트하고, 장면 복잡성(삼각형, 드로우 호출 및 동적 조명), 물리학, 복제 및 프레임당 스크립트 시간에 대한 예산을 조기에 설정하세요. 대부분의 성능 문제는 잘못 구성된 콘텐츠에서 발생하며, 이를 늦게 수정하는 것은 자산을 재작업해야 함을 의미합니다.
- 자동 품질: 대부분의 플레이어는 자동 그래픽 품질을 사용하며, 이는 10단계로 나뉩니다. 프레임 속도를 유지하기 위해 레벨이 떨어지면 엔진은 렌더 거리, 기하학 품질(세부 수준 및 SLIM), 음영 품질, 조명 품질, 그림자, 입자 방출 및 스트리밍 반경을 낮춥니다. 드로우 거리는 500 스터드 이하로 떨어지지 않으며, 레벨 4 이하에서는 그림자가 꺼지고, 지형 물과 빔은 모든 레벨에서 동일하게 보입니다. Roblox는 이러한 값을 지속적으로 조정하므로 정확한 숫자를 기준으로 설계하지 마세요. 미리 보려면 Studio 설정에서 편집기 품질 수준을 변경하고, 가장 낮은 수준과 가장 높은 수준에서 테스트하세요. 자세한 내용은 그래픽 품질 수준을 참조하세요.
- 텍스처 스트리밍: 텍스처는 메모리 예산과 화면 크기에 맞게 자동으로 스트리밍되고 스케일됩니다.
- 오클루전 컬링: 엔진은 다른 객체 뒤에 숨겨진 부품, 메쉬 및 지형에 대한 드로우 호출을 자동으로 건너뜁니다. 벽 및 기타 시야 차단기로 레벨을 구조화하면 장면 복잡성을 관리할 수 있습니다. 벽 안에 간단한 숨겨진 블록 부품을 사용하면 상세한 메쉬에 의존하는 것보다 오클루전 테스트가 더 저렴해집니다. 드로우 호출을 줄이는 더 많은 방법은 렌더링을 참조하세요.
- 스크립팅: Luau는 복잡하고 동적인 게임 플레이 코드를 처리할 만큼 빠릅니다. 가비지 수집을 피하거나 객체를 풀링할 필요가 없으며, 런타임에 인스턴스를 생성하는 것은 빠릅니다.
- 조명: 장면은 많은 조명을 사용할 수 있습니다. Roblox는 장치에 따라 조명 품질을 자동으로 조정하며, 복잡한 장면에서는 더 저렴한 조명 경로로 되돌아갑니다.
문제를 측정하고 수정하는 도구에 대한 내용은 성능 최적화를 참조하세요.
도구 및 AI
- 외부 편집기: VS Code 또는 스크립트 동기화 또는 Rojo가 있는 다른 편집기를 사용하세요. 유형 검사 및 린트를 위해 Luau 언어 서버와 selene 린터를 추가하세요. 팀 설정에 대한 내용은 파일 기반 워크플로 비교를 참조하세요.
- Studio MCP 서버: 대부분의 전문 개발자는 터미널이나 편집기에서 코딩 에이전트와 같은 자신의 AI 도구 및 에이전트 하네스를 사용하고 싶어할 것입니다. Studio MCP 서버는 이러한 도구를 Studio에 연결하여 열려 있는 세션에서 직접 빌드하고 테스트할 수 있도록 합니다.
- 어시스턴트: 어시스턴트는 코드를 작성하고 빌드하는 데 도움을 주는 Studio의 내장 AI 도우미로, 자신의 도구를 설정하지 않고 AI의 도움을 받고 싶을 때 유용합니다.