Aim Test

개인 프로젝트 주제를 고민하던 중, 나의 고려사항은 이러했다.서비스 사용자를 기대할 수 있는 주제화면을 다채롭게 사용할 수 있는 주제가벼운 백엔드를 사용하기 좋은 주제그렇게 고민해서 만든 주제, Aim Tester 가 되겠다.이름 그대로 에임 테스트 게임이다. 다만 많

프로젝트 초기 세팅을 마치고 첫 번째로 진행한 작업은 맵을 구현하는 점이다.단순하게라도 원근감 있게 맵을 제작하는 것이 중요했다. 3D로 게임을 구현하는 것은 지금의 내겐 큰 어려움이 있으니, 2D 이미지로 원근감을 주는 사격 게임의 맵을 구현해야 했다.Figma를 사

FPS용 에임 테스트 게임을 만들려고 했으니, 가장 먼저 구현해야 할 것은 1인칭 시점의 화면 전환이었다. 실현 가능성을 찾아보던 중 사용하려 했던 FullscreenAPI와 PointerLockAPI를 사용해 전체화면에서 마우스 포인터를 고정시키고, 마우스를 이동한다

맵과 마우스 이동에 따른 1인칭 시점 렌더링까지 구현했으니 이제는 타겟을 생성해야 한다. 디자인부터 생각하다가 점수 측정 방식에 따라 디자인이 달라져야 한다는 생각에 도달했다.게임 시스템을 구상하면서 점수 측정 기준을 단순히 맞춘 개수로 할지, 오래 버틴 시간을 기준으

타겟을 생성하고, 클릭 시 점수 증가, 타겟 제거, 생성 속도 관리 등 타겟 생성과 게임 운영에 대한 로직이 게임 기능 상에서의 핵심 기능이다. 그런 기준들을 설정하고 관리하는 모듈로써, TargetManager를 클래스로 만들었다.타겟 메니저는 클래스로 구현했다.함수

랭킹보드 데이터 예시처음으로 백엔드를 구현해서 랭킹보드를 구현했다.전공수업과 정보처리기사 공부하면서 SQL을 거의 이론으로만 공부했었는데, 처음으로 실제 사용할 DB와 api까지 설계해서 만들어보니 새로운 기분이었다.백엔드를 사용해 출력하려고 했던 데이터는 위 이미지처

동작은 멀쩡했다. 대신 코드가 나를 괴롭혔다.FPS Aim Test를 만들면서 타겟 스폰은 ‘그냥 된다’고 생각했다. 실제 플레이에서도 수십 ms 차이를 체감하기는 어렵다. 하지만 개발 완료 후 코드를 다시 볼 때 setInterval을 사실상 1회용으로 쓰고 즉시 초

기존의 '처리되지 않은 타겟 10개 도달시 종료' 기준은 사용자가 한창 집중력이 오른 시점에 한 번의 실수로 바로 끝나버리는 아쉬움이 있었다. 이를 어떻게 개선할 수 있을까 고민하다가, 단순히 개수를 늘리는 것만으론 재미가 살지 않을 것 같아서 '3초 이상 10개 이상

지난 게시글에서 게임 종료 직전 타겟 색상을 바꾸는 기능을 추가하고 발견한 문제가 하나 있었다.타겟의 색상을 여러 번 바꾸고 되돌리는 과정에서,타겟의 외곽선이 점점 거칠어지고 흐려지는 현상이 나타난 것이다.처음엔 색상 처리 로직이나 픽셀 좌표를 의심했지만,결국 원인은

타겟을 맞추면 우측 상단의 점수에 방금의 사격 점수가 더해진다. 하지만 게임 중 우측 상단을 확인하기란 속도가 빨라지는 중후반부에는 어렵다. 조금 더 생동감 있고 즉각적인 피드백을 주고 싶어서 '타겟을 맞춘 지점에서 점수가 떠오르며 사라지는' 플로팅 스코어 기능을 추가

게임 로직과 렌더 루프를 정리하고 나니, 남은 건 보는 맛이었다. 추가 기능도 거의 마치고 전체를 돌아보니, 내가 개발을 하며 마무리엔 항상 섬세하게 작업하고자 했던 애니메이션을 거의 넣지 않았다는 것을 깨달았다.거의 막바지에 이르러서 메뉴/패널에 애니메이션을 입히기로

대부분의 기능이 마무리되고 나니, 이제 눈에 띄는 건 ‘로딩 순간’이었다.게임 화면이 열릴 때, 검은 캔버스와 메뉴 UI가 맵보다 먼저 나타나는 걸 보고 있었다. 대체로 짧은 순간이었지만 계속 거슬렸다.완성도 있는 UI는 절대 이런 틈을 허용하지 않을 것이다. 본래는

이번 작업량은 하나의 게시글에 적기엔 너무 많아 2개로 나눈다.이 게시글에선 책임 분리와 Hub패턴의 적용 방식, 리팩토링 전후 결과에 대해 요약하고, 다음 게시글에서 분리한 핵심 커스텀 훅에 대해 설명할 예정이다.기능 구현에 집중하다 보면 어느새 파일 하나가 비대해지

지난 글에서는 600줄에 육박하던 GameWorld 컴포넌트의 책임을 분리하고, 컴포넌트는 이를 연결하는 Hub의 역할만 하도록 재정의했다.구조적인 큰 틀은 잡았다. 하지만 이 리팩토링 과정이 단순히 코드를 "파일 별로 나누기"로 끝난 건 아니다.오히려 진짜 문제는 파