로블록스 스튜디오 작업공간

안녕하세요

 

 

이번 글 에서는, 로블록스 스튜디오의 기본 환경인 탐색기의 작업 공간에 대해서 작성하고자 합니다.

 

로블록스를 만들기 위해서는 위와 같은 '로블록스 스튜디오' 공간이 필요합니다.

 

또한 이 공간이 필요하다는것은, 이와 친숙해져야 한다는 것을 의미합니다.

 

 

이 중 오늘 다룰 주제는 작업공간 입니다.

 

만일 본인의 언어에 맞는 환경이라면 하나씩 눌러보면서 파악을 할 순 있지만

 

이 작업공간은 처음에 어디서부터 건드려야 하는지 감이 안 잡혀서 이곳저곳 찾아보곤 했었습니다.

 

 

모든 것을 다루진 않고, 기본 적인 초기에 필요한 기본적인 공간 정보 들만 다루고 

 

나머지는 차차 글을 작성해 나가며 필요시 공간 소개를 하도록 하겠습니다.

 

 

가장 먼저 'Workspace'

 

게임의 3D 환경을 구성하는 모든 오브젝트가 포함된 영역이라고 보시면 됩니다.

 

쉽게 말해 로블록스 스튜디오에선 기본 도형을 Part라고 부르지만, 유니티로 예를 들면 오브젝트나 프리팹, 모델 등이 보이게 될 한 '씬'이라고 보시면 됩니다.

 

또한 이 Worspace는 플레이어 간 공유가 된다고 보시면 되며, 로블록스 같은 경우에는 로컬과 서버의 개념이 존재합니다.

이 부분은 다른 글에서 보다 더 상세히(?) 다루도록 하겠습니다.

 

 

다음은 'Players'입니다.

 

이 영역은 게임에 접속한 플레이어의 정보를 관리하는 서비스라고 보시면 됩니다.

 

게임을 플레이한 후 Players의 하위를 열어 보시면

 

다음과 같은 모습을 볼 수 있습니다.

 

 

다음은 'ReplicatedStorage'라는 영역인데요

 

서버와 클라이언트 간에 데이터를 공유할 수 있도록 도와주는 저장소입니다.

 

만일 로블록스 스튜디오를 처음 다뤄보시는 분이라면 귀에 안 들어올 수 있습니다.(당연합니다)

 

이 부분도 로컬/서버 개념을 다루는 글에서 함께 다루도록 하겠습니다.

 

단순히 ' 서버와 클라이언트 간에 데이터를 공유할 수 있도록 도와주는 저장소'이다

 

로 알고 있으면 좋을 것 같습니다.

 

 

다음은 ' ServerScriptService'입니다.

 

서버에서만 실행되는 스크립트를 저장하는 공간입니다.

 

위에 로컬/서버를 나눴는데요, 이 중 서버 스크립트를 보편적으로 저장하는 공간이라 보시면 됩니다.

 

 

다음은 ' StarterGui'입니다.

 

이름에서도 알 수 있듯이 GUI가 저장되는 공간입니다.

 

이 영역은 로컬 스크립트를 저장할 수도 있는 공간이라고 보시면 됩니다.

 

---

 

현재 5가지 정도만 다뤄 보았는데요. 몇 차례 언급된 로컬/서버 개념을 간략하게 말하자면

 

로컬 = 클라이언트

서버 = 전체

 

라고 보시면 되는데요

 

조금 더 풀어서 쓰자면

 

로컬 = 플레이어 개별 화면에서만 보이거나 작동해야 하는 기능

서버 = 모든 플레이어에게 공통적으로 적용되는 기능

 

이라고 보시면 됩니다.

 

예를 들어 A라는 버튼을 상호작용하여 UI가 팝업 되는 기능을 만들었다고 가정하겠습니다.

 

이러한 부분은 로컬 스크립트에서 작성을 해야 합니다.

 

만일 서버 스크립트에서 작성을 하신다면, 1번 플레이어가 A라는 버튼을 상호작용 하여 UI가 팝업 될 시

 

기타 2~... 숫자의 플레이어 모두에게 뜨는 불상사가 발생하게 됩니다.

 

 

물론! 서버 스크립트에서 신호를 받고 로컬 플레이어를 특정 지어서

로컬로 신호를 보내주게 한다던가 등 방안들은 존재하지만!

 

보편적으로 이러한 개별적 UI 기능은 로컬 스크립트에서 작성을 하게 되고,

 

특정 파트를 움직여서 모든 플레이어에게 보이게 만들어야 한다던가, 무언갈 달성하면 모든 이들에게 알림을 준다던가 등

 

공통적으로 적용되는 기능을 구현할 때에는 서버스크립트로 관리를 하게 됩니다.

 

"

로컬 스크립트 = 클라이언트 전용

서버 스크립트 = 서버 전용

 

로컬 스크립트 = 개인화된 화면 요소나 동작

서버 스크립트 = 모든 플레이어에게 영향

"

 

정도로 우선 알고 계시면 좋을 것 같습니다.

 

---

 

다음과 같이 워크스페이스 하위엔 기본으로 오브젝트들이 구성되어 있습니다.

 

카메라 : 플레이어가 보는 시점을 제어하는 오브젝트

터레인 : 게임의 지형을 만드는 데 사용되는 오브젝트

스폰로케이션 : 플레이어가 게임에 리스폰될 때 위치

베이스플레이트 : 기본 맵 그라운드 오브젝트

베이스플레이트

 

 

다음은 기본 도형인 Part를 만들고 그 하위에 Part를 둔 캡처사진입니다.

 

 

여기서 말하고자 하는 것은 이 Workspace에 스크립트에서 접근을 할 때

 

이름과 경로가 무조건 일치해야 한다는 것입니다.

 

다음 사진을 보겠습니다.

 

 

Workspace 하위에 있는 오브젝트를 찾는 방법입니다.

 

이렇듯 각 이름을 스크립트상에서 똑같이 선언해 주기에 단순히 Part라고 지으면 무슨 파트인지 한눈에 알아보기가 힘들어서, 초기 Workspace 구성 단계에서 계층구조와 이름을 명확하게 해 줄 필요가 있습니다.

 

또한

 

하나는.으로 검색을 하였고 또 다른 하나는 WaitForChild로 검색을 하였습니다.

 

결과적으로 두 기능은 모두 Workspace/Part/Part를 찾는 것은 동일하나 약간의 차이가 있습니다.

 

 

Part.Part 같은 경우에는, 이 오브젝트가 즉시 존재한다고 가정하고 접근을 하기에

 

로딩이 지연되거나 혹은 리소스가 많이 들게 될 경우 오류를 발생하게 됩니다.

 

 

반대로 WaitForChild 같은 경우는 오브젝트가 로드될 때까지 스크립트가 잠시 대기를 하게 된다고는 나와있지만 약 10초 정도 지나도 오브젝트를 찾지 못하면 경고를 로그로 표시하게 됩니다.

 

속도 면에서는 Part.Part 가 빠르며, 보다 안전한 것은 WaitForChild 이기에

 

각 상황에 맞게, 현재 프로젝트에 맞게 사용을 하는 것을 추천드리며

 

현재 글에서는 rua 스크립트를 다룰 목적이 아니기에 여기서 마치겠습니다.

 

 

전하고 싶었던 말을 요약하자면

 

1. Workspace 하위에 계층구조와 이름을 명확히 해야 합니다.

2. 스크립트로 작성한 뒤에 Workspace 하위 경로를 수정하게 되면 이를 찾았던 스크립트를 전부 수정해 줘야 합니다.

 

 

약간의 팁?으로 같은 연관 오브젝트의 이름을 선언할 때 뒤에 인덱스를 붙여주면 조금 수월하게 저장을 할 수 있습니다.

 

예를 들어 Workspace 하위에 target1, target2, target3... target100까지 있을 경우

 

 

이를 관리할 테이블을 만들고,

for문 1~100까지 "target" + index를 저장해 주면 많은 수고를 덜 수 있습니다.

 

 

(아마 그러진 않으시겠지만...)

전.. 하나하나 저장하려고 했던 기억이 있기에.... 생각나서 적게 되었습니다.

 

 

더 생각나는것들이 많은데... 이번 글의 주제가 벗어나기에, 오늘은 이만 마치도록 하겠습니다.

 

 

감사합니다.