FPS Aim Test - 1인칭 에임 테스트 웹 게임

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

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

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

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

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

게임 창 시작 화면 시작 메뉴 시작 메뉴 구성 처음 기본 페이지에서 전체화면 모드 또는 창 모드를 클릭해 게임 창으로 이동하면 나오는 화면이다. 메뉴 구성은 다음과 같다. >1. 해상도 설정 16:9 4:3 16:10 효과음 & 배경음 시작 버

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

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

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

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

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

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

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

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

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

지난 힘들었던 리팩토링의 다음 작업은 메인 페이지 리모델링이었다.지금의 메인 페이지는 처음에 고안한 투박한 디자인이고,프론트엔드 프로젝트라고 보기엔 요소가 많이 부족했다.그래서 다양한 디자인 기법을 활용해FPS Aim Test 게임과 어울리는 페이지로 만들어 보고자 했

막바지에 다다른 FPS Aim Test의 마무리 작업으로,최근에는 새로운 기능 추가보다는 주석 등 컨벤션 점검과기존 기능을 안정화하고, 예상치 못한 버그를 해결하는 작업이 많았다.특히 resize, fullscreen 전환, Canvas 렌더링과 관련된 문제들은각각 독

FPS Aim Test는 처음부터 “빠르고 정밀한 렌더링을 다뤄보는 프로젝트”를 목표로 시작했다.단순한 웹 페이지가 아니라, 화면이 끊임없이 변하고 사용자의 입력에 즉각 반응하는 구조를 직접 만들어보고 싶었다.그래서 흔히 볼 수 있는 에임 테스트 게임이 아니라,마우스로

이력서와 포트폴리오를 수정하며 다시 입사 지원을 시작하면서, 문득 내 aimtest가 여전히 http를 사용중이라는 것을 깨달았다.분명 나중에 https로 다시 바꾸려고 했고, 그리 어렵지 않은 작업으로 알고 있었기에 잽싸게 시작했으나,CloudFront 설정 및 배포