Prototype Fast,
Not Twice.

Rapid prototyping isn’t writing disposable code. It’s deciding — fast — what deserves structure and what doesn’t. Unity, in practice.

Mahmoud AglanAL-ArcadeTechne Summit

Open · ⏱ 0:00–1:00

“Hands up: who has built a prototype that worked, and then had to throw it away to build the real thing?” — wait for hands.

“That second build is the most expensive thing in game development. Today is about not paying for it twice.”
Who I am, in one line: we build games and production systems at AL-Arcade, always on a deadline.
Housekeeping: slides are shared at the end, there's a short exercise in the last 10 minutes.

The bill everyone pays

Every prototype is written twice.
The only question is who pays for the second one.— the thing nobody puts in the schedule

Version one

Fast, messy, fun. It proves the game. Written in a week.

Version two

The same game, rebuilt to be changeable. Takes three weeks, feels like zero progress, and ships late.

today

The move

Make version one absorb change instead of resisting it. Four or five decisions, most of them under 15 minutes.

⏱ 1:00–3:00

“Version one is not the problem. Version one is the point. The problem is that version one usually can’t take a single change without breaking.”

Tell a short real story: a jam build or a client prototype where a “small” change cost days.
Land the frame: we’re not trading speed for architecture — we’re buying speed later with 15 minutes now.

What you leave with

Three skills, not a framework.

No new architecture to adopt. Nothing to install. Things you can do on Sunday in the project you already have.

01

Hear the concept

Three sounds your code makes when an idea is hiding inside it — and what to name it.

02

Cut at the seam

Five cheap seams in Unity, the cost of each in minutes, and what each one buys you.

03

Know when not to

The four abstractions that kill prototypes, and a 30-second test to decide on the spot.

⏱ 3:00–4:00

Say plainly: “I am not going to sell you ECS, DI, or a state machine package.”
Promise the takeaway slide at the end — people relax when they know they don’t have to write everything down.

01

Two kinds of fast

One gets you to Friday. The other gets you to launch.

⏱ 4:00

Transition: “First, let’s be honest about what ‘fast’ means.”

Prototype velocity

Fast on day 3. Frozen on day 30.

Both teams “moved fast”. One kept moving.

Week 1Structure costs you time. The messy build is genuinely ahead.

Week 3They cross. This is the week nobody notices, and the one that decides the project.

Week 6One team ships changes daily. The other is “rewriting a few things”.

⏱ 4:00–7:00

“Notice where the lines cross — week three. Before that, structure genuinely slows you down. That’s why this is a judgement call, not a rule.”

If the prototype’s whole life is 5 days (a jam), the red line wins. Say that out loud — it buys you credibility.
Everything after this slide is about buying the green line for 15 minutes, not 3 days.

Where the time actually goes

You are not slow because you type slowly.

One change, five files — and you must hold all five in your head.
Re-deciding things you already decided, because the decision lives nowhere.
The designer waits for you to change a number. Every time.
Fifteen-second recompiles, forty times an hour.
Fear: “if I touch this, what breaks?” — so you copy-paste instead.

→

Every item on that list is coupling or waiting. Neither is fixed by typing faster.

The test that matters

Pick the change your designer asked for yesterday. How many files does it touch, and can they do it without you?

What we’re optimising

Not lines of code. Time from “what if…” to seeing it on screen. That number decides whether the game gets good.

⏱ 7:00–9:00

“Prototyping speed isn’t typing speed. It’s the time between someone saying ‘what if’ and everyone seeing it on screen.”

Ask the room: “what’s your ‘what if’ time right now — minutes? a day?”
Point out the designer line specifically; it's usually the biggest hidden cost in a small team.

The frame for today

Code is disposable.
Concepts are not.throw the code away — keep what you learned it was

You will rewrite the movement code three times.

You will not rewrite the idea that “things that can be hurt” are one kind of thing, that “what a weapon is” is data, and that the UI should never know where the score came from.

★

Structure the concepts. Let the code stay cheap and replaceable.

⏱ 9:00–10:30

“This is the whole talk in one line: code is disposable, concepts are not.”

The next section is only about hearing the concept early — before it costs anything.

02

Hear the concept

Your code makes three distinct sounds when an idea is hiding inside it.

⏱ 10:30

“Three smells. You already know all of them — today they get names.”

Smell 01 · the flag cluster

Five booleans that are really one idea.

grows with every feature

PlayerController.csweek 2

public bool isStunned;
public bool isFrozen;
public bool isBurning;
public bool isInvulnerable;
public bool isDashing;

void Update() {
    if (isStunned || isFrozen) return;
    if (isBurning && !isInvulnerable) Damage(1f);
    // and the 40 lines that handle
    // every combination of the above
}

Conditions.cs12 lines, once

public enum Condition { Stun, Freeze, Burn, Invulnerable }

public class Conditions : MonoBehaviour {
    readonly Dictionary<Condition, float> _until = new();

    public bool Has(Condition c) =>
        _until.TryGetValue(c, out var t) && t > Time.time;

    public void Apply(Condition c, float seconds) =>
        _until[c] = Time.time + seconds;
}

✓

New condition = one enum entry. Duration and stacking are solved once, for everything in the game.

⏱ 10:30–14:00

“When flags travel in a pack, they’re not flags. They’re one concept wearing five hats — a status condition, with a duration.”

The tell: you keep writing if (a || b) with the same group of variables.
Cost here is 12 lines. Payoff: poison, slow, shield, root — all free, and enemies get them too.
Honesty: with two flags that never interact, leave them. It’s the cluster that's the signal.

Smell 02 · copy-paste with one word changed

Three files. One idea.

PlayerHealth · EnemyHealth · CrateHealth

the contract — 1 line

public interface IDamageable {
    void TakeDamage(float amount, GameObject source);
}

the bullet stops caring what it hit

if (hit.collider.TryGetComponent(out IDamageable d))
    d.TakeDamage(damage, gameObject);

✓

Now “destructible barrel” is a prefab, not a programming task.

Health.csone component, everything uses it

public class Health : MonoBehaviour, IDamageable {
    [SerializeField] float max = 100f;
    public float Current { get; private set; }

    public event Action<float> Changed;   // UI, VFX
    public event Action<GameObject> Died; // score, drops

    void Awake() => Current = max;

    public void TakeDamage(float amount, GameObject source) {
        if (Current <= 0f) return;
        Current = Mathf.Max(0f, Current - amount);
        Changed?.Invoke(Current / max);
        if (Current == 0f) Died?.Invoke(source);
    }
}

⏱ 14:00–17:00

“If you can copy a file and make it work by changing one word, that word is the concept — and the file is the duplicate.”

Interface first, one line. The component is boring on purpose.
Two events on Health pay for the UI, the VFX, the score and the drop table without any of them knowing about each other.
Ask: “what else in your game can be hurt? shields? doors? the boss’s three weak points?” — same component.

Smell 03 · the switch that keeps growing

Every new enemy edits the same file.

merge conflicts included

Enemy.csand a fourth type next week

switch (type) {
    case EnemyType.Walker: /* 20 lines */ break;
    case EnemyType.Flyer:  /* 25 lines */ break;
    case EnemyType.Turret: /* 18 lines */ break;
}

behaviour as an assetnew enemy = new asset

public abstract class MoveBehaviour : ScriptableObject {
    public abstract void Tick(Transform self, Transform target, float dt);
}

[CreateAssetMenu(menuName = "AI/Move/Chase")]
public class ChaseMove : MoveBehaviour {
    [SerializeField] float speed = 3f;
    public override void Tick(Transform self, Transform target, float dt) =>
        self.position = Vector3.MoveTowards(self.position, target.position, speed * dt);
}

public class Enemy : MonoBehaviour {
    [SerializeField] MoveBehaviour move;  // drag the asset in
    void Update() => move.Tick(transform, Player.Current, Time.deltaTime);
}

!

A ScriptableObject asset is shared by every enemy using it. Keep per-enemy state on the MonoBehaviour, not in the asset — this is the one trap in this pattern.

⏱ 17:00–20:00

“A switch on a type enum is a list of things the designer can’t make without you.”

Now a designer builds “fast flyer that circles” by making an asset and dragging it on. No code, no recompile.
Say the trap clearly — shared asset state is the bug people hit in week two. Per-instance state stays on the component.
If you only ever have two enemies, the switch is fine. The smell is growth, not the switch.

How to be sure

If you can name it without saying “and”.

A concept has one job and one name. If the name needs “and”, you found two.

What you were going to call it	What it actually is	Why it matters
PlayerManager	Input · Motor · Health · Inventory	Four things one file, four reasons to edit it, four ways to break it.
EnemyAIAndSpawner	Behaviour · Spawner	The “and” is doing the work of a folder.
GameManager	GameFlow · Score · Save	The file everyone edits, and nobody dares delete.
Health	Health	One job. This one is already a concept — keep it.

★

Naming is the design work. When the name gets easy, the code gets easy.

⏱ 20:00–22:00

“Before you write a class, say what it does in one sentence. If the sentence has an ‘and’, you’re about to write two classes in one file.”

“Manager” is almost always an “and” in disguise.
Invite one example from the room and name it live — this is the moment the room gets involved.

The one every Unity project has

The 600-line PlayerController.

Nobody wrote it. It accumulated.

01

Input

Where intent comes from. Swap for AI, replay, or a tutorial that plays itself.

02

Motor

Turns intent into movement. The part you will rewrite three times.

03

Abilities

Dash, shoot, interact. Each one an asset a designer can tune.

04

Health

Already shared with every enemy and crate in the game.

→

Splitting it is 30 minutes of cutting, no new logic. And it makes “the enemy can be possessed by the player” a 10-minute feature instead of a rewrite.

⏱ 22:00–24:00

“Four concepts, and you can find them in any player controller in this room right now.”

The possession example is the killer: with Input separated, an AI brain drives the same motor.
Stress: this is cut-and-paste surgery, not a redesign. Half an hour.
This is also the exercise we do at the end — flag that now.

03

Cut at the seam

Five seams, cheapest first. Each one costs minutes — and each buys back a category of change.

⏱ 24:00

“Now: where to cut. And the answer is never ‘everywhere’.”

The only question

What varies — and who changes it?

The answer picks the seam for you. You don’t need taste, you need this table.

What varies	The seam	Cost	In Unity
Numbers a designer tunes	data	5 min	ScriptableObject asset with [CreateAssetMenu]
Kinds of the same thing	interface	2 min	IDamageable, IInteractable + TryGetComponent
Who reacts to an event	event	10 min	C# event, or a ScriptableObject channel across scenes
How one step is done	strategy	15 min	abstract ScriptableObject, dragged into the inspector
Parts of an object	composition	30 min	small MonoBehaviours on a prefab instead of one class

⏱ 24:00–26:00

“Don’t ask ‘what’s the right architecture’. Ask ‘what varies, and who changes it’. If the answer is a designer, it’s data. If it’s another system, it’s an event.”

Costs are honest, measured in minutes — say they’re from our own projects.
Next five slides: one seam each, with the code.

Seam 01 · data

Numbers belong in assets, not code.

cheapest thing in this talk

WeaponDef.cs5 minutes

[CreateAssetMenu(menuName = "Game/Weapon")]
public class WeaponDef : ScriptableObject {
    public float damage = 10f;
    public float fireRate = 6f;   // per second
    public int   magazine = 12;
    public GameObject projectile;
    public AudioClip shot;
}

What it buys

Pistol, shotgun and “the one that shoots cats” are three assets. No new code, no recompile, and your designer makes them.

The bonus nobody expects

Tuning during play mode. Changes to an asset survive exiting play mode — unlike values on a scene object.

!

Runtime state does not go here. currentAmmo lives on the weapon instance; the asset is the recipe, not the meal.

⏱ 26:00–29:00

“This is the highest return on five minutes in Unity. If you take one thing home, take this one.”

Demo-able live in 60 seconds if you have a project open.
The play-mode point is the one that makes designers happy — balance without stopping the game.
The trap: writing ammo/cooldown into the asset. Say it, people do it constantly.

Seam 02 · interface

Two minutes to stop caring what it is.

3 lines

Interactable.cs

public interface IInteractable {
    string Prompt { get; }          // "Open", "Talk", "Pick up"
    void Interact(GameObject who);
}

// the player never learns what a door is
void TryInteract() {
    if (Physics.Raycast(eye.position, eye.forward, out var hit, 2.5f)
        && hit.collider.TryGetComponent(out IInteractable it))
        it.Interact(gameObject);
}

What it buys

Doors, chests, NPCs, the vending machine you add on Thursday — none of them touch the player script.

don’t

One implementation, no second in sight

An interface with a single implementer is a rename with extra steps. Wait for the second real case.

⏱ 29:00–31:00

“The interface isn’t for polymorphism theory. It’s so the player script stops growing every time we add a thing in the world.”

Prompt in the interface is the practical touch — the UI text comes from the object, so the HUD needs no switch either.
Balance it with the “don’t”: single-implementation interfaces are the most common premature abstraction in game code.

Seam 03 · events

The UI should never know where the score came from.

10 min

IntEvent.cs — a channel as an asset

[CreateAssetMenu(menuName = "Game/Events/Int")]
public class IntEvent : ScriptableObject {
    public event Action<int> Raised;
    public void Raise(int value) => Raised?.Invoke(value);
}

// gameplay — knows nothing about UI
[SerializeField] IntEvent scoreChanged;
scoreChanged.Raise(score);

// HUD — in another scene, zero references
void OnEnable()  => scoreChanged.Raised += Render;
void OnDisable() => scoreChanged.Raised -= Render;

What it buys

Additive scenes, a HUD you can delete, an audio system that reacts to gameplay it has never heard of.

!

Always unsubscribe in OnDisable. A ScriptableObject outlives your scene — that’s the point, and the bug.

don’t

Events inside one system

Within a system, call the method. Events across systems, calls within them — otherwise you lose the call stack and debugging gets slow.

⏱ 31:00–34:00

“This is the one that makes a prototype feel like a product: the HUD, the audio and the save system all listen, and gameplay doesn’t know they exist.”

Say the rule of thumb twice — events across systems, direct calls inside a system.
Mention the debugging cost honestly: a full event bus makes “who changed this?” hard. That’s why it’s a boundary tool.

Seam 04 · composition

Prefabs of parts, not a class tree.

Enemy : Character : Entity : MonoBehaviour

inheritance

The flying enemy that can’t fly

Week 4: you need one enemy that swims. It inherits Walker. Now you’re moving methods up and down a tree instead of making a game.

composition

Parts on a prefab

Health + Mover + Shooter + Loot. A swimming enemy is a different set of parts, made in the editor in a minute.

parts talk through the object, not each other

[RequireComponent(typeof(Health))]
public class Loot : MonoBehaviour {
    [SerializeField] LootTable table;

    void Awake() => GetComponent<Health>().Died += Drop;

    void Drop(GameObject killer) {
        foreach (var item in table.Roll())
            Instantiate(item, transform.position, Quaternion.identity);
    }
}

⏱ 34:00–36:00

“Unity is already a composition engine. The prefab is the class — components are the parts.”

The loot example shows parts wiring themselves through an event, so no part references another by type.
Caveat for honesty: a shallow base class for shared boilerplate is fine. It's the four-level tree that hurts.

Seam 05 · the spine

A game state machine in 20 lines.

No package. No graph editor. No plugin to learn on a deadline.

GameFlow.cs

public enum Phase { Boot, Menu, Playing, Paused, GameOver }

public class GameFlow : MonoBehaviour {
    public static GameFlow I { get; private set; }
    public Phase Phase { get; private set; }
    public event Action<Phase> Changed;

    void Awake() => I = this;

    public void Go(Phase next) {
        if (next == Phase) return;
        Phase = next;
        Time.timeScale = next == Phase.Paused ? 0f : 1f;
        Changed?.Invoke(next);
    }
}

What it buys

Pause, game over, menu and the “press any key” screen stop being booleans scattered across five scripts.

Why so small

Every screen and system asks one place what’s happening. When you outgrow it, you replace 20 lines — not a dependency.

★

One singleton for flow is pragmatic. A singleton for gameplay state is a trap — that's the next section.

⏱ 36:00–38:00

“You do not need a state machine package for a prototype. You need five named phases and one event.”

timeScale in one place is the small detail that saves an evening of pause bugs.
Admit the singleton: it's deliberate, it's for flow only, and it's 20 lines to delete.

04

The first hour

What we set up before writing any gameplay — and why it pays for itself by Thursday.

⏱ 38:00

“Practical part: this is our own checklist at AL-Arcade when a new prototype starts.”

Sprint zero

Six things, sixty minutes.

Do these before the first mechanic, not after the first crisis.

01
Folders by feature
/Player, /Enemies, /UI — each with its own scripts, prefabs, art. Not /Scripts, /Prefabs, /Materials.
02
One Tuning asset
The numbers everyone argues about, in one ScriptableObject, editable in play mode.
03
GameFlow with five phases
The 20 lines from the last slide. Everything else asks it.
04
A debug panel on F1
God mode, skip level, spawn, time scale. The single biggest velocity win.
05
Play mode without domain reload
Project Settings → Editor. Entering play mode goes from 8 seconds to instant.
06
A bootstrap scene
Loads any level by name, so nobody’s work depends on which scene is open.

⏱ 38:00–41:00

“One hour, before any gameplay. Every one of these is about the loop between an idea and seeing it.”

Feature folders are also how you delete a feature cleanly — select folder, delete, done.
Domain reload: mention the cost — static state no longer resets, so reset it deliberately. Worth it.

The underrated one

The cheat panel is a feature.

20 lines · saves hours

DebugPanel.csugly on purpose

public class DebugPanel : MonoBehaviour {
    bool _open;

    void Update() {
        if (Input.GetKeyDown(KeyCode.F1)) _open = !_open;
    }

    void OnGUI() {
        if (!_open) return;
        GUILayout.BeginArea(new Rect(12, 12, 230, 320), GUI.skin.box);
        if (GUILayout.Button("Kill all enemies")) Wave.KillAll();
        if (GUILayout.Button("Give 1000 gold"))   Wallet.Add(1000);
        if (GUILayout.Button("Skip level"))       GameFlow.I.Go(Phase.GameOver);
        Time.timeScale = GUILayout.HorizontalSlider(Time.timeScale, 0f, 4f);
        GUILayout.EndArea();
    }
}

Why it wins

Testing the boss means reaching the boss. Twenty times a day. This button is worth more than any optimisation you’ll do this month.

Use OnGUI, deliberately

It’s slow and it’s ugly — so nobody is ever tempted to ship it, and nobody spends an afternoon styling it.

★

Time scale at 0.2 is also your slow-motion debugger for anything that “feels wrong”.

⏱ 41:00–43:00

“Every hour you spend replaying level one to test level three is an hour stolen from making the game good.”

Push the room: “what would be on yours?” — get two or three answers.
Slow-mo tip lands well with anyone doing game feel work.

05

And now: don’t

Half of prototyping fast is knowing which structure not to build.

⏱ 43:00

“I’ve spent 40 minutes telling you to add structure. Now the other half.”

The four that kill prototypes

Structure you will regret by Friday.

01

An event for everything

When every call is an event, no stack trace tells you who did what. Debugging goes from seconds to an afternoon.

02

Interfaces with one implementation

IPlayerService, IInventoryService, one class each. That’s not flexibility, it’s typing.

03

The manager of managers

A GameManager holding fourteen references, initialised in an order only you understand — and only today.

04

Framework first

DI container, full ECS, netcode, a save system — before anyone knows whether the game is fun. Build the fun first.

→

All four share one tell: they’re built for a future you have not seen yet.

⏱ 43:00–46:00

“Every one of these, I have done. The ECS one cost me two weeks on a game that turned out not to be fun.”

Be specific and self-deprecating — credibility comes from your own scars, not from warnings.
Tie back: seams are for variation you can see today.

The principle behind all four

Duplication is far cheaper
than the wrong abstraction.— Sandi Metz

Copy-paste is reversible in 30 seconds.

A wrong abstraction is not: everyone builds on it, it grows parameters and flags, and by the time it’s clearly wrong it has twelve callers. That’s the rewrite you’re trying to avoid.

★

When unsure: duplicate, and wait for the third case. Then you’ll know the shape instead of guessing it.

⏱ 46:00–48:00

“If you remember one sentence from someone smarter than me: duplication is cheaper than the wrong abstraction.”

Rule of three, prototype edition: the third real case, not the third imagined one.
Bridge to the decision test: “so how do you decide in the moment? Here’s the 30-second version.”

The money slide

The 30-second test, before you extract.

Two yeses or more: cut the seam now. Fewer: duplicate and move on.

Q1
Does it already vary — twice, in the build, today?
Not “it might”. Two real cases on screen.
Q2
Will someone who doesn’t write code need to change it?
If yes, it’s data. This is almost always the strongest yes.
Q3
Does it cross a system boundary?
Gameplay → UI, audio, save, analytics. Boundaries want events.
Q4
Would one change mean editing three or more places?
Three edit sites is where mistakes start living.

✓

And the escape hatch: no seam is permanent. The test isn’t “is this right forever”, it’s “is this right this week”.

⏱ 48:00–51:00 — the slide to photograph

“Say it out loud with me the next time you’re about to make an interface: does it vary today, does a designer touch it, does it cross a boundary, is it three edits?”

Pause here. Let people take a photo — literally invite it.
Then: “that’s the whole decision procedure. Everything else is taste.”

Insurance, not architecture

Make the rewrite cheap instead.

You cannot avoid every rewrite. You can make it a Tuesday instead of a sprint.

01

Feature folders

A feature lives in one folder, with its own prefabs and assets. Deleting it is selecting a folder — not an archaeology dig.

02

No cross-feature references

Features talk through events or shared data, never directly. Then any one of them can be replaced alone.

03

A sandbox scene

One scene where a mechanic is tested with nothing else in it. If it needs the whole game to run, it’s already coupled.

★

Cheap deletion is the real measure of a flexible prototype. Can you delete a feature in five minutes without fear?

⏱ 51:00–53:00

“The best prototypes I’ve worked on weren’t the ones we never rewrote. They were the ones where rewriting a system took a day.”

The deletion test is memorable — use it as the section’s closing line.

06

Your turn — 8 minutes

One file, four concepts, one extraction. Pair up with the person next to you.

⏱ 53:00

“Pair up. Don’t open Unity — paper or a text editor is enough.”

The exercise

Name four concepts. Extract exactly one.

8 minutes · in pairs

PlayerController.csan honest excerpt

public class PlayerController : MonoBehaviour {
    public float speed = 5f, dashSpeed = 18f;
    public float maxHealth = 100f, currentHealth;
    public int ammo = 12, maxAmmo = 12;
    public bool isStunned, isDashing, isDead;
    public Slider healthBar;     // the HUD, from in here

    void Update() {
        if (isDead || isStunned) return;
        var h = Input.GetAxisRaw("Horizontal");
        var v = Input.GetAxisRaw("Vertical");
        transform.Translate(new Vector3(h, 0, v)
                            * speed * Time.deltaTime);
        if (Input.GetKeyDown(KeyCode.Space)) Dash();
        if (Input.GetMouseButtonDown(0) && ammo > 0) Shoot();
        healthBar.value = currentHealth / maxHealth;
    }
    // …and 140 more lines
}

step 1

Name the concepts

Write four names on paper. Use the “no ‘and’” test. Don’t write any code yet.

step 2

Run the 30-second test

For each one: varies today? designer-facing? crosses a boundary? three edit sites?

step 3

Extract the winner only

Whichever scored highest. One extraction — and notice how little you had to move.

⏱ 53:00–61:00 — run the clock, press T

Walk the room. Most pairs name Input, Motor, Health, Weapon — some also name HUD binding, which is the best answer.
At 4 minutes, call out: “anyone who hasn’t started extracting, pick the one your designer touches.”
Wrap-up: take two answers out loud, then show the next slide as “what we’d do”.

What we’d do

Four concepts, thirty minutes of cutting.

No new logic. Same game, different shape.

Concept	Seam	What it unlocks the same day
PlayerInput	interface	An AI can drive the player. Replays. A tutorial that plays itself. Gamepad support becomes one class.
Motor	component	Rewrite movement without touching shooting. Knockback and dash stop fighting each other.
Health	component + events	Shared with enemies and crates. The HUD leaves the player script for good.
WeaponDef	data asset	Your designer balances every gun in play mode while you keep working.

★

The HUD leaving the player script is the one people feel immediately — the player object stops knowing what a Slider is.

⏱ 61:00–64:00

“Notice: nothing here is clever. It’s naming, and moving lines into files that have one job.”

If time is short, this slide can be summarised in 40 seconds — it's the safest cut.

Take this home

Five rules, one screenshot.

01
Name it without “and”
If the name needs an “and”, it’s two things. Naming is the design.
02
Numbers live in assets
Five minutes, and your designer stops waiting for you.
03
Events cross systems, calls stay inside
Keep your stack traces. Decouple only at boundaries.
04
Two yeses on the 30-second test
Varies today · designer-facing · crosses a boundary · three edit sites.
05
Make deletion cheap
Feature folders, no cross-references, a sandbox scene. Rewrite becomes a Tuesday.
★
And the one-liner
Code is disposable. Concepts are not.

⏱ 64:00–66:00

“One screenshot, five rules. If you do numbers-in-assets and the 30-second test, you’ve got 80% of the benefit.”

Pause for photos again.

Who’s talking

We build games and the systems behind them.

AL-Arcade is a game and software studio in Egypt. Unity games, multiplayer and motion-tracking installations, and production systems that run real businesses every day — which is exactly where you learn what “flexible” costs.

→

Questions, or an argument about ECS: find me after this session.

AL-ARCADE

GAMES · SYSTEMS · INTERACTIVE

⏱ 66:00

Keep it to 30 seconds — credibility, not a sales pitch.
Mention one concrete thing you shipped that the audience can picture.

Prototype fast.
Once.

Every slide, every code sample and the checklist — at this link. Take a photo now, then let’s talk.

prototype-fast.caprover.al-arcade.com Speaker notes are in the deck — press N. PDF at /Prototype-Fast-Not-Twice.pdf

Thank youTechne SummitAL-Arcade

Close

“Thank you. One ask: pick one prototype you have right now, and do the numbers-in-assets seam tonight. It takes five minutes and you’ll feel it tomorrow.”

Then open the floor for questions — keep the jump menu (press O) handy to go back to any slide someone asks about.

Prototype Fast,Not Twice.

Open · ⏱ 0:00–1:00

Version one

Version two

The move

⏱ 1:00–3:00

Three skills, not a framework.

Hear the concept

Cut at the seam

Know when not to

⏱ 3:00–4:00

Two kinds of fast

⏱ 4:00

Fast on day 3. Frozen on day 30.

⏱ 4:00–7:00

You are not slow because you type slowly.

The test that matters

What we’re optimising

⏱ 7:00–9:00

⏱ 9:00–10:30

Hear the concept

⏱ 10:30

Five booleans that are really one idea.

⏱ 10:30–14:00

Three files. One idea.

⏱ 14:00–17:00

Every new enemy edits the same file.

⏱ 17:00–20:00

If you can name it without saying “and”.

⏱ 20:00–22:00

The 600-line PlayerController.

Input

Motor

Abilities

Health

⏱ 22:00–24:00

Cut at the seam

⏱ 24:00

What varies — and who changes it?

⏱ 24:00–26:00

Numbers belong in assets, not code.

What it buys

The bonus nobody expects

⏱ 26:00–29:00

Two minutes to stop caring what it is.

What it buys

One implementation, no second in sight

⏱ 29:00–31:00

The UI should never know where the score came from.

What it buys

Events inside one system

⏱ 31:00–34:00

Prefabs of parts, not a class tree.

The flying enemy that can’t fly

Parts on a prefab

⏱ 34:00–36:00

A game state machine in 20 lines.

What it buys

Why so small

⏱ 36:00–38:00

The first hour

⏱ 38:00

Six things, sixty minutes.

⏱ 38:00–41:00

The cheat panel is a feature.

Why it wins

Use OnGUI, deliberately

⏱ 41:00–43:00

And now: don’t

⏱ 43:00

Structure you will regret by Friday.

An event for everything

Interfaces with one implementation

The manager of managers

Framework first

⏱ 43:00–46:00

⏱ 46:00–48:00

The 30-second test, before you extract.

⏱ 48:00–51:00 — the slide to photograph

Make the rewrite cheap instead.

Prototype Fast,
Not Twice.

Prototype fast.
Once.