Category
Preparing references and filters for this topic. 이 주제의 레퍼런스와 필터를 준비하고 있습니다.
Category Reference
게임 루프, 패턴과 구조, technical design, 게임 수학, 좌표계, 카메라, 렌더링 파이프라인까지 게임 프로그래밍의 핵심 흐름을 카드형 레퍼런스로 정리합니다.
Search titles, summaries, tags, and subcategories.
Showing 39 cards.
Subcategory
21 cards
게임이 input, update, render를 frame 단위로 반복한다는 사고와 variable/fixed timestep을 어떻게 읽어야 하는지 정리합니다.
while (running)
poll input
update simulation
render frame게임 오브젝트를 설계할 때 상속보다 컴포지션을 우선 검토하는 이유와, 예외적으로 상속이 맞는 상황을 비교합니다.
Player
- MovementComponent
- HealthComponent
- WeaponComponent캐릭터나 UI, 전투 흐름처럼 mode가 분명한 시스템에서 상태 패턴과 finite state machine을 어떻게 적용할지 정리합니다.
Idle -> Run -> Jump -> Fall -> Land투사체, 이펙트, 오디오처럼 자주 생성·파괴되는 대상을 object pool로 다룰 때 무엇이 핵심인지 정리합니다.
spawn 요청
-> 풀에서 비어 있는 객체 확보
-> 상태 초기화
-> 사용 종료 시 반환적, 투사체, 보상처럼 런타임에 여러 종류를 생성할 때 factory 패턴으로 생성 규칙과 초기화를 어떻게 모을지 정리합니다.
spawn 요청
-> factory가 타입 결정
-> 필요한 prefab / 설정 / 초기화 적용
-> 호출부는 "무엇을 만들지"만 안다게임 전역에서 하나만 있어야 하는 시스템을 singleton으로 둘 때의 장점과, 전역 접근이 숨기는 비용을 함께 정리합니다.
전역에서 하나
-> 정말 "한 인스턴스"가 규칙일 때만 singleton
전역 접근이 편한 것
!= singleton이 맞는 것입력이나 행동을 command 객체로 캡슐화해 queue, replay, undo에 연결할 때 어떤 구조가 자연스러운지 정리합니다.
입력
-> command 생성
-> queue / stack에 저장
-> 지금 실행하거나 나중에 재생적 처치, 퀘스트 완료, 체력 변화처럼 한 사건을 여러 시스템에 전달할 때 observer 패턴과 이벤트 경계를 어떻게 잡을지 정리합니다.
체력 변경
-> Health가 이벤트 발행
-> UI / SFX / 퀘스트 시스템이 각자 구독이동, 공격, 타겟팅처럼 런타임에 행동 알고리즘을 바꿔야 할 때 strategy 패턴을 어떻게 적용할지 정리합니다.
Context
-> 현재 전략 참조
-> 필요 시 다른 전략으로 교체
MeleeAttack / RangedAttack / MagicAttackSOLID 원칙을 게임플레이 코드, UI, 매니저, ScriptableObject 구조에 어떻게 읽어야 하는지 Unity 맥락에서 빠르게 정리합니다.
SOLID 빠른 질문
- 책임이 하나인가
- 새 기능이 기존 switch 수정 없이 붙는가
- 대체 구현을 바꿔도 호출부가 버티는가
- 큰 인터페이스를 억지로 구현하고 있지 않은가
- 구체 타입 대신 계약에 의존하는가플레이어, 적, UI, 매니저 코드가 비대해질 때 SRP 기준으로 어디를 끊어야 하는지 Unity 맥락에서 정리합니다.
PlayerController가
입력 / 이동 / 공격 / HUD / 저장
를 다 하면 SRP가 약하다게임플레이 흐름이 특정 MonoBehaviour 구현에 묶이지 않도록 계약과 조립 지점을 어디에 둘지 Unity 기준으로 정리합니다.
high-level 흐름
-> 구체 구현 직접 new 하지 않음
-> 인터페이스 또는 계약에 의존
-> 조립은 bootstrapper / installer에서게임 시스템을 설계할 때 인터페이스와 추상 클래스를 언제 고르고 어떻게 섞어 쓰는지 Unity 맥락에서 비교합니다.
계약만 필요
-> interface
공통 기본 구현과 상태 필요
-> abstract classHUD, 인벤토리, 상점, 설정 화면 같은 게임 UI에서 MVP와 MVVM을 어떤 기준으로 고를지 Unity 관점에서 비교합니다.
MVP
View는 표시
Presenter가 흐름 제어
MVVM
ViewModel이 상태/명령 노출
View는 바인딩 중심월드 행렬, 장비 스탯, UI 표시값처럼 원본 데이터에서 다시 계산되는 값을 더티 플래그로 언제 갱신할지 정리합니다.
원본 값 변경
-> dirty = true
-> 필요할 때만 다시 계산
-> 계산 후 dirty = false무기, 스킬, 적 행동처럼 종류가 늘어나는 시스템에서 기존 switch를 덜 건드리도록 OCP를 어떻게 적용할지 Unity 맥락으로 정리합니다.
새 타입 추가
-> 기존 giant switch 수정 반복
-> OCP 약함
새 타입 추가
-> 새 전략 / 새 factory 등록
-> OCP 강함부모 타입 자리에 자식 타입을 넣었을 때 입력 규칙이나 결과 의미가 깨지지 않도록 게임 코드에서 LSP를 어떻게 볼지 정리합니다.
BaseWeapon 자리에 자식 무기 넣었는데
-> 예외 규칙이 늘어남
-> 계약이 깨진 것게임 오브젝트와 시스템이 큰 인터페이스를 억지로 구현하지 않도록 ISP 기준으로 계약을 어떻게 쪼갤지 Unity 맥락에서 정리합니다.
너무 큰 계약
-> 안 쓰는 메서드도 구현
얇은 계약
-> 필요한 기능만 구현같은 모델, 같은 설정, 같은 효과 데이터를 많은 객체가 공유할 때 flyweight 패턴으로 무엇을 공유하고 무엇을 개별 상태로 둘지 정리합니다.
공유 가능한 것
-> mesh / icon / base stat / config
개별 상태
-> hp / position / cooldown / targetUnityEvent, C# event, Action 계열을 게임 UI와 런타임 시스템에서 어떤 기준으로 나눠 쓸지 정리합니다.
Inspector 연결 중심
-> UnityEvent
코드 중심 런타임 이벤트
-> C# event / Action씬 로딩 초기에 공통 서비스와 초기화 순서를 안정적으로 잡기 위해 boot scene과 bootstrapper를 어떻게 둘지 Unity 기준으로 정리합니다.
Boot Scene
-> 공통 서비스 생성
-> 초기 설정 주입
-> 메인 씬 진입5 cards
벡터를 위치값이 아니라 방향과 크기로 읽고, 정규화와 dot/cross를 이동·시야·판정 문제에 어떻게 연결할지 정리합니다.
heading = target - current
direction = normalize(heading)
speedVector = direction * speedlocal, world, view, clip space가 각각 어떤 의미를 가지는지와, transform을 읽을 때 어떤 공간에 있는 값을 보는지 정리합니다.
local -> world -> view -> clip -> screenLerp, Slerp, damping을 같은 것으로 보지 않고, 위치 이동·카메라 추적·회전 보간에서 각각 언제 써야 하는지 정리합니다.
position = lerp(current, target, t)
rotation = slerp(currentRot, targetRot, t)이동, 회전, 크기 변형을 행렬 곱으로 다룰 때 순서가 왜 중요한지와 local-to-world 변환을 어떻게 읽어야 하는지 정리합니다.
modelMatrix = translation * rotation * scale
worldPosition = modelMatrix * localPositionatan2를 이용해 방향 벡터를 각도로 바꾸고, 캐릭터 회전·조준·2D 방향 판정에 어떻게 적용하는지 정리합니다.
direction = target - origin
angle = atan2(direction.y, direction.x)4 cards
점·선·면 같은 기하 용어부터 vertex, rasterization, fragment, depth/blend까지 real-time rendering pipeline의 큰 흐름을 정리합니다.
vertex
-> primitive assembly
-> rasterization
-> fragment
-> depth / blendview matrix, perspective/orthographic projection, depth buffer가 각각 무엇을 하는지와 카메라 문제를 어떻게 읽을지 정리합니다.
world -> view -> projection -> depth testrendering cost를 볼 때 draw call 수만 세지 않고 batching, state change, overdraw를 함께 읽어야 하는 이유를 정리합니다.
같은 mesh/material을 많이 그린다
-> batching / instancing 가능성 확인
겹쳐 그리는 픽셀이 많다
-> overdraw 확인후면을 추려내는 backface culling이 왜 성능과 가시성에 도움이 되는지와, CW/CCW winding을 어떻게 읽어야 하는지 정리합니다.
카메라에서 안 보일 후면 삼각형은
-> rasterization 전에 제외9 cards
매니저, 시스템, 서비스라는 이름을 언제 쓰고 어떤 책임 경계를 기대해야 하는지 설계 판단 관점에서 정리합니다.
Manager
-> 조정과 orchestration
System
-> 규칙 실행과 처리 파이프라인
Service
-> 재사용 가능한 기능 제공어떤 데이터와 규칙을 어느 서비스가 소유해야 하는지, 그리고 경계를 넘는 책임을 어떻게 줄일지 설계 판단 관점에서 정리합니다.
한 서비스가 소유해야 할 것
-> 자기 데이터
-> 자기 규칙
-> 자기 상태 변화
남의 데이터까지 직접 고치기 시작
-> 경계가 흐려짐서비스와 시스템을 연결할 때 event-driven 구조가 맞는지, 아니면 직접 호출이 더 단순한지 판단 기준 중심으로 정리합니다.
한 결과를 여러 곳이 들어야 함
-> event
순서와 성공 여부가 중요함
-> direct call객체 조립을 어디서 끝내고 런타임 흐름 시작을 어디서 넘길지, composition root와 bootstrap 경계를 설계 판단 관점에서 정리합니다.
Composition Root
-> 의존성 조립이 끝나는 곳
Bootstrap
-> 앱/게임 시작 순서를 여는 곳
둘을 섞으면
-> 초기화 순서와 wiring이 같이 꼬임에디터에서 만드는 데이터와 플레이 중 바뀌는 상태를 어디서 분리해야 하는지 설계 판단 관점에서 정리합니다.
Authoring Data
-> 디자이너가 만든 원본 설정
Runtime State
-> 플레이 중 변하는 값
원본과 상태를 같이 들고 다니면
-> 저장/리셋/복제가 꼬임씬이 바뀔 때 어떤 의존성을 씬 내부에서 조립하고 어떤 것은 상위 루트에서 넘길지 Scene DI 경계를 설계 판단 관점에서 정리합니다.
씬 안에서만 쓰는 것
-> scene scope
여러 씬이 공유하는 것
-> app/root scope
씬 로딩 때마다 전역 resolve 남발
-> 경계가 흐려짐매니저가 언제 생성되고 언제 해제돼야 하는지, 종료 책임을 어디까지 가져가야 하는지 설계 판단 관점에서 정리합니다.
Manager가 오래 산다고
-> 전역이어야 하는 것은 아님
생성 시점
-> scope 기준
해제 시점
-> owner 기준게임 시작 이후에도 모드 전환이나 feature loading 시점에 조립 지점이 필요한 경우, runtime composition root를 어디까지 둘지 설계 판단 관점에서 정리합니다.
초기 composition root
-> 앱 시작 조립
Runtime composition root
-> 모드/feature 진입 시 재조립
아무 곳에서 resolve
-> root가 사라짐이벤트 이름과 payload를 어디까지 구체적으로 설계해야 하는지, broad event와 narrow contract 사이 경계를 설계 판단 관점에서 정리합니다.
이벤트 이름
-> 무슨 일이 끝났는지 말해야 함
payload
-> 수신자가 실제로 필요한 만큼만
generic event 하나
-> 결국 분기와 캐스팅 증가