Start Building

Before you write a single line of code or place a single mesh, you need to decide what FPS you are actually building and how its systems will fit together. A clear design and technical architecture up front will save you from rebuilding movement, weapons, and AI three times as the project grows.

In this lesson you will:

  • Define a one-sentence pitch and target player experience for your shooter.
  • Choose a feature set for your first vertical slice so scope stays under control.
  • Sketch a high-level systems diagram that ties movement, weapons, AI, and levels together.
  • Capture these decisions in a lightweight design and tech doc you can keep updating.

Step 1: Write your FPS one-sentence pitch

Start with a simple, concrete statement:

"It is a fast-paced arena FPS where players surf and dash through low-gravity corridors while fighting heavily telegraphed melee enemies."

Or:

"It is a slower, tactical corridor shooter where sound and line of sight matter more than raw reflexes."

In your doc, include:

  • Player fantasy: what does it feel like to play at a high level?
  • Core verbs: move, aim, shoot, reload, dash, interact, throw, etc.
  • Primary constraints: solo only, co-op later, no PvP, or LAN only.

Everything else in the course should support this pitch instead of fighting it.

Step 2: Choose your first vertical slice

Instead of promising a full campaign, focus on one replayable level that proves your core loop.

Decide:

  • Environment type: indoor lab, industrial hangar, canyon, space station, etc.
  • Encounter structure: one intro room, two combat arenas, one mini-boss or finale.
  • Enemy mix: for now, 1–2 enemy archetypes you can refine over time.
  • Win and fail conditions: clear objective and how a run ends.

Write this as a short bullet list, not a novel. You should be able to read the slice description in under 30 seconds and immediately understand what you are building.

Step 3: Map your core systems

Now sketch the big systems and how they talk to one another. You can do this on paper, a whiteboard, or a simple diagram tool.

Include at least:

  • Player controller: movement, camera, input mapping, sprint/crouch/jump, interaction.
  • Weapon system: weapon data, firing logic, ammo, reloads, hit detection, recoil.
  • Health and damage: player health, enemy health, damage types, invulnerability windows.
  • AI system: perception (sight/hearing), state machines/behaviour trees, pathfinding.
  • Level flow: spawners, checkpoints, doors, triggers, objectives.
  • UI: HUD, crosshair, health/armor, ammo, interaction prompts.

Draw arrows to show data flow, for example:

  • Input → Player Controller → Weapon Component → Projectile → Damage System → Enemy.
  • Enemy Perception → AI Controller → Blackboard/State → Movement Component.

The goal is not to perfect every detail now, but to prevent hidden coupling later.

Step 4: Decide on Blueprints vs C++

Unreal lets you mix Blueprints and C++; for this course you should choose a default and a rule for exceptions.

Common patterns:

  • Use Blueprints for high-level gameplay scripting, level-specific logic, and quick iteration.
  • Use C++ for performance-critical systems, shared base classes, and low-level utilities.

In your tech doc, add a short section:

  • Which classes will almost certainly live in C++ (for example BaseWeapon, BaseCharacter, DamageType)?
  • Which systems you expect to implement mainly in Blueprints (for example, level events, UIs, simple AI variations)?

This avoids a project where half your systems are duplicated between C++ and Blueprints with no plan.

Step 5: Define your data foundations

Good FPS projects treat data as a first-class citizen.

Decide:

  • How you will store weapon data (Data Assets, Data Tables, or config structs).
  • How you will represent enemies (base enemy class with child Blueprints or composition via components).
  • How you will store level configuration (spawner configs, encounter definitions, difficulty curves).

Write a brief table in your doc that lists:

  • System → Data container → Example fields.

For example:

  • Weapons → Data Asset → name, damage, fireRate, recoilPattern, ammoPerClip.
  • Enemies → Blueprint child of ABaseEnemy → health, moveSpeed, behaviorProfile, rewardXP.

Step 6: Choose your project folder conventions

A messy Content Browser kills iteration speed.

Set up top-level folders such as:

  • /Game/Core for shared systems and base classes.
  • /Game/Characters for player and enemies.
  • /Game/Weapons for weapon Blueprints, meshes, and VFX.
  • /Game/Levels for maps and level-specific scripts.
  • /Game/UI for widgets and HUD elements.
  • /Game/Audio for SFX and music.

Document these conventions in your tech doc, then create the empty folders in your project so future lessons can follow them.

Step 7: Outline your first three implementation lessons

To keep the course grounded in outcomes, quickly outline what you expect to tackle in Lessons 2–4.

For example:

  • Lesson 2 – FPS movement and camera: sprint, crouch, and jump in a graybox level.
  • Lesson 3 – Basic weapon and shooting loop with hit markers and debug visualization.
  • Lesson 4 – Health, damage, and death flow for player and a simple dummy enemy.

You do not need full scripts yet; just enough detail so you can check that the architecture you defined supports them.

Mini exercise

Take 30–45 minutes to:

  1. Write your one-sentence pitch and vertical slice description.
  2. Sketch a simple systems diagram with boxes and arrows.
  3. Decide your Blueprint vs C++ rules and note them in your doc.
  4. Create the initial folder structure inside your Unreal project to match this plan.

Keep this doc open while you work through the rest of the course and update it any time you make a significant decision.

Common mistakes to avoid

  • Trying to design every weapon and enemy type up front instead of focusing on one slice.
  • Mixing random folder structures from different tutorials into the same project.
  • Spreading the same responsibility across Blueprints and C++ with no clear owner.
  • Ignoring level flow and encounter pacing until the end of development.

If you feel stuck, reduce scope: one level, one weapon, one enemy, one clear win condition.

What is next

In the next lesson you will implement the player controller and camera for your FPS and test movement in a simple blockout level. With your design and architecture in place, those decisions will plug straight into the systems you just outlined instead of being throwaway prototypes.