첫 프로젝트에서 익힐 순서
아래 순서대로 한 번씩 직접 만져보면 이후 튜토리얼이나 코드 예제를 봤을 때 어디에 넣어야 하는지 이해하기 쉬워집니다.
1. 먼저 Explorer와 Properties 위치를 익힙니다
Studio에서 무엇을 선택했는지, 그 객체가 어디에 들어 있는지, 어떤 속성을 바꾸는지가 기본입니다. Explorer는 게임 안의 객체 구조를 보고, Properties는 선택한 객체의 값을 수정하는 곳입니다.
처음에는 Workspace 안에 Part 하나를 만들고 크기, 위치, Anchored, CanCollide 같은 속성을 직접 바꿔보세요. 코드를 쓰기 전에 객체가 어떻게 구성되는지 알아야 스크립트가 어떤 대상을 찾는지도 이해할 수 있습니다.
2. 맵은 작은 방 하나부터 만듭니다
처음부터 도시나 타워디펜스 전체 맵을 만들면 배치와 스크립트가 섞여 문제를 찾기 어렵습니다. 바닥, 벽, 스폰 위치 정도만 있는 작은 테스트 공간을 먼저 만들고 기능이 정상 동작한 뒤 확장하는 편이 좋습니다.
3. Script, LocalScript, ModuleScript를 처음부터 섞지 않습니다
초보 단계에서는 “이 코드를 어디에 넣어야 하는지”가 가장 큰 혼란입니다. 서버에서 모든 플레이어에게 공통으로 적용돼야 하는 로직과, 한 플레이어의 화면이나 입력처럼 클라이언트에서 처리할 내용을 구분해야 합니다.
- Script: 서버에서 처리할 게임 규칙, 적 생성, 공용 상태 등에 사용합니다.
- LocalScript: 플레이어 입력, 카메라, 개인 UI처럼 각 클라이언트에서 처리할 내용에 사용합니다.
- ModuleScript: 여러 스크립트에서 재사용할 함수나 데이터를 정리할 때 사용합니다.
처음 프로젝트에서는 Script 하나로 파트 색을 바꾸거나 접촉 이벤트를 처리해본 뒤 LocalScript와 RemoteEvent로 넘어가세요.
4. Output 창을 항상 같이 봅니다
게임이 “안 된다”고 느껴도 실제로는 코드가 실행됐지만 객체 이름이 틀렸거나 nil 오류가 난 경우가 많습니다. Play 테스트를 시작한 뒤 Output에 빨간 오류가 생기는지 먼저 확인하세요.
오류 메시지에는 어느 스크립트의 몇 번째 줄에서 문제가 났는지가 나오는 경우가 많습니다. 에러 문구 전체를 복사해서 검색하거나 질문에 함께 적으면 원인을 찾기 쉽습니다.
5. 한 번에 기능 하나만 테스트합니다
예를 들어 타워디펜스를 만든다면 처음부터 웨이브, 적 이동, 유닛 소환, 공격, 데미지, 돈, 저장을 동시에 붙이지 않는 것이 좋습니다. 먼저 적 하나가 경로를 따라 이동하는지 확인하고, 다음에 공격 대상 선택, 다음에 데미지 계산을 붙이는 식으로 나눕니다.
기능을 나누면 어느 단계에서 문제가 생겼는지 바로 알 수 있고, 나중에 기존 코드와 새 코드가 충돌하는 것도 줄일 수 있습니다.
6. 서버와 클라이언트를 연결할 때 RemoteEvent를 이해합니다
UI 버튼을 눌렀다고 클라이언트에서 돈이나 데미지를 마음대로 확정하면 악용될 수 있습니다. 클라이언트는 “버튼을 눌렀다”는 요청을 보내고, 실제 구매 가능 여부나 데미지 판정은 서버에서 다시 검증하는 구조가 기본입니다.
RemoteEvent를 처음 쓸 때는 요청 이름과 전달 값, 서버에서 검증할 항목을 작은 메모로 정리해두면 나중에 중복 Remote나 비슷한 기능이 여러 곳에 생기는 것을 줄일 수 있습니다.
7. 저장 기능은 마지막에 붙이지 말고 작은 값부터 미리 테스트합니다
레벨, 코인, 인벤토리를 모두 만든 뒤 저장을 붙이면 어떤 데이터가 잘못됐는지 찾기 어렵습니다. 숫자 하나를 저장하고 다시 접속했을 때 불러오는 최소 구조부터 검증한 뒤 실제 데이터 구조를 확장하세요.
저장과 불러오기 코드를 여러 스크립트가 각각 처리하도록 만들면 충돌이나 덮어쓰기가 생기기 쉽습니다. 프로젝트가 커질수록 데이터 처리는 한곳에 모아 관리하는 편이 안전합니다.
8. 질문할 때 이 정보가 있으면 답을 받기 쉽습니다
- 무엇을 만들려고 했는지
- 기대한 동작과 실제 동작이 무엇인지
- 오류가 난 Script·LocalScript 위치
- Output의 오류 문구
- 이미 시도해본 해결 방법
- 관련 코드 중 최소한의 재현 가능한 부분
전체 프로젝트를 통째로 올리는 것보다 문제가 생긴 기능을 작은 테스트로 재현하면 다른 개발자가 원인을 파악하기 훨씬 쉽습니다.
9. 첫 목표는 “완성된 작은 게임”으로 잡습니다
거대한 오픈월드보다 작은 장애물 코스, 간단한 버튼 게임, 웨이브 3개짜리 전투 테스트처럼 끝까지 완성할 수 있는 프로젝트가 배우는 데 더 도움이 됩니다. 배포, 테스트, 수정까지 한 번 경험하면 다음 프로젝트에서 구조를 설계하는 속도가 빨라집니다.
