Game Programming Fundamentals Questions

Summary of trade-offs

Value types (C# structs) store data inline; reference types (classes) live on the heap with a pointer. That difference drives copying cost, memory layout, GC behavior, and alignment—critical in hot loops and large arrays for games.

Memory layout & caching

• Struct arrays are contiguous: good cache locality for physics/renderer data (positions, velocities).
• Class arrays hold contiguous references but scattered objects -> poor locality and more cache misses.

Copying costs

• Small, immutable structs (<=16 bytes) are cheap to copy; large structs incur heavy stack/stack-frame or memcpy overhead when passed by value.
• Classes pass a pointer cheaply; mutation without copying.

Garbage collection

• Lots of short-lived class instances increase GC pressure and frame spikes. Structs avoid GC if stored in arrays or on the stack.
• Beware boxing: storing a struct in object or IEnumerable<T> causes heap allocation and boxing cost.

Alignment & padding

• Struct field ordering affects alignment and size; pack frequently accessed fields together to reduce padding.
• Use explicit layout or reorder fields to minimize size.

Recommendations for games

• Use small POD structs for arrays of components (positions, normals, transforms) for physics/rendering.
• For mutable large state, prefer classes or store big data in arrays and use indices to avoid copying.
• Mark structs readonly when immutable; pass by ref/in to avoid copies.
• Avoid virtual methods on hot structs; avoid boxing (use generics where possible).
• Profile: measure cache misses, GC allocations, and memcpy costs. Optimize based on hotspots.

Example patterns: Native arrays / Unsafe/Span or Unity’s ECS/NativeArray for predictable layout and minimal GC.

Approach (short)
Use composition + strategy + data-driven config: decompose weapon into independent components (FiringMode, DamageCalculator, Ammo, Modifier). Wire components in code or via JSON to avoid subclass explosion.

Interfaces / classes (C# sketch)

public interface IFiringMode { void Fire(WeaponContext ctx); }
public interface IDamageCalc { Damage Calculate(WeaponContext ctx); }
public interface IAmmo { bool Consume(int amount); int Count {get;} }
public interface IModifier { void Apply(ref Damage dmg, WeaponContext ctx); }

public class Weapon {
  public string Id;
  public IFiringMode Firing;
  public IDamageCalc DamageCalc;
  public IAmmo Ammo;
  public List<IModifier> Modifiers;
  public void Trigger() {
    if (!Ammo.Consume(1)) return;
    Firing.Fire(new WeaponContext(this));
  }
}

Example components

class SingleShot : IFiringMode { void Fire(WeaponContext ctx){ var dmg=ctx.Weapon.DamageCalc.Calculate(ctx); ApplyMods(dmg); SpawnProjectile(dmg);} }
class ShotgunSpread : IFiringMode { /* spawn N pellets */ }
class BaseDamage : IDamageCalc { /* uses weapon stats */ }
class ArmorPiercing : IModifier { /* reduce armor */ }

Data-driven wiring (JSON)

{
 "id":"sg_shotgun",
 "firing":"ShotgunSpread",
 "damage":"BaseDamage",
 "ammo":"Shells",
 "modifiers":["Scatter","Knockback"]
}

Runtime composition
Factory/DI maps names to component instances or parameterized factories, loads JSON, composes Weapon by resolving component classes.

Why this works

• Adds behavior orthogonally, avoids combinatorial subclasses
• Designers tweak JSON to create new weapons quickly
• Unit-testable components, hot-reloadable in editor for rapid iteration

Edge cases / notes

• Ensure stat/param inheritance (base template + overrides)
• Handle stateful modifiers (cooldowns) and network serialization for multiplayer.

Overview of each pattern

Factory: Encapsulates creation logic in a factory class or method. Client asks Factory.Create(type, params) and receives a new entity initialized per type. Good for deciding which subclass/config to instantiate at runtime.

Prototype: Stores prototypical objects (blueprints). To spawn, you clone an existing prototype and then tweak properties. Useful when copying complex state is cheaper than building from scratch.

Concrete use case — spawning enemies with slight variations

• Factory: Factory.Create("Goblin", difficulty=2, skin="green") constructs a Goblin, picks model, equips weapons, applies modifiers.
• Prototype: Designer places several Goblin prototypes (base, armored, fast). Spawner clones a prototype then randomizes health ±10%, color tint, and attach loot.

Pros / Cons

• Performance:
  • Factory: construction cost can be higher if setup is heavy (loading components); but pooling inside factory mitigates allocation spikes.
  • Prototype: cloning (shallow/deep) is typically faster than full construction; combined with object pools gives lowest spawn latency.
• Memory:
  • Factory: fewer persistent blueprints; may need more transient allocations unless pooling used.
  • Prototype: stores full prototypes in memory (models, components) — small overhead but enables faster clones.
• Designer-driven iteration:
  • Factory: designers need asset/config changes wired into factory logic or JSON data; requires developer support for new combinations.
  • Prototype: very designer-friendly — prototypes are editable in editor (prefabs), enabling rapid iteration without code changes.

Recommendation
Use Prototype (prefabs + pooling) for high-frequency, slight-variation enemies for performance and designer flexibility. Use Factory for conditional logic, server-side authoritative creation, or when construction involves complex rules that centralize behavior.

Approach summary
I’d attack CPU skinning by (1) restructuring data for vectorization, (2) implementing SIMD skinning kernels, (3) making memory/cache friendly, and (4) parallelizing across meshes/mesh chunks. Measure before/after with microbenchmarks and real scenes.

Data layout & cache

• Convert vertex stream from AoS (pos,norm,weights,indices) to SoA: separate float4 arrays for positions, normals, and small packed weight/index arrays.
• Pack 4 vertices per SIMD lane if using SSE/AVX; align arrays to 16/32 bytes.
• Reorder vertices by mesh/chunk to increase spatial locality; prefetch next chunk for large bones.

SIMD intrinsics

• Write an inner kernel that loads 4 positions, loads 4 bone matrices (broadcast per bone), multiplies and accumulates weighted transforms.
• Example SSE/AVX pattern (simplified AVX2 for 8-wide floats):

 // loads: posX[], posY[], posZ[], weight[]
 __m256 px = _mm256_load_ps(&posX[i]);
 __m256 py = _mm256_load_ps(&posY[i]);
 __m256 pz = _mm256_load_ps(&posZ[i]);
// load and broadcast matrix rows per bone, multiply-add weighted
 __m256 outX = _mm256_setzero_ps();
 // for each bone influence (0..3)
 outX = _mm256_fmadd_ps(px, mat_r0_x, outX); // multiply-add pattern

• Use fused-multiply-add where available; eliminate gathers by organizing bone transforms per-batch or using 4x4 transposed matrices to reduce shuffles.

Multithreading

• Parallelize by mesh, submesh, or vertex-chunk; avoid per-vertex locks.
• Use job system/task queues with chunk sizes tuned to keep threads busy but limit overhead (~1–8k vertices chunk).
• Reduce NUMA cross-talk: pin worker threads or allocate per-thread scratch buffers.

Pitfalls

• Precision: SIMD FP ordering changes associative results; validate skinning tolerances and use float32 or mixed precision carefully.
• Alignment: misaligned loads cost cycles—use aligned allocators or use unaligned intrinsics if necessary.
• Thread overhead: excessive fine-grained tasks degrade perf; measure and pick chunk size.
• Scatter/gather: AVX-512 gathers still slow; prefer data layout changes to avoid gathers.
• Register pressure/shuffles: balance kernel complexity; microprofile.

Measurement

• Baseline: measure skinning time and frame time on representative scenes (CPU profiler sampling + high-resolution timers).
• Microbenchmarks: isolate kernel throughput (vertices/sec) and memory bandwidth.
• Tools: VTune, RenderDoc CPU trace, platform profilers. Measure wall-clock, cache misses, branch mispredictions, SIMD utilization.
• Iterate: A/B test each change, quantify % frame time saved and impact on tail latency.

Approach (brief)

• Use explicit horizontal acceleration and friction in a fixed-step update.
• Clamp horizontal speed to maxSpeed.
• Apply a single jump impulse when grounded and jumpPressed is true.
• Integrate velocity -> position using simple Euler integration (deterministic for fixed deltaTime).

using System.Numerics;

public static Vector2 SimulatePlayerMovement(
    Vector2 position,
    Vector2 velocity,
    float moveAxis,        // -1..1 input
    bool jumpPressed,
    bool isGrounded,
    float deltaTime)
{
    // Tunable parameters (deterministic constants)
    const float accel = 50f;        // horizontal acceleration units/s^2
    const float maxSpeed = 8f;      // horizontal max speed units/s
    const float friction = 30f;     // friction deceleration when no input units/s^2
    const float gravity = -30f;     // gravity units/s^2 (negative downwards)
    const float jumpVelocity = 12f; // upward impulse units/s

    // Horizontal movement
    if (MathF.Abs(moveAxis) > 0.0001f)
    {
        // Accelerate toward input direction
        velocity.X += moveAxis * accel * deltaTime;
    }
    else
    {
        // Apply friction to reduce horizontal velocity toward zero
        float sign = MathF.Sign(velocity.X);
        float decel = friction * deltaTime;
        if (MathF.Abs(velocity.X) <= decel)
            velocity.X = 0f;
        else
            velocity.X -= sign * decel;
    }

    // Clamp horizontal speed
    velocity.X = MathF.Clamp(velocity.X, -maxSpeed, maxSpeed);

    // Jump: only apply when grounded and jump pressed
    if (jumpPressed && isGrounded)
    {
        velocity.Y = jumpVelocity; // set upward impulse
        isGrounded = false;        // caller should use collision to reset grounded
    }

    // Gravity always applies (deterministic)
    velocity.Y += gravity * deltaTime;

    // Integrate position
    position += velocity * deltaTime;

    return position; // caller should keep velocity state between steps
}

Integration into FixedUpdate

• Store and pass persistent position and velocity between calls.
• Call this method at a fixed timestep (e.g., 1/60s). Example loop:
  • velocity/position = SimulatePlayerMovement(position, velocity, inputX, jumpPressed, isGrounded, fixedDeltaTime)
  • After integration, run collision resolution which may correct position/velocity and set isGrounded.
• Keep all parameters deterministic and avoid frame-dependent logic so simulations stay repeatable.