🛠️ 오늘 한 작업
- 실전 모의 면접 1일차를 진행했습니다. 인성 면접 중심으로 질문을 받았고, 전날 준비했던 내용을 바탕으로 답변했습니다.
- 다행히도 튜터님께서 제가 가장 면접을 잘 봤다고 말씀해주셔서 조금 안심했습니다.
- 퀵슬롯 수정 작업을 진행했습니다.
- 퀵슬롯 등록 방식과 이동 방식을 수정했습니다.
- 아이템 추가 수정 작업으로 장비 해제 시 기존 아이템 정보를 유지하는 방향으로 수정했습니다.
- 장비창 쪽 수정도 같이 진행했습니다.
🎤 실전 모의 면접 1일차
오늘은 부트캠프에서 지원하는 실전 모의 면접 1일차가 있었습니다.
이번 면접은 기술 면접보다는 인성 면접 중심으로 진행된다고 해서, 전날에 예상 질문에 대한 답변을 꽤 길게 정리해두었습니다.
특히 제 이야기를 어떻게 풀어갈지 많이 준비했습니다. 컴퓨터공학과를 전공으로 선택했고, 졸업 작품으로 Unity 게임을 만들면서 인기상을 받았고, 그 경험을 계기로 게임 개발에 관심을 가지게 되었다는 흐름으로 정리했습니다.
그냥 “게임 개발자가 되고 싶습니다”라고 말하는 것보다, 왜 게임 개발에 관심을 갖게 됐는지 실제 경험을 기준으로 말하는 게 더 설득력 있을 것 같았습니다.
면접 전에는 긴장을 많이 했는데, 다행히 준비했던 내용이 잘 전달된 것 같습니다. 튜터님께서 이 중에서 제가 가장 면접을 잘 봤다고 말씀해주셔서 정말 다행이었습니다.
솔직히 면접은 코딩이랑 또 다른 느낌이라 부담이 있었는데, 그래도 제 경험을 정리해둔 게 도움이 많이 됐습니다.
⚡ 퀵슬롯 수정
개발 쪽에서는 퀵슬롯을 이어서 수정했습니다.
기존에는 인벤토리 아이템을 퀵슬롯에 등록하는 기능과 퀵슬롯끼리 교환하는 기능을 따로 만들어두었는데, 오늘은 이 구조를 조금 바꿨습니다.
특히 같은 ItemStack이 여러 퀵슬롯에 중복 등록되지 않도록 처리하는 부분을 추가했습니다. 같은 아이템 참조가 여러 슬롯에 동시에 들어가 있으면, 나중에 아이템을 사용하거나 제거할 때 꼬일 가능성이 있기 때문입니다.
QuickSlot.cs - 같은 ItemStack 중복 등록 제거
private void UnbindSameStack(ItemStack stack)
{
if (stack == null) return;
var removeKeys = new List<QuickSlotType>();
foreach (var kv in quickSlots)
{
if (ReferenceEquals(kv.Value, stack))
{
removeKeys.Add(kv.Key);
}
}
for (int i = 0; i < removeKeys.Count; i++)
{
quickSlots.Remove(removeKeys[i]);
}
}
처음에는 하나만 찾아서 제거하는 방식이었는데, 아예 같은 참조를 가진 슬롯을 전부 찾아서 제거하는 쪽으로 바꿨습니다.
퀵슬롯은 아이템을 복사해서 들고 있는 구조가 아니라, 인벤토리 안의 ItemStack을 참조하는 방식이라 이런 처리가 필요했습니다.
🧷 퀵슬롯 등록 가능 아이템 제한
퀵슬롯에는 아무 아이템이나 들어가면 안 된다고 판단했습니다.
그래서 인벤토리에서 퀵슬롯으로 등록할 때, 아이템 타입을 확인해서 무기와 소비 아이템만 등록할 수 있도록 수정했습니다.
QuickSlot.cs - 등록 가능한 아이템 타입 검사
var type = DataManager.Instance.ItemDB.GetItemType(stack.itemId);
if (type != ItemType.Weapon && type != ItemType.Consumable)
{
return false;
}
퀵슬롯은 전투나 탐색 중 빠르게 사용하는 UI에 가깝기 때문에, 무기와 소비 아이템 위주로 제한하는 게 더 자연스럽다고 생각했습니다.
장비나 기타 아이템까지 등록되면 사용 규칙이 애매해질 수 있어서, 일단은 사용 목적이 명확한 아이템만 허용하는 방향으로 갔습니다.
🔁 퀵슬롯 이동 방식 수정
퀵슬롯끼리의 이동 방식도 수정했습니다.
기존에는 두 퀵슬롯의 아이템을 서로 교환하는 Swap 방식이었다면, 오늘은 특정 퀵슬롯의 아이템을 다른 퀵슬롯으로 옮기는 Move 방식으로 바꿨습니다.
QuickSlot.cs - 퀵슬롯 이동
public bool Move(QuickSlotType from, QuickSlotType to)
{
if (from == to) return false;
if (!quickSlots.TryGetValue(from, out var stack) || stack == null) return false;
quickSlots.Remove(from);
quickSlots[to] = stack;
EventManager.TriggerEvent(EventKey.QuickSlotChanged);
return true;
}
퀵슬롯은 인벤토리 슬롯처럼 실제 아이템 위치를 바꾸는 것이 아니라, 등록 정보를 관리하는 쪽에 가깝습니다. 그래서 “아이템을 교환한다”보다 “등록 위치를 옮긴다”는 느낌으로 보는 게 더 맞다고 생각했습니다.
다만 이 부분은 실제 UX에 따라 다시 바뀔 수도 있을 것 같습니다. 퀵슬롯끼리 드래그했을 때 교환이 더 자연스러운지, 이동이 더 자연스러운지는 테스트하면서 봐야 할 것 같습니다.
🎒 장비 해제 시 기존 아이템 유지
오늘은 장비 해제 쪽도 수정했습니다.
기존에는 장비를 해제할 때 itemId와 count를 기준으로 새 아이템처럼 다시 인벤토리에 추가하는 흐름이 있었습니다.
그런데 내구도 같은 런타임 정보가 있는 아이템은 그렇게 처리하면 문제가 생길 수 있습니다. 새로 아이템을 추가하면 기존 아이템의 내구도나 런타임 정보가 유지되지 않을 수 있기 때문입니다.
그래서 장비 해제나 교체 시 기존 ItemStack 자체를 인벤토리에 다시 넣는 방향으로 수정했습니다.
Equipment.cs - 기존 ItemStack 유지
if (!inv.TryAddStack(stack)) return;
equippedItems.Remove(slot);
EventManager.TriggerEvent(EventKey.EquipmentChanged);
이 수정은 꽤 중요했습니다. 무기나 방어구처럼 내구도를 가진 아이템은 단순히 같은 ID의 새 아이템으로 복구하면 안 됩니다. 기존 아이템이 가진 상태를 그대로 유지해야 하기 때문입니다.
아직 이 부분은 더 검증이 필요해 보이지만, 방향 자체는 맞다고 생각했습니다. 아이템을 장착하거나 해제할 때는 새로 생성하는 게 아니라, 가능한 기존 인스턴스 정보를 유지하는 게 더 안전합니다.
⚔️ 장비 교체 처리 수정
장비를 새로 장착할 때 기존 장비가 이미 들어있는 경우도 다시 손봤습니다.
기존 장비가 있는 슬롯에 새 장비를 넣으면, 기존 장비는 인벤토리로 돌아가야 합니다. 이때도 기존 장비의 ItemStack을 유지하는 방향으로 처리했습니다.
Equipment.cs - 기존 장비를 원래 인벤토리 위치로 돌리기
equippedItems.TryGetValue(slot, out var oldStack);
equippedItems[slot] = stack;
if (oldStack != null)
{
if (!inv.TryPlaceStackAt(oldStack, fromIndex, out var swapped))
{
equippedItems[slot] = oldStack;
return false;
}
}
else
{
inv.ClearSlot(fromIndex);
}
이렇게 하면 새 장비를 장착했을 때, 원래 장비 슬롯에 있던 아이템을 인벤토리의 기존 위치로 되돌리는 흐름을 만들 수 있습니다.
장비 교체는 단순히 “새 장비를 넣는다”로 끝나는 문제가 아니었습니다. 기존 장비를 어디로 보낼지, 인벤토리 칸이 비어 있는지, 기존 아이템의 런타임 정보를 유지할지까지 같이 봐야 했습니다.
📌 오늘의 회고
오늘은 실전 모의 면접이 있어서 개발에만 집중한 날은 아니었습니다.
그래도 면접을 생각보다 잘 마쳐서 마음이 많이 놓였습니다. 전날에 제 경험을 길게 정리해둔 게 확실히 도움이 됐습니다. 컴퓨터공학과를 선택한 이유, 졸업 작품으로 게임을 만들었던 경험, 인기상을 받으면서 게임 개발에 더 관심을 가지게 된 흐름을 말로 정리해둔 게 좋았던 것 같습니다.
개발 쪽에서는 퀵슬롯과 장비 해제 흐름을 수정했습니다. 퀵슬롯은 단순히 아이콘을 등록하는 기능처럼 보이지만, 실제로는 인벤토리의 ItemStack을 참조하고 있어서 중복 등록이나 유효성 검사까지 신경 써야 했습니다.
장비 해제 쪽도 생각보다 중요한 문제였습니다. 내구도가 있는 아이템을 새로 생성해서 넣어버리면 기존 상태가 사라질 수 있기 때문에, 기존 ItemStack을 유지하는 방식으로 수정하기 시작했습니다.
오늘 목표였던 “면접 클리어”는 어느 정도 성공한 것 같고, 퀵슬롯도 계속 손보고 있습니다. 다음에는 퀵슬롯과 플레이어 연결 쪽을 더 확인해야 할 것 같습니다.
'내일배움캠프 본캠프' 카테고리의 다른 글
| [내일배움캠프 60일차 TIL] 최종 프로젝트 12일차 - 퀵슬롯 상태 표시와 소비 아이템 사용 기능 (0) | 2025.12.23 |
|---|---|
| [내일배움캠프 59일차 TIL] 최종 프로젝트 11일차 - 퀵슬롯 수정과 플레이어 인벤토리 연결 (0) | 2025.12.22 |
| [내일배움캠프 57일차 TIL] 최종 프로젝트 9일차 - 모의 면접 준비와 퀵슬롯 구조 시작 (0) | 2025.12.18 |
| [내일배움캠프 56일차 TIL] 최종 프로젝트 8일차 - 드래그 앤 드롭 시도와 아이템 텍스트 표시 정리 (0) | 2025.12.17 |
| [내일배움캠프 55일차 TIL] 최종 프로젝트 7일차 - 인벤토리 기능 구현과 구조 재정리 (0) | 2025.12.16 |