Reference

Game Programming

게임 루프, 패턴과 구조, 설계 판단, 게임 수학, 좌표계, 카메라, 렌더링 파이프라인까지 게임 프로그래밍의 핵심 흐름을 카드형 레퍼런스로 정리합니다.

전체40개

현재40개

레퍼런스 검색

패턴과 구조

Unity 게임 루프에서 frame과 fixed step 나누기

Update·FixedUpdate·LateUpdate의 시간 계약을 구분하고, input sampling·physics simulation·render follow를 섞지 않는 방법입니다.

Vector2 pendingMove;

void Update()
{
    pendingMove = ReadMoveInput(); // 최신 input을 frame마다 수집
}

void FixedUpdate()
{
    body.AddForce(new Vector3(pendingMove.x, 0f, pendingMove.y) * acceleration);
}

void LateUpdate()
{
    cameraRig.Follow(body.position); // simulation 뒤 화면 갱신
}

게임에서 컴포지션과 상속 고르기

기능 조합은 컴포지션으로, 안정적인 종류·공통 계약은 상속 또는 interface로 표현하고 Unity Component 의존성을 관리하는 방법입니다.

public interface IDamageable
{
    void TakeDamage(int amount);
}

public sealed class Enemy : MonoBehaviour, IDamageable
{
    [SerializeField] private Health health;
    public void TakeDamage(int amount) => health.Apply(amount);
}

게임 FSM의 전이와 상태 수명 관리

mode가 다른 행동을 FSM으로 분리하고, OnEnter·Tick·OnExit·pending transition·cancel을 한 전이 계약으로 관리하는 방법입니다.

public interface IState
{
    void OnEnter();
    void Tick();
    void OnExit();
}

public sealed class StateMachine
{
    IState current;
    bool isTransitioning;

    public void Change(IState next)
    {
        if (next == current || isTransitioning) return;
        isTransitioning = true;
        current?.OnExit();
        current = next;
        current.OnEnter();
        isTransitioning = false;
    }

    public void Tick() => current?.Tick();
}

Unity 오브젝트 풀의 반환과 수명 관리

ObjectPool<T>의 get·release·destroy callback, collectionCheck·maxSize, reset·double release·scene unload owner를 정해 반복 생성 비용을 측정하는 방법입니다.

ObjectPool<Projectile> pool = new(
    createFunc: CreateProjectile,
    actionOnGet: p => p.OnGet(),
    actionOnRelease: p => p.OnRelease(),
    actionOnDestroy: p => Destroy(p.gameObject),
    collectionCheck: true,
    defaultCapacity: 32,
    maxSize: 256);

Projectile projectile = pool.Get();
projectile.Launch(origin, direction, () => pool.Release(projectile));

팩토리로 생성과 초기화 경계 만들기

prefab·config·spawn parent·pool·asynchronous load를 호출부에서 분리하고, 생성 뒤 ready·release owner를 명확히 하는 방법입니다.

public interface IEnemyFactory
{
    Enemy Spawn(EnemyDefinition definition, SpawnRequest request);
}

public sealed class EnemyFactory : IEnemyFactory
{
    public Enemy Spawn(EnemyDefinition definition, SpawnRequest request)
    {
        Enemy enemy = Object.Instantiate(definition.Prefab, request.Position, request.Rotation, request.Parent);
        enemy.Initialize(definition, request.Team);
        return enemy;
    }
}

Unity 싱글톤의 수명과 의존성 경계

정말 한 인스턴스여야 하는 Unity 서비스만 singleton으로 두고, duplicate·DontDestroyOnLoad·domain reload·static state와 명시적 bootstrap 경계를 설계하는 방법입니다.

public sealed class AudioService : MonoBehaviour
{
    public static AudioService Instance { get; private set; }

    void Awake()
    {
        if (Instance != null && Instance != this)
        {
            Destroy(gameObject);
            return;
        }

        Instance = this;
        DontDestroyOnLoad(gameObject);
    }

    void OnDestroy()
    {
        if (Instance == this) Instance = null;
    }
}

커맨드 패턴으로 입력과 실행 기록 남기기

입력·AI·replay가 같은 행동 값을 만들고, 실행·기록·취소·부가 효과의 경계를 분리하는 방법입니다.

public interface ICommand
{
    void Execute(GameState state);
}

public readonly record struct MoveCommand(int ActorId, int Dx, int Dz) : ICommand
{
    public void Execute(GameState state) => state.Move(ActorId, Dx, Dz);
}

// Update에서 만든 command를 simulation tick 순서로 적용합니다.
commandQueue.Enqueue(new MoveCommand(playerId, 1, 0));

게임 이벤트에서 observer와 직접 호출 고르기

동기 direct call, C# event, UnityEvent, queued message의 반환·순서·예외·구독 수명 차이를 구분해 게임 이벤트를 설계하는 방법입니다.

public sealed class Health : MonoBehaviour
{
    public event Action<int, int> Changed;

    public void ApplyDamage(int amount)
    {
        currentHp = Mathf.Max(0, currentHp - amount);
        Changed?.Invoke(currentHp, maxHp);
    }
}

void OnEnable() => health.Changed += UpdateBar;
void OnDisable() => health.Changed -= UpdateBar;

게임 행동 strategy의 asset과 runtime 경계

같은 목표를 다른 알고리즘으로 수행할 때 strategy를 쓰고, ScriptableObject definition과 actor별 runtime state·선택·cancel을 분리하는 방법입니다.

public abstract class AttackRule : ScriptableObject
{
    public abstract void Execute(AttackContext context);
}

public sealed class AttackController : MonoBehaviour
{
    [SerializeField] AttackRule rule;
    [SerializeField] AttackContext context;

    public void Attack() => rule.Execute(context);
}

게임 코드에서 SOLID 문제 진단하기

SOLID를 class 수를 늘리는 템플릿이 아니라 변경 요구의 위치, 호출 계약, Unity lifecycle 경계를 진단하는 순서로 사용하는 방법입니다.

요구: 새 무기 규칙 추가
  -> central switch와 call site가 함께 바뀌는가? OCP
  -> 구현을 바꾸면 caller 결과·cleanup이 달라지는가? LSP
  -> consumer가 쓰지 않는 member까지 요구받는가? ISP
  -> gameplay가 구체 scene component를 직접 만드는가? DIP

요구: HUD 또는 저장 형식 변경
  -> combat class까지 같이 바뀌는가? SRP

게임 코드의 책임을 변경 이유로 나누기

입력·movement·combat·presentation·save처럼 함께 바뀌지 않는 이유를 분리하고, Unity MonoBehaviour를 파일 수가 아니라 data flow로 나누는 방법입니다.

InputReader -> MoveCommand -> PlayerMotor -> PlayerState
                                     -> Health / Combat
PlayerState events -> Presenter -> HUD / audio / VFX
SaveService <-> snapshot contract

의존성 역전으로 게임 시스템 연결하기

gameplay 규칙이 구체 MonoBehaviour·singleton 조회에 묶이지 않도록 capability 계약과 bootstrap 조립 지점을 분리하는 방법입니다.

public interface IDamagePopup { void Show(int amount, Vector3 worldPosition); }

public sealed class CombatResolver
{
    private readonly IDamagePopup popup;
    public CombatResolver(IDamagePopup popup) => this.popup = popup;

    public void ResolveHit(Hit hit)
    {
        hit.Target.ApplyDamage(hit.Amount);
        popup.Show(hit.Amount, hit.Position);
    }
}

게임 코드에서 interface와 abstract class 고르기

여러 계층을 가로지르는 capability contract와 공유 state·template method가 있는 base class를 구분하고 Unity MonoBehaviour 상속 제약을 다루는 방법입니다.

public abstract class Ability
{
    public bool TryUse(Actor actor) => CanUse(actor) && UseCore(actor);
    protected abstract bool CanUse(Actor actor);
    protected abstract bool UseCore(Actor actor);
}

public interface ITargetable { bool IsTargetable { get; } }

Unity 게임 UI에서 MVP와 MVVM 고르기

화면 흐름을 코드에서 제어하는 MVP와 UI Toolkit runtime data binding을 쓰는 MVVM을 UI 시스템·갱신 빈도·상태 owner 기준으로 선택하는 방법입니다.

Model: 게임 상태와 규칙을 소유한다.
View: button, label, visual tree를 표현한다.
Presenter/ViewModel: view가 필요한 형태로 state를 연결한다.

입력은 View -> Presenter 또는 command로 전달하고,
저장·전투 규칙을 View가 직접 바꾸지 않게 한다.

더티 플래그로 파생 상태 갱신하기

원본 state와 계산된 cache를 분리하고 변경·조회·재계산·무효화 owner를 정해 오래된 UI와 불필요한 계산을 줄이는 방법입니다.

public sealed class EquipmentStats
{
    private readonly List<Item> items = new();
    private bool totalsDirty = true;
    private Stats cachedTotals;

    public void Add(Item item) { items.Add(item); totalsDirty = true; }

    public Stats Totals
    {
        get
        {
            if (totalsDirty) { cachedTotals = Calculate(items); totalsDirty = false; }
            return cachedTotals;
        }
    }
}

게임 기능을 확장 가능한 축으로 설계하기

새 행동·무기·규칙이 늘어나는 축만 strategy·factory·data definition으로 분리하고 Unity Inspector 직렬화 경계를 명확히 하는 방법입니다.

public abstract class DamageRule : ScriptableObject
{
    public abstract int Calculate(DamageRequest request);
}

public sealed class Weapon : MonoBehaviour
{
    [SerializeField] private DamageRule rule;
    public int Deal(DamageRequest request) => rule.Calculate(request);
}

게임 코드에서 치환 가능한 계약 만들기

base type 또는 interface 자리에 다른 구현을 넣어도 입력·결과·오류·비동기 완료 의미가 유지되도록 game contract를 설계하는 방법입니다.

public interface IRewardGrant
{
    // 호출자는 성공·보류·실패를 결과로 처리한다.
    ValueTask<GrantResult> GrantAsync(RewardRequest request, CancellationToken token);
}

// LocalReward와 OnlineReward는 같은 cancellation·result contract를 지켜야 합니다.

얇은 interface로 게임 시스템 계약 나누기

호출부가 실제로 쓰는 capability만 interface에 두고, 지나치게 큰 game entity 계약과 의미 없는 한 메서드 interface를 피하는 방법입니다.

public interface IDamageable { void TakeDamage(int amount); }
public interface IInteractable { InteractionResult Interact(Interactor actor); }

public sealed class CombatSystem
{
    public void Apply(IDamageable target, int amount) => target.TakeDamage(amount);
}

플라이웨이트로 공유 데이터와 런타임 상태 나누기

ScriptableObject·mesh·material 같은 공유 definition과 actor별 HP·target·cooldown을 분리하고 shared asset 변경 범위를 관리하는 방법입니다.

[CreateAssetMenu]
public sealed class EnemyDefinition : ScriptableObject
{
    public int BaseHp;
    public float MoveSpeed;
    public GameObject Prefab;
}

public sealed class Enemy : MonoBehaviour
{
    private int currentHp;
    public void Initialize(EnemyDefinition definition) => currentHp = definition.BaseHp;
}

UnityEvent, C# event, Action의 호출 계약

Inspector persistent listener, runtime UnityEvent listener, C# event의 발행 권한, Action callback의 반환·수명·refactor 경계를 구분하는 방법입니다.

public sealed class Health : MonoBehaviour
{
    public event Action<int, int> Changed;

    public void ApplyDamage(int amount)
    {
        currentHp = Mathf.Max(0, currentHp - amount);
        Changed?.Invoke(currentHp, maxHp);
    }
}

void OnEnable() => health.Changed += UpdateBar;
void OnDisable() => health.Changed -= UpdateBar;

Unity Boot Scene과 bootstrapper의 시작 경계

공통 app scope를 한 번 조립한 뒤 target scene으로 넘기는 Boot Scene의 초기화·ready·중복 실행·실패·scene unload 경계를 설계하는 방법입니다.

Boot Scene
  -> duplicate boot guard
  -> config / save / required asset load
  -> app composition root 생성
  -> ready 또는 failure 화면
  -> target scene load
  -> scene-local composition 후 gameplay start

공간 분할과 broad phase 후보 줄이기

grid·spatial hash·tree가 narrow phase 이전의 후보만 줄인다는 점과 cell 크기·큰 객체·빠른 이동·정적/동적 데이터 경계를 설계하는 방법입니다.

object bounds 업데이트
  -> grid / hash / tree에서 겹치는 cell 또는 node를 찾음
  -> 후보 pair를 중복 없이 수집
  -> narrow phase에서 shape·layer·rule을 검사
  -> hit / response

게임 수학

Unity에서 벡터와 dot, cross 쓰기

Unity Vector3의 위치·방향·길이, zero vector 정규화, dot의 시야 판정, cross의 축·좌우 판정을 구분해 사용하는 방법입니다.

Vector3 heading = target.position - transform.position;
if (heading.sqrMagnitude <= 0.000001f)
    return; // target과 같은 위치에는 방향이 없습니다.

Vector3 toTarget = heading.normalized;
float facing = Vector3.Dot(transform.forward, toTarget);
bool isInFront = facing > 0f;

// Y-up 평면에서 forward(+Z)의 오른쪽(+X)을 만듭니다.
Vector3 right = Vector3.Cross(Vector3.up, transform.forward).normalized;
float side = Vector3.Cross(transform.forward, toTarget).y;

Unity Transform과 좌표 공간

local·world·view·clip·screen 공간과 Unity Transform의 point·vector·direction 변환을 구분해 위치와 방향을 안전하게 다루는 방법입니다.

Vector3 muzzleLocal = new(0f, 0.1f, 0.8f);
Vector3 muzzleWorld = character.TransformPoint(muzzleLocal); // position + rotation + scale

Vector3 aimLocal = Vector3.forward;
Vector3 aimWorld = character.TransformDirection(aimLocal); // position·scale 제외

Vector3 recoilLocal = new(0f, 0f, -0.2f);
Vector3 recoilWorld = character.TransformVector(recoilLocal); // position 제외, scale 포함

보간, damping, 회전 보간 고르기

Unity에서 정해진 시간의 Lerp, 일정 속도의 MoveTowards, 부드러운 추적의 SmoothDamp, 회전 보간을 구분해 선택하는 방법입니다.

float elapsed;
Vector3 startPosition;

void Update()
{
    elapsed += Time.deltaTime;
    float t = Mathf.Clamp01(elapsed / 0.5f);
    transform.position = Vector3.Lerp(startPosition, target.position, t);
}

Unity 행렬 변환의 순서

Unity의 column-major Matrix4x4에서 TRS 곱의 적용 순서, 부모-자식 누적, point와 vector 변환을 구분하는 방법입니다.

Matrix4x4 localToWorld = Matrix4x4.TRS(position, rotation, scale);

Vector3 worldPoint = localToWorld.MultiplyPoint3x4(localPoint); // 이동 포함
Vector3 worldDirection = localToWorld.MultiplyVector(localDirection); // 이동 제외, scale 포함

// 계층: sword local -> hand local -> character world
Matrix4x4 swordWorld = characterWorld * handLocal * swordLocal;

atan2와 방향 각도 계산

Unity에서 2D 방향 벡터를 각도로 바꾸고, 기준축·radian·degree·wrap-around를 구분해 조준과 회전에 쓰는 방법입니다.

Vector2 delta = targetPosition - originPosition;
float targetDegrees = Mathf.Atan2(delta.y, delta.x) * Mathf.Rad2Deg;

// 스프라이트의 앞면이 +Y라면 +X 기준 각도에서 보정합니다.
float spriteDegrees = targetDegrees - 90f;
transform.rotation = Quaternion.Euler(0f, 0f, spriteDegrees);

// 현재 359도, 목표 1도처럼 경계를 넘어도 -180~180도의 짧은 차이를 반환합니다.
float shortestDegrees = Mathf.DeltaAngle(currentDegrees, targetDegrees);
float nextDegrees = Mathf.MoveTowardsAngle(
    currentDegrees, targetDegrees, turnDegreesPerSecond * Time.deltaTime);

그래픽스와 렌더링

Unity 렌더링 파이프라인의 흐름

Unity에서 culling·rendering·post-processing의 큰 흐름과 vertex·fragment·depth·blend 오류를 서로 다른 진단 지점으로 읽는 방법입니다.

scene object
  -> frustum / occlusion culling
  -> vertex 처리와 primitive 조립
  -> rasterization: fragment 후보 생성
  -> fragment 색 계산
  -> depth / stencil / blend 상태로 framebuffer 합성
  -> post-processing과 display

Unity Camera의 projection과 depth 읽기

perspective·orthographic projection, near·far clipping plane, depth precision, 여러 Camera의 역할을 구분해 가려짐과 z-fighting을 진단하는 방법입니다.

camera 문제 진단 순서
보이지 않음 -> clipping plane / layer / culling
크기 감각 이상 -> projection type / FOV / orthographic size
앞뒤가 깜빡임 -> 겹친 surface / near-far range / depth state
특정 view만 이상 -> 그 Camera의 pipeline·stack·target texture

Unity에서 draw call, batching, overdraw 측정하기

SRP Batcher·static/dynamic batching·GPU instancing의 조건과 우선순위, transparent overdraw를 profiler와 Frame Debugger로 판단하는 방법입니다.

측정 순서
1. target device에서 CPU/GPU frame time을 분리한다.
2. Frame Debugger로 실제 draw sequence와 batch break를 확인한다.
3. Profiler/Rendering overlay에서 SRP Batcher·instancing 적용 여부를 본다.
4. GPU 병목이면 transparent·shader·resolution·overdraw를, CPU 병목이면 setup·culling·batch 조건을 바꾼다.

Unity에서 backface culling과 winding 읽기

Unity shader의 Cull state, mesh winding, double-sided material, 음수 scale의 관계를 구분해 사라지는 면과 불필요한 fragment 처리를 진단하는 방법입니다.

사라진 면을 볼 때
1. Scene/Game view에서 camera 방향을 바꿔 한쪽 면만 사라지는지 확인
2. material 또는 shader의 Cull mode를 임시로 양면으로 바꿔 winding 문제인지 분리
3. mesh import, normal, parent의 negative scale, render pipeline shader를 차례로 확인
4. 원인을 고친 뒤 필요한 면만 그리도록 Cull 상태를 되돌린다

Technical Design

Manager, System, Service의 책임 경계

이름을 관습으로 고르지 않고, flow 조정자·domain rule 처리자·공통 기능 provider의 호출 방향과 state owner를 기준으로 나누는 방법입니다.

BattleFlowManager
  -> CombatSystem.ResolveTurn(command)
  -> RewardService.Grant(reward)
  -> BattlePresenter.Show(result)

CombatSystem은 reward UI를 직접 열지 않고,
RewardService는 battle phase를 직접 바꾸지 않는다.

Service 경계와 state ownership 정하기

상태마다 source of truth와 mutation API를 하나로 정하고, 다른 service는 command·result·notification으로 협력하게 해 저장·동기화·복구 경계를 지키는 방법입니다.

RewardService
  -> InventoryService.TryAdd(itemId, amount)
  -> result: applied / rejected
  -> InventoryChanged notification
  -> SaveCoordinator creates snapshot

InventoryService만 item count를 변경한다.

게임 흐름에서 event와 직접 호출 고르기

동기 direct call의 반환·실패 책임과 event notification의 다중 반응·수명·순서 경계를 나눠 core gameplay 흐름을 설계하는 방법입니다.

DamageResult result = health.TryApplyDamage(request);
if (!result.Applied) return;

// source of truth가 바뀐 뒤 notification을 발행한다.
DamageApplied?.Invoke(result);

Composition Root와 bootstrap의 역할 나누기

dependency를 조립하는 composition root와 앱 시작·전환을 조정하는 bootstrap을 분리하고, ready·실패·dispose owner를 명시하는 방법입니다.

Boot
  -> load config / save / required assets
  -> composition root: services와 entry를 조립
  -> await ready
  -> bootstrap: title, tutorial, gameplay 중 다음 흐름 선택
  -> scope dispose: unsubscribe, cancel, release

Unity authoring data와 runtime state 나누기

ScriptableObject·prefab의 공유 definition과 플레이 중 변하는 actor state·save snapshot을 분리해 reset·복제·저장 범위를 명확히 하는 방법입니다.

[CreateAssetMenu]
public sealed class WeaponDefinition : ScriptableObject
{
    public int baseDamage;
    public float cooldownSeconds;
}

[System.Serializable]
public sealed class WeaponState
{
    public int currentAmmo;
    public float cooldownRemaining;
}

Unity Scene DI의 scope와 reference 경계

app·scene·view scope를 분리해 shared service와 scene-local presenter·spawner를 조립하고, additive scene·unload·late callback을 안전하게 다루는 방법입니다.

AppRoot
  -> SaveService, SettingsService
  -> Load BattleScene
     -> BattleSceneRoot(AppServices)
        -> BattleSystem, EnemySpawner, BattleHudPresenter
     -> Unload: scene scope Dispose()

Manager의 scope와 shutdown owner 정하기

manager라는 이름이 아닌 app·mode·scene·view scope로 수명을 정하고, subscription·async 작업·Addressables handle·pool을 종료하는 owner를 설계하는 방법입니다.

App scope: settings, account session
  -> creates Mode scope: battle flow, match services
     -> creates Scene/View scope: HUD, local input, effects
        -> shutdown: unsubscribe -> cancel -> release -> destroy

Runtime Composition Root의 진입과 해제

battle·shop·minigame처럼 runtime mode에 들어갈 때 필요한 object graph를 한 번 조립하고, entry와 scope disposal을 함께 반환하는 방법입니다.

App root: account, config, telemetry
  -> Battle root: battle state, combat system, HUD presenter
     -> Start
     -> Leave: cancel -> unsubscribe -> release -> dispose
  -> Shop root: catalog, pricing, shop presenter

게임 event 계약과 payload 범위 정하기

notification과 command를 분리하고, event payload에 stable ID·변경값·시점만 넣어 listener·ordering·중복 처리 계약을 명확히 하는 방법입니다.

public readonly struct InventoryChanged
{
    public readonly string ItemId;
    public readonly int PreviousCount;
    public readonly int CurrentCount;
    public readonly string Reason;

    public InventoryChanged(string itemId, int previousCount, int currentCount, string reason)
    {
        ItemId = itemId;
        PreviousCount = previousCount;
        CurrentCount = currentCount;
        Reason = reason;
    }
}

Loading category cards

Preparing references and filters for this topic. 이 주제의 레퍼런스와 필터를 준비하고 있습니다.