핵심 루프 그레이박스 결과물은 LAUNCHER #9의 개발 현황-시각효과 마무리 단락 참고 확인할 가설 코어 루프의 기능이 정상적으로 작동한다. 발사기 조작을 통해 공의 궤적을 설계할 수 있지만, 완벽히 의도한 결과를 낼 수는 없다. 공이 튕기며 점수를 획득하고,

핵심을 요약하자면, 현재의 우려점은 게임을 진행하면서 "변화하는 것"이 느껴지지 않는다는 것이다.보는 맛은 확실히 살아났다 (1스테이지 첫인상은 합격점)1스테이지와 2스테이지가 달라지는 느낌이 없는 게 아쉽다 (2스테이지에서 유저의 흥미를 이어가게 하는 요소가 필요)상

빌드 자동화 계획 개발 현황 내일 계획

빌드 테스트 빌드 전 체크리스트 [ ] 시작 맵: Game 씬 (아직 메인 화면이 없음) [ ] [ ] 설치 테스트 체크리스트 [ ] 첫 화면 까지 몇 초 걸리나 [ ] 핵심 루프 한 바퀴를 설명 없이 할 수 있나 [ ] 전체 화면, 다른 해상도에서 UI가 잘리

튜터 피드백 아래 내용의 핵심은 결국, 게임으로서 재미있는 한 판을 만들어내야 한다는 내용이었다. 코어 루프의 "기능"은 완성되었지만, 너무 밋밋하다. 첫 판에서의 재미가 느껴지지 않는다. 긴장감을 만들어내거나, 플레이어에게 목표 의식을 만들어줄 수 있는 장치가 있

발사 순서대로 왼쪽부터 채워진다.바의 길이는 고정이고, 정해진 개수만 표시된다. (발사 순서가 빠른 n개)수정이 필요하다. 아래 참조상점 페이즈에서 드래그로 순서를 변경할 수 있다.처음에는 uGUI 오브젝트를 사용했다가, 월드 오브젝트 방식으로 변경했다.공을 표시하는

Common, Rare, Epic, Legendary 네 단계로 구분했다.enum으로 구현하지 않고, 각각을 추상 SO 클래스 ItemRarity의 구현체로 만들었다. 추후 등급 체계를 수정할 가능성을 고려한 방식이다. (enum은 중간에 단계를 추가하거나 빼면, 기존

코어 루프 구현최초 상점 페이즈 시작스테이지 진입클리어 후 다시 상점 진입스테이지 점수 요구치 달성 시 클리어 처리스테이지 정산목표 수치와 달성한 점수기본 보상과 남은 공 보너스 보상공이 페그를 타격 시 페그에 피해를 줌체력이 0이 된 페그는 비활성화 (더 이상 충돌하

게임을 어떻게 매력적으로 표현할지를 1주차 기획 정리 링크기본 플링코 머신의 틀을 만들었다.핀의 간격, 열과 행 개수를 조절할 수 있다.낙하 구역의 칸 수와 배율을 조절할 수 있다.추후 컨텐츠의 기준이 되는 기본 공, 기본 핀을 만들었다.발사기의 위치/각도 조절, 차징

"궁극의 파칭코 머신을 만들고, 대박을 터뜨리세요!"영혼을 건 도박장 속에서 살아남고 더 높은 점수를 얻기 위해 나만의 플링코 보드를 만들어가는 로그라이트 게임.3초 장면: 잘 세팅된 플링코 보드에서 공이 미친 듯이 튕기며 점수가 폭주하는 순간행동: 발사기를 조준하여

AI 작업환경 세팅 한 일 IDE는 VS Code를 유지하기로 결정 (Rider 무료 라이선스는 상업 출시 프로젝트에 쓸 수 없음) Claude Code: csharp-ls 0.28.0과 csharp-lsp 플러그인으로 C# LSP 연결 Codex: Serena MC

인앱결제도 없는 순수 패키지 게임이 될 예정이다. 사행성에 표시한 이유는 테마가 도박이기 때문. 15세 이용가 정도까지는 받을지도 모르겠다.레퍼런스 중 가장 메인이 된 발라트로도 현재 앱스토어 기준 15세 등급근데 발라트로는 등급 관련해서 이슈가 된 적이 있다.물리 기

OT: 8주 간의 계획 로드맵 1~4주차에는 강의와 개발을 병행한다. 6주차 안에 STOVE 심사 신청을 한다. 즉, 그 전에 게임 개발은 마무리해야 한다. 1주차에는 기획을 확정한다. 무엇을 만들지, 무엇을 쳐낼지 정해야 한다. 2주차부터는 빌드 검증을 한다.

이번 글은 설계나 구현이 아니라 보안 사고 대응 기록이다. 배포를 준비하던 중, 팀원 한 명의 GitHub 활동 기록에 본인도 모르는 브랜치 생성과 푸시가 계속 나타나는 것을 발견했다. 따라가 보니 저장소에는 우리가 만들지 않은 시크릿 탈취용 워크플로(sync-chec

지난 글에서는 도메인을 연결하고 Nginx와 인증서로 HTTPS를 적용했다(4단계). 이번 글은 배포 계획의 마지막 자동화 단계인 CI/CD(5단계, 6단계)를 다룬다. 앞쪽 CI는 대부분 팀원이 만든 것이라 우리가 한 일(브랜치 보호, 검증)을 중심으로 짧게 정리하고

지난 글에서는 서버를 처음으로 직접 올리고(3단계), 그 절차를 deploy.sh로 정리했다. 이번 글은 4단계, 도메인과 HTTPS를 다룬다. 서버는 이미 공인 IP(탄력적 IP)로 접속되는데도 도메인을 쓰는 이유를 먼저 정리하고, 이어서 도메인 연결, Nginx 설

지난 글에서는 배포 계획을 세우고 AWS 인프라(VPC, RDS, ECR, EC2, IAM, Parameter Store)를 구축하는 데까지 정리했다. 이번 글은 그 위에 서버를 처음으로 직접 올려 보는 3단계, 수동 배포를 다룬다. 이미지를 내 PC에서 빌드해 ECR

이번 글은 만든 서버를 실제로 운영하기 위한 배포 계획과, 그 첫 단계인 AWS 인프라 구축 과정을 정리한다. 운영과 배포는 이번 부트캠프에서 개념으로만 접했고 구체적인 절차를 몰랐기 때문에, 코드를 올리기에 앞서 무엇을 어떤 순서로 준비해야 하는지부터 계획으로 세웠다

12편에서는 서버를 게임 전체의 흐름으로 검증해야 하는 이유와 두 가지 통합 테스트의 구조를 정리하고, 그중 규칙의 값이 클라이언트와 같은지 확인하는 W4-1(기대값 표)을 다뤘다. 이번 편은 W4-2다. 클라이언트가 실제로 판을 수백 번 돌려 만든 로그 전체를 서버에

11편까지 서버와 클라이언트가 각자 맡은 기능을 구현했다. 기능마다 단위 테스트를 거쳤고, 클라이언트와 로컬 서버를 붙여 한 번 돌려 보기도 했다. 이번 편부터 두 편에 걸쳐 서버를 "게임 전체의 흐름"으로 검증하는 통합 테스트를 다룬다(W4-1, W4-2). 이번 편