일정표
| 시간 | 할 일 | 비고 |
| 08:30~10:00 | 코드카타, 팀프로젝트 | |
| 10:00~13:00 | TA | |
| 14:00~18:00 | 2시 스크럼, 팀프로젝트 | |
| 19:00~21:00 | 7시 스크럼, 팀프로젝트 | |
| 21:00~22:00 | 운동 | |
| 22:00~23:30 | 개인 프로젝트 |
*오늘의 코드카타*
문제. 소수 만들기
주어진 숫자 중 3개의 수를 더했을 때 소수가 되는 경우의 개수를 구하려고 합니다. 숫자들이 들어있는 배열 nums가 매개변수로 주어질 때, nums에 있는 숫자들 중 서로 다른 3개를 골라 더했을 때 소수가 되는 경우의 개수를 return 하도록 solution 함수를 완성해주세요
#include <vector>
#include <iostream>
using namespace std;
bool isPrime(int n)
{
if ( n < 2 ) return false;
for (int i = 2; i * i <= n; i++)
{
if (n % i == 0 ) return false;
}
return true;
}
int solution(vector<int> nums) {
int answer = 0;
for (int i = 0; i < nums.size(); i++)
{
for (int j = i + 1; j < nums.size(); j++)
{
for (int k = j + 1; k < nums.size(); k++)
{
int sum = nums[i] + nums[j] + nums[k];
if (isPrime(sum))
{
answer++;
}
}
}
}
return answer;
}
1) 3중 for문으로 조합 탐색 : 배열 안에서 서로 다른 인덱스의 숫자 3개를 고르기 위해 3중 반복문을 사용한다. 첫 번째 숫자의 인덱스를 i라 하면, 두 번째는 i + 1부터 시작하는 j, 세 번째는 j + 1부터 시작하는 k로 설정하여 중복 없이 3개의 조합을 찾아낸다.
2) **소수 판별 함수 작성 (isPrime) : 어떤 수 N이 소수인지 판별할 때 2부터 N-1까지 일일이 나누어 볼 수도 있지만, 수학적 원리를 이용하면 sqrt{N}까지만 확인해도 완벽하게 소수 여부를 판별할 수 있어 성능을 극대화할 수 있다.
2보다 작은 수는 소수가 아니다.
(참고) i * i <= n 조건 (소수 판별 최적화) 예를 들어 어떤 수의 약수들은 항상 대칭 구조 쌍을 이루게 된다. (예: 16의 약수는 1-16, 2-8, 4-4) 따라서 대칭의 중심점인 제곱근까지만 나누어떨어지는지 검사하면, 그 뒤로는 굳이 연산하지 않아도 소수인지 아닌지 O(sqrt{N})속도로 알아낼 수 있어 우수한 알고리즘이 된다.
*TA*
주제 : 게임 디자인
- 게임 화면에서 디자인 이론이 왜 필요한지 이해한다.
- 색상이 정보 전달과 분위기 형성에 어떤 영향을 주는지 이해한다.
- 명도가 캐릭터, 배경, UI의 분리에 어떤 영향을 주는지 이해한다.
- 채도가 중요도, 분위기, 시선 유도에 어떤 영향을 주는지 이해한다.
- 대비가 플레이어의 정보 인식에 어떤 영향을 주는지 이해한다.
- 강조가 플레이어의 시선을 유도하는 방법이라는 것을 이해한다.
- 가독성이 UI뿐 아니라 전체 게임 화면에 적용되는 개념임을 이해한다.
- 게임 화면을 보고 색상, 명도, 채도, 대비, 강조, 가독성 관점으로 분석할 수 있다.
- 문제 있는 화면을 보고 개선 방향을 제안할 수 있다.
게임 개발자는 모든 아트 리소스를 직접 만들 필요는 없으나, 게임 화면이 왜 잘 읽히는지, 왜 안 읽히는지 판단할 수 있어야 한다.
1) 색상 : 색상은 상태, 위험, 보상, 속성, 분위기, 진영, 상호작용 가능 여부를 전달하는 데 사용된다. 색상에 반드시 어떠한 역할이 부여되어있는 것은 아닌데, 플레이어가 이미 익숙하게 받아들이는 의미가 있다는 것을 알아야한다.
2) 명도 : 명도는 색이 얼마나 밝거나 어두운지를 의미하며, 게임 화면에서 명도는 가독성과 시선 유도에 매우 중요하다.
(예시)
- 캐릭터와 배경분리 : 캐릭터가 어두운 의상을 입고 있고 배경도 어두우면 캐릭터가 배경에 묻힐 수 있다. 따라서, 어두운 분위기의 게임이어도 캐릭터의 가장자리에 Rim Light, 밝은 Outline을 덧대어 인식이 쉬워지도록 만든다. 추가로 배경 명도를 낮추고 캐릭터 명도를 높이거나, 카메라/조명 방향을 조정하는 방법으로 개선이 가능하다.
- UI 텍스트 : 밝은 배경 위에 밝은 글자를 올리면 글자가 잘 보이지 않는다. UI에서는 텍스트와 배경 사이의 명도 차이를 충분히 확보해야 한다. 이를 위해 텍스트와 배경의 명도 차이를 충분히 확보하고, 필요 시 반투명 배경, Outline, Shadow를 활용하고, 플레이어가 한눈에 읽을 수 있도록 해야 한다.
3) 채도 : 색이 선명한 정도를 의미한다. 채도가 높으면 색이 강하고 눈에 잘 띈다. 채도가 낮으면 색이 차분하고 흐리며, 현실적인 느낌을 줄 수 있다.
(예시)
- 중요 아이템 강조 : 중요 아이템은 배경보다 높은 채도와 밝은 색을 사용하는 경우가 많다. 아이템이 배경과 비슷한 채도와 색을 가지면 플레이어는 아이템을 놓칠 수 있다.
- 화면 분위기 : 채도가 낮은 화면은 현실적이고 차분하거나 우울한 느낌을 줄 수 있다. 채도가 높은 화면은 활기차고 판타지적이며 강한 인상을 줄 수 있다.
4) 대비 : 두 요소 사이의 차이를 의미한다. 색상 뿐만 아니라 밝기, 크기, 채도, 움직임, 형태 차이도 모두 대비가 될 수 있다.
| 대비 종류 | 설명 | 게임 예시 |
| 명도 대비 | 밝고 어두운 차이 | 어두운 배경 위 밝은 캐릭터 |
| 색상 대비 | 색의 차이 | 빨간 경고 표시와 어두운 UI |
| 채도 대비 | 선명함의 차이 | 낮은 채도 배경 위 높은 채도 아이템 |
| 크기 대비 | 크기의 차이 | 큰 보스와 작은 플레이어 |
| 움직임 대비 | 움직임의 차이 | 정적인 배경 속 움직이는 적 |
| 형태 대비 | 모양의 차이 | 둥근 배경 속 날카로운 함정 |
(예시)
- 보스 공격 범위 : 보스가 강한 공격을 하기 전에 바닥에 빨간 원형으로 범위를 표시한다. 색상 대비를 통해 경고 표시를 하는 것이다.
5) 강조 : 플레이어가 먼저 봐야 하는 요소를 드러내는 방법이다.
| 강조 방식 | 예시 |
| 색상 | 중요한 아이템을 금색으로 표시 |
| 명도 | 상호작용 오브젝트를 밝게 표시 |
| 채도 | 보상 아이템만 선명하게 표시 |
| 크기 | 보스 체력바를 크게 표시 |
| 이펙트 | 아이템에 반짝이는 효과 추가 |
| 움직임 | 퀘스트 마커가 살짝 움직임 |
| Outline | 상호작용 가능한 물체 외곽선 표시 |
| UI | 화면 중앙에 경고 메시지 표시 |
(예시)
- 상호작용 오브젝트 : 색상을 사용해서 직관적으로 전달하고, 정보를 빠르게 구분하고 혼란을 줄여준다. 또한 다양한 시각적 강조(밝기로 강조, 밝은 색 포인트, Outline 표시, UI 아이콘 표시, 이펙트 추가 등)를 통해 플레이어가 상호작용 가능한 오브젝트를 빠르게 알아차리게 한다.
6) 가독성 : 플레이어가 정보를 빠르게 이해할 수 있는 정도이다.
(예시)
이펙트가 너무 강하면 중요한 게임 정보를 가릴 수 있다. 따라서 적의 위치가 보이도록 적절한 크기의 이펙트가 필요하다.
>> 이펙트 크기 조절, 투명도/밝기 조절, 적 실루엣이 보이도록 연출
피격 이펙트가 너무 밝으면 다음 공격 범위가 보이지 않는다. 따라서 피격 이펙트가 과하지 않고 공격 범위를 확인할 수 있게 해야한다.
>> 피격 이펙트 밝기/시간 조절, 중요한 정보가 가려지지 않도록 연출
스킬 이펙트가 UI를 가리면 체력/쿨타임 확인이 불가능하다. 따라서 이펙트와 UI가 겹치지 않게 연출해서 정보를 확인할 수 있도록 한다.
>> UI 안전 영역 확보, 이펙트 위치/카메라 연출 조정, UI 색상 대비 확보
7) 화면 구성 : 화면 안의 요소들을 어디에, 어떤 크기로, 어떤 관계로 배치할지 결정하는 과정이다.
| 요소 | 질문 |
| 플레이어 캐릭터 | 화면에서 캐릭터 위치를 빠르게 확인할 수 있는가? |
| 적 | 적의 위치와 행동이 잘 보이는가? |
| 위험 요소 | 공격 범위, 함정, 투사체가 명확하게 보이는가? |
| 보상 요소 | 아이템, 목표 지점, 상호작용 오브젝트가 눈에 띄는가? |
| UI | 필요한 정보가 적절한 위치에 배치되어 있는가? |
| 배경 | 분위기를 만들면서도 주요 정보를 방해하지 않는가? |
| 카메라 | 플레이어가 봐야 할 정보를 화면 안에 담고 있는가? |
- 게임 화면의 요소 : 캐릭터, 적, 배경, 아이템, 이펙트, UI, 카메라, 조명, 공격 범위, 퀘스트 표시
- 좋은 화면 구성의 목표 : 중요한 정보를 먼저, 더 크게 보이게 하기. 시선의 흐름을 자연스럽게 유도하기, 위험/목표/보상을 명확히 구분하기, 플레이 몰입감과 가독성을 높이기
- 시선의 흐름 : 가장 중요한 요소(캐릭터/적/위험) > 다음으로 중요한 요소(목표/상호작용) > 보조 정보(아이템/이펙트) > UI 및 세부 정보(수치/아이콘)
- 구성의 핵심 원칙 : 대비(명도/채도/크기로 중요도 구분) > 크기(중요한 요소는 더 크게) > 위치(시선이 잘 가는 위치에 중요 요소 배치) > 여백(적절한 여백으로 정보 간섭 최소화) > 관계(연관된 요소끼리 묶여서 배치)
(예시)
<보스전 화면 구성>
보스 위치 : 시선의 중심, 가장 큰 위협 요소
공격 준비(와인드업) : 보스의 행동을 읽고 다음 공격을 예측
공격 범위(텔레그래프) : 위험 구역을 인지하고 회피 빈독를 결정
플레이어 위치 : 화면 하단 중심으로 조작과 이동 결정
정보확인&대응 : HP, 스킬 쿨타임, 회피 자원 등 핵심 정보를 빠르게 확인하고 대응하기.
8) 비율 : 비율은 화면 안의 요소들이 서로 어떤 크기 관계를 가지는지를 의미한다. 게임 화면에서 비율은 중요도, 위협감, 거리감, 공간감을 만든다.
(예시)
<보스와 플레이어의 비율>
보스가 플레이어보다 훨씬 크게 보이면 플레이어는 보스를 강한 위협으로 인식한다. 일반적으로 보스 : 플레이어 = 3 : 1 정도가 자주 사용된다. 즉, 보스에게 위압감을 느낄 수 있도록 하고, 전체 모션과 바닥 패턴이 화면 안에 들어오게 해서 공격 패턴을 읽기 쉽게 만들어야 한다.
8) 균형 : 화면 안의 시각적 무게가 어떻게 분포되어 있는지를 의미한다. 게임에서는 안정감과 긴장감을 모두 사용할 수 있고, 탐험 장면에서는 안정적인 균형이 좋을 수도 있다. 전투 장면에서는 약간의 불균형이 긴장감을 만들 수 있다.
<대칭 균형> : 캐릭터가 중앙에 있고 양쪽 배경이 비슷한 형태라면 안정적으로 보일 수 있다.
<비대칭 균형> : 화면 양쪽이 완전히 같지는 않지만 시각적 무게가 조절된 구성이다.
9) 시선 흐름 : 플레이어가 화면을 어떤 순서로 읽는지를 의미한다.
목표는 플레이어가 봐야 할 정보를 자연스러운 순서로 보여주는 것이다.
| 요소 | 역할 |
| 위치 | 화면 중앙, 상단, 하단, 가장자리 배치 |
| 크기 | 큰 요소가 먼저 보이기 쉬움 |
| 명도 | 밝은 요소가 먼저 보이기 쉬움 |
| 채도 | 선명한 요소가 먼저 보이기 쉬움 |
| 움직임 | 움직이는 요소가 시선을 끌기 쉬움 |
| 이펙트 | 빛, 폭발, 반짝임이 시선을 유도 |
| 방향성 | 캐릭터 시선, 무기 방향, 길의 흐름 |
| UI | 아이콘, 마커, 경고 표시가 시선을 유도 |
(예시)
<탐험 화면의 시선 흐름>
플레이어가 다음 목적지를 자연스럽게 발견하게 만들기 위해서, 길의 형태/조명/색상/카메라 방향/배경 구조를 활용해서 시선을 유도하는 것이다.
*팀 프로젝트*
1. 시작하기에 앞서 개념 공부
dev 브랜치에서 내 로컬 브랜치인 feat/UI 브랜치를 파서 작업중. 매일 저녁에 모든 팀원이 PR을 올리고, dev에 merge 시켜놓거든. 나는 아침에 이제 dev에서 그거를 다시 로컬 브랜치로 merge해서 작업을 시작하는 방식인데, 내가 설정해 놓은 에디터 세팅이랑, 내가 만들어 놓은 나만의 테스트용 파일들(블루프린트, 테스트 맵)이 날아가버린다. 무엇이 문제인지 먼저 파악하고 공유하기로 했다.
사실 이런 유형의 문제는 대부분 Git이 추적(Track)하지 말아야 할 파일까지 dev 브랜치에 포함되어 있거나, 로컬 전용 파일들이 덮어씌워지면서 발생한다.
1) .gitignore 확인하기
# 에디터 개인 설정 및 로컬 캐시 제외
/Saved/
/Intermediate/
/DerivedDataCache/
# 나만의 테스트 전용 폴더 제외 (예: Content/Test 폴더를 만든 경우)
/Content/Test/Content 폴더 하위에 자신만의 테스트 폴더(예: Test 또는 Developer)를 만들고, 이를 .gitignore에 등록하면 그 안의 블루프린트나 테스트 맵은 Git이 건드리지 않는다.
이미 dev 브랜치에 Saved 폴더나 테스트 파일이 올라가 있다면, .gitignore에 적어도 계속 파일이 바뀐다. Git이 더 이상 이 파일들을 추적하지 않도록 명령어(또는 깃허브 데스크탑)로 지워줘야 한다. 실제 파일이 삭제되는 것은 아니며, Git의 관리 대상에서만 제외하는 작업이다.
팀원들과 공유하고, dev 브랜치에서 아래 작업을 한 번 진행해야 한다. Git Bash에서 작업해보자.
# Git 캐시에서 제거 (실제 파일은 유지됨)
git rm -r --cached Saved/
git rm -r --cached Intermediate/
# 만약 Content/Test 폴더도 이미 올라갔다면 캐시 제거
git rm -r --cached Content/Test/
# 변경 사항 커밋 후 dev에 반영
git commit -m "chore: 고유 설정 및 테스트 폴더 Git 추적 제외"
git push origin dev
2) 언리얼 엔진 자체 기능 활용하기 (Developers 폴더)
언리얼 엔진은 애초에 협업할 때 팀원 간의 테스트 파일이 엉키지 않도록 Developer(개발자) 폴더 기능을 지원한다.
Developers 폴더는 일반적으로 언리얼 표준 .gitignore에서 자동으로 제외 항목으로 묶여 있기 때문에, 개인 테스트용 블루프린트나 맵은 폴더 안에서만 생성하고 작업하는 것이 좋다. 그러면 dev 브랜치를 아무리 머지해도 내 테스트 파일이 날아가거나 팀원에게 공유되는 일이 없게 된다.
3) dev 브랜치를 확인해보니, Saved, Intermediate 등의 폴더가 원격 저장소에서 정상적으로 제외되어 있었다. 그렇다면 내 개인 에디터 세팅과 테스트 파일이 날아가버리는 원인은 깃허브 데스크탑(GitHub Desktop)에서 브랜치를 전환하거나 머지(Merge)할 때 발생하는 로컬(내 컴퓨터) 환경의 특성 때문이다.
원인은 크게 두 가지로 추정할 수 있다.
- Config 폴더 내 공통 세팅 덮어쓰기: 언리얼 엔진의 에디터 세팅 중 일부(예: 에디터 레이아웃, 단축키 등)는 Saved에 저장되지만, 프로젝트 공통 설정(입력 매핑, 플러그인 활성화, 기본 맵 설정 등)은 Config/ 폴더 내의 .ini 파일에 저장된다. 팀원들이 dev 브랜치의 Config 파일을 수정해서 올렸고, 아침에 이를 머지하면서 질문자님이 로컬에서 바꾼 세팅과 충돌이 나거나 덮어씌워졌을 가능성이 높다.
- 깃허브 데스크탑의 'Stash(임시 저장)' 처리 미숙: feat/UI 브랜치에서 에디터 세팅이나 테스트 파일이 변경된 상태(깃허브 데스크탑의 'Changes'에 떠 있는 상태)에서 dev 브랜치를 머지하려고 하면, 깃허브 데스크탑은 내 변경 사항을 잠시 숨겨두었다가(Stash) 머지 후 다시 꺼내온다(Pop). 이 과정에서 언리얼 에디터가 켜져 있으면 에디터가 메모리에 들고 있던 예전 세팅으로 파일을 다시 덮어써 버리면서 변경 사항이 날아갈 수 있다.
원인을 알았으니, 이제 예방을 할 차례다. 핵심은 "내가 변경한 나만의 세팅과 테스트 파일을 Git이 추적하지 않게 만들어서, Changes 목록에서 아예 지워버리는 것" 이다.
- 개인 테스트 파일 해결 (Developers 폴더 활용)
언리얼 에디터의 Developers 폴더는 일반적으로 .gitignore에 의해 자동 제외되지만, 프로젝트 세팅에 따라 간혹 추적되는 경우가 있다. 만약 Developers/내계정 폴더 안의 파일이 깃허브 데스크탑의 'Changes'에 뜬다면, 앞서 확인한 .gitignore 맨 아래에 다음 줄을 추가하고 이 .gitignore 파일 자체만 dev에 커밋해 두면 된다.
/Content/Developers/
- 개인 에디터 세팅 해결 (Config 충돌 방지)
개인적인 편의를 위해 바꾼 에디터 세팅이 Config/DefaultEditor.ini 등을 건드려서 'Changes'에 자꾸 잡힌다면, Git의 강제 무시 명령어를 쓰는 것이 좋다. 터미널(또는 깃허브 데스크탑의 Repository -> Open in Command Prompt / Git Bash)을 열고 아래 명령어를 입력한다.
// 에디터 세팅 강제 무시 명령어
git update-index --assume-unchanged Config/DefaultEditor.ini
// 강제 무시 해제 명령어
git update-index ---no-assume-unchanged Config/DefaultEditor.ini