Core Concepts

Five ideas explain most of how ShmupKit is put together. Read this once and the rest of the documentation will make sense faster.

1. The camera doesn't move — the world does

The camera holds a fixed position along the scroll axis and pans sideways to follow the player. It is the terrain that moves, carried by a single scrolling actor with every piece of scenery parented beneath it. One tick moves the entire level.

This single decision explains several rules elsewhere:

• Anything that should feel part of the world must be attached to the scrolling background — scenery, spawners, explosions.
• An enemy flying sideways never changes its scroll-axis position, which is why sideways spawns need Entry Depth to anchor them to the camera instead.
• Off-screen tests only ever use the top and bottom edges. The side edges move as the camera pans, so testing them would delete or protect things that were still plainly visible.

2. Data assets, not Blueprint logic

Weapons, levels, formations, paths, drop tables and pickup variants are all data assets. Building content means filling in fields, not wiring graphs. The practical benefit is reuse: one projectile serves a dozen weapons, one path serves both sides of the screen, one pickup Blueprint becomes every collectible in the game.

The kit's own Blueprints (BP_GameMode, BP_PlayerPawn and the rest) are thin — they exist to hold asset references, not behaviour.

3. Almost everything is pooled

Projectiles, enemies, pickups and floating numbers are recycled rather than created and destroyed. A stage that fires thousands of bullets does no allocation once it is running.

The one consequence worth internalising: a pooled actor is hidden, not destroyed. It is the same object coming back, so any state written to it must be reset when it is reused. The kit does this for everything it owns; if you add your own state, see Object Pooling.

4. Systems strip out cleanly

Optional components are genuinely optional. No energy component means energy weapons fire for free. No shield component means damage goes straight to health. No magnet means pickups sit where they land. Nothing errors, and nothing needs reconfiguring.

This works in both directions, so you can ship a simple game and add a system later without touching the assets you already authored.

5. Zero and None mean "don't override"

A convention used consistently across the kit. Wherever a field could override something else, 0 or None leaves the original value alone rather than setting it to zero.

Field	Zero means
Move Speed Override	Keep the enemy's own speed
Health Override	Keep its own max health
Emergency Health Threshold	The feature is off entirely
Path Move Speed	Use the enemy's speed
Retarget Interval	Never re-target
Beam Duration	Stay on while held

Durations are the one place to be careful: an invulnerability duration of 0 grants nothing rather than lasting forever. Permanent immunity is a separate flag.

Class map

What to subclass in Blueprint, and what to just place or configure.

Class	You typically
SKGameModeBase	Use the shipped BP_GameMode, or subclass to add rules
SKPlayerPawnBase	Subclass once, for your ship
SKEnemyBase	Subclass per enemy type
SKBossBase / SKBossPart	Subclass per boss and per part
SKProjectileBase and variants	Subclass per projectile
SKPickupBase	Subclass once; vary it with definitions
SKHUDWidget / SKResourceBarWidget / SKHUDItemWidget	Reparent your widgets to these
SKCameraDirector / SKScrollingBackground / SKScrollSpawner / SKWaveDirector	Place in the level and configure
SKPoolSubsystem / SKRunStateSubsystem / SKSaveSubsystem	Nothing — they exist automatically

Where next