# Fudbal Manager Simulator Mobile
## Product & Technical Concept — Investor / Partner Overview

**Status:** Active development  
**Product thesis:** **Easy to play. Hard to master.**  
**Positioning:** Mobile-first football management game with classic-manager clarity and a modern simulation engine underneath.

> This document deliberately separates **IMPLEMENTED**, **LOCKED DESIGN**, **IN DEVELOPMENT**, and **PLANNED**. It does not present roadmap items as already-built features.

---

# 1. Executive Summary

**Fudbal Manager Simulator Mobile** is a mobile-first football management game designed around one principle:

> The player should make understandable football decisions. The simulation should carry the complexity.

The product takes emotional inspiration from the directness of classic European football managers from the 1990s — fast navigation, readable squads, clear decisions and quick seasons — but it is not a remake or clone. The underlying Match Engine is being built as a deterministic, spatial and event/state-driven football simulation.

The long-term goal is to combine:

- short, satisfying mobile sessions;
- fast seasons and long careers;
- meaningful club-building;
- players who differ because their underlying football abilities differ;
- roles and tactics that influence behaviour instead of granting magic stat boosts;
- a match experience that becomes the emotional payoff of the manager’s decisions;
- monetisation that does not depend on pay-to-win competitive advantages.

The project is already beyond the pure idea phase. A substantial Match Engine foundation exists, including physical pitch geometry, player movement, passing, reception, interception, defensive pressure, pass-flight defensive coverage, direct possession contests, ability sensitivity validation and deterministic replay/testing infrastructure.

The current development priority is still the Match Engine foundation. Club, career and production UI systems will be layered on top after the match simulation reaches a sufficiently stable playable slice.

---

# 2. The Product Problem

Football management games often fall into two extremes.

## 2.1 Very deep, but operationally heavy

Modern football management simulations can provide enormous depth, but that depth often arrives together with many menus, many screens and a large cognitive burden. That is excellent for one type of player, but not ideal for a mobile-first product meant to be enjoyable in short sessions.

## 2.2 Very accessible, but mechanically shallow

Many simple mobile football games are easy to learn, but their match outcomes can feel disconnected from player quality, roles, tactical behaviour and spatial football logic.

Our intended middle ground is:

**simple decisions + deep consequences.**

A manager should not need forty menus to understand what the team is trying to do. But when the player chooses a footballer, a role, a formation or eventually a tactical direction, the Match Engine should have enough football structure for that decision to matter.

---

# 3. Product Principles

## 3.1 Easy to play. Hard to master.

The interface should be learnable quickly. Mastery should come from understanding players, squad construction, roles, matchups, development and club strategy — not from learning where settings are hidden.

## 3.2 Complexity belongs inside the simulation

The user may see six clear player attributes. The Match Engine can still understand First Touch, Ball Control, Anticipation, Tackling and many other detailed abilities underneath.

The product should hide unnecessary complexity without removing football depth.

## 3.3 Roles are behaviour, not bonuses

A Playmaker should move, receive and choose differently. He should not receive a magical hidden passing bonus simply because the manager selected the role.

A role answers:

> What should this player try to do?

Abilities and context answer:

> Can he actually do it?

## 3.4 The Match Engine is presentation-independent

The same underlying match should drive every future presentation mode. The user may watch, accelerate, skip animations or receive summaries without changing the simulation result.

## 3.5 Football time is real simulation time

Actions, stoppages and restarts consume football time in the simulation. The presentation layer is free to compress that waiting.

## 3.6 Determinism matters

The same setup and seed should be replayable. This is important for debugging, calibration, automated testing and future simulation modes.

## 3.7 No OVR-driven football

OVR may eventually exist as a product-facing summary, but the Match Engine should never use it as the primary action resolver.

Football actions are resolved from underlying abilities and context.

---

# 4. Core Player Experience

The intended gameplay rhythm is:

**Build Club → Build Team → Prepare Match → Play / Watch → Analyse → Develop → Next Match**

At a larger scale:

**Match → Week → Season → Career → Club Legacy**

The game is intended to feel fast on a phone without making the career itself shallow.

A short session might be:

- check squad state;
- make one or two lineup decisions;
- prepare the next match;
- watch or accelerate the match presentation;
- review the result;
- continue the season.

The long-term hook is club ownership: building a team, developing players, managing resources, surviving difficult seasons, improving the club and creating a career history that belongs to the player.

---

# 5. Player System

## Status: LOCKED DESIGN + PARTIALLY IMPLEMENTED

Field players expose six visible attributes:

- Pace
- Shooting
- Passing
- Technique
- Defending
- Physical

Goalkeepers have their own six visible attributes.

OVR is not treated as a seventh fundamental football ability and is not the primary Match Engine resolver.

The detailed model underneath contains technical, mental, physical and goalkeeper-specific abilities. A separate personality/development layer is planned for long-term player lifecycle behaviour.

## 5.1 Fourteen locked positions

The positional system currently uses fourteen positions.

Roles are not positions. For example, False Nine and Poacher describe behaviour within a forward position rather than creating new positions.

## 5.2 Position Familiarity

Four familiarity levels are designed:

- Natural
- Comfortable
- Makeshift
- Unsuited

Position Familiarity is separate from Role Mastery.

## 5.3 Role Mastery

Role Mastery influences execution fidelity — timing, zone choice, role-specific movement, pressing/transition behaviour and support distances — rather than granting direct action-quality stat bonuses.

---

# 6. Hidden Ability Architecture

## Status: LOCKED DESIGN + SELECTIVE RUNTIME CONSUMPTION

The internal player model contains more detail than the six visible attributes.

Examples of runtime-relevant underlying abilities already exercised by the Match Engine include:

- Ball Control
- First Touch
- Tackling
- Anticipation
- Defensive Positioning
- Acceleration
- Sprint Speed
- Vision
- Decisions
- Short Passing
- Long Passing
- Finishing
- goalkeeper-specific abilities

Other hidden abilities are designed but not all are active runtime consumers yet.

This is intentional. The project is activating ability ownership gradually so each coefficient can be measured and tested rather than switching on a large opaque attribute soup.

---

# 7. Role System

## Status: LOCKED DESIGN + IMPLEMENTED FOUNDATION

The role model is based on behavioural tendencies.

Examples include:

### Goalkeepers
- Goalkeeper
- Sweeper Keeper

### Central defenders
- Defender
- Stopper
- Ball-Playing Defender

### Full-backs / wing-backs
- Full-Back
- Wing-Back
- Inverted Full-Back

### Defensive midfielders
- Anchor
- Ball Winner
- Deep-Lying Playmaker

### Central midfielders
- Central Midfielder
- Box-to-Box
- Playmaker
- Ball Winner

### Attacking midfielders
- Playmaker
- Shadow Striker

### Wide midfield / attack
- Wide Midfielder
- Winger
- Wide Playmaker
- Inside Forward

### Strikers
- Poacher
- Advanced Forward
- Target Forward
- Pressing Forward
- False Nine

The role system influences behavioural parameters such as:

- vertical depth;
- width preference;
- inside-lane bias;
- come-short tendency;
- run-in-behind tendency;
- channel runs;
- roaming;
- box occupation;
- support distance;
- receive-to-feet preference;
- hold-up behaviour;
- aerial target tendency;
- carrying/dribbling tendency;
- passing risk;
- crossing;
- shooting;
- pressing;
- defensive tracking;
- transition pressure.

The guiding concept is:

`target behaviour = position baseline + role delta + bounded team delta + bounded trait delta + match-context delta`

Execution fidelity is handled separately.

---

# 8. Tactics

## Status: LOCKED BASIC DESIGN / LIMITED RUNTIME AUTHORITY

The basic tactical vocabulary is designed around understandable manager choices such as:

- Mentality
- Tempo
- Passing
- Pressing
- Defensive Line
- Width

A key principle is that tactics should change player behaviour and space, not provide direct stat buffs.

Advanced tactical authority remains a later stage. The current Match Engine work intentionally establishes neutral football behaviour first.

---

# 9. Formation System

## Status: IMPLEMENTED FOUNDATION

The current design contains nine formation presets, with a 4-4-2 used as an early canonical Match Engine slice.

Formation anchors are data-driven and normalized, while physical match distances use the canonical pitch dimensions.

No player may simply teleport during live play. Explicit restart states may reposition players where football rules require it.

---

# 10. Match Engine Architecture

## Status: ACTIVE IMPLEMENTATION

The Match Engine uses a hybrid architecture:

- event/state-driven match lifecycle;
- physical/spatial player state;
- semantic deterministic RNG;
- authoritative transitions;
- one MatchState as the source of truth.

It is not intended to be:

- a pure aggregate result generator;
- a fixed-timestep animation simulation;
- a UI-driven match;
- a system where OVR directly resolves actions.

## 10.1 Canonical pitch

**105 m × 68 m**

Normalized coordinates exist for state representation, but physical football distances use pitch-aware geometry.

## 10.2 Match duration

A full match runs from:

`0 → 5,400,000 ms`

with halftime at:

`2,700,000 ms`

## 10.3 BallControl and PossessionSequence

BallControl and possession are separate concepts.

A team may have a continuing possession sequence while the ball is temporarily loose. BallControl represents who currently has authoritative control.

This distinction is important for receptions, loose balls, interceptions and turnovers.

---

# 11. Current Match Engine Football Flow

The current engine foundation includes:

1. player/formation spatial targets;
2. collective defensive block reaction;
3. local controlled-ball engagement;
4. pass candidate selection;
5. physical pass execution;
6. pass-flight defensive coverage;
7. interception opportunities;
8. reception / First Touch;
9. BallControl establishment;
10. direct close-range possession contest;
11. loose-ball recovery lifecycle.

A typical causal sequence can now look like:

**Carrier pressured → Pass released → Defensive handoff → Receiver attempts First Touch → Defender arrives → Controlled-ball possession contest**

This is the kind of football causality the project is trying to create instead of resolving everything through one generic possession probability.

---

# 12. Passing

## Status: IMPLEMENTED V1 FOUNDATION

The passing system includes:

- candidate selection;
- pass-lane visibility;
- physical pass source and terminal;
- delivery deviation;
- pass-flight duration;
- interception responders;
- reception resolution.

One important semantic defect discovered during development was the defender at the pass source being falsely counted as blocking the pass lane. That was isolated and corrected while preserving legitimate interior and target-endpoint occupancy.

This illustrates the project’s development method:

1. observe a defect;
2. measure it;
3. isolate one semantic cause;
4. change one bounded mechanic;
5. test;
6. commit or revert.

---

# 13. Defensive Spatial Stack

## Status: IMPLEMENTED V1 FOUNDATION

The current defensive structure has multiple layers.

### Controlled ball

`formation → role → collective defensive block → local carrier engagement → world reconciliation`

### Pass in flight

`formation → role → temporally coherent collective pass block → one local pass-terminal coverage defender → world reconciliation`

The pass-flight coverage defender naturally becomes the next controlled-ball engager in most successful receptions, creating a defensive handoff rather than an unrelated second presser.

---

# 14. Controlled-Ball Possession Contest

## Status: IMPLEMENTED V1

A direct possession challenge is possible when:

- the ball is CONTROLLED;
- the state is OPEN_PLAY;
- the carrier is not a goalkeeper;
- the canonical local engager exists;
- committed physical separation is at most 1.0 metre.

The defender’s challenge skill uses **Tackling**.

The attacker’s resistance uses **Ball Control**.

Current V1 probability:

`clamp(0.22 + (Tackling - BallControl) × 0.004, 0.03, 0.60)`

A successful challenge directly transfers BallControl to the defender and starts a new possession sequence.

A failed challenge changes nothing and the attacker continues into normal action selection.

The system intentionally does not reinterpret unrelated `CARRY_CONTROL_LOST` events as tackles.

---

# 15. First Touch / Reception

## Status: IMPLEMENTED + REBALANCED V1

The reception model uses:

`base + FirstTouch × weight - geometry penalties`

with a lower and upper probability clamp.

A heterogeneous ability probe showed that the earlier envelope saturated too early — moderate FirstTouch values above roughly 55 were frequently pinned to the ceiling.

The current accepted V1 envelope is:

- `baseProbability = 0.7225`
- `firstTouchWeight = 0.00325`
- `minimumProbability = 0.04`
- `maximumProbability = 0.97`

On a clean delivery:

- FirstTouch 30 → 0.820
- FirstTouch 50 → 0.885
- FirstTouch 70 → 0.950

Moderate FirstTouch values are therefore ordered without pathological upper-clamp saturation.

---

# 16. Ability Sensitivity Validation

## Status: VALIDATED DEVELOPMENT INFRASTRUCTURE

A deterministic heterogeneous player population was created specifically for Match Engine testing. It is **not** a production roster generator and makes no realism claim.

Its purpose is to prove that abilities actually change football outcomes.

### Carry retention by Ball Control

- 30 → ~45.9%
- 50 → ~58.8%
- 70 → ~71.1%

### Reception by First Touch after the V1 rebalance

- 30 → ~73.0%
- 50 → ~77.3%
- 70 → ~84.1%

Controlled-ball contest probabilities are also monotonic under Tackling vs BallControl matchups.

This verifies that the Match Engine is not merely moving 22 statistically identical players around the pitch.

---

# 17. Loose-Ball Recovery

## Status: IN DEVELOPMENT

Loose-ball recovery is the current active engineering area.

Recent observer work showed:

- failed receptions currently place the receiver and loose ball at the same terminal coordinate;
- this makes the failed receiver recover the ball almost automatically;
- simple 1–5 m deterministic ball spill does not solve the problem cleanly;
- the current loose-ball recovery timing is based on a legacy normalized-distance multiplier;
- this timing implies physically unrealistic travel speeds;
- the current recovery lifecycle is effectively “preselected winner + wait,” not a dynamic physical race;
- the next design boundary is evaluating a physical arrival-time recovery model using the existing player movement/reach speed authority.

No final gameplay change from that research is being claimed in this document yet.

---

# 18. Realism & Calibration

## Status: ACTIVE DEVELOPMENT

Primary realism benchmark:

**European Top 5 leagues**

Additional control:

**Bundesliga**

The philosophy is to compare distributions and semantics rather than chase one average.

Areas observed include:

- goals;
- shots;
- shots on target;
- pass volume;
- pass completion;
- interceptions;
- corners;
- throw-ins;
- goal kicks;
- saves;
- possession structure;
- action and sequence lengths;
- open-play / dead-ball / restart time.

Important caveat:

**Development metrics are not release claims.**

A subsystem is not accepted simply because it moves one headline statistic closer to a real-world average. Football semantics come first; calibration follows.

---

# 19. Testing & Determinism

## Status: STRONG FOUNDATION

The project uses a small-stage development cycle:

1. define one semantic boundary;
2. implement one bounded stage;
3. run automated tests;
4. run deterministic match batches;
5. measure observer artifacts;
6. review;
7. commit or revert.

At the latest accepted gameplay milestone represented by the landing page:

- the automated suite exceeded **900 tests**;
- the canonical batch completed **16/16** full matches;
- matches finished exactly at **5,400,000 ms**;
- the defined replay equality contract remained exact.

This testing discipline is a major part of the project’s technical risk reduction.

---

# 20. Technology

Current core direction:

- **TypeScript**
- headless Match Engine
- deterministic semantic RNG
- centralized calibration
- authoritative state transitions
- mobile presentation separated from simulation

This makes it possible to:

- run matches quickly without rendering;
- calibrate batches;
- test deterministic replays;
- support multiple presentation speeds later;
- keep the simulation consistent across UI modes.

---

# 21. Mobile Product Philosophy

A football manager on a phone should respect mobile time.

The target experience is not:

> Spend forty minutes configuring one match.

It is closer to:

- 1–2 minutes: check club/squad;
- a few minutes: prepare the next match;
- watch, accelerate or compress the match presentation;
- quickly understand what happened;
- continue the season.

The simulation may be complex. The interaction should remain direct.

---

# 22. Club & Career Vision

## Status: PLANNED / PARTIALLY DESIGNED

The long-term product includes more than the match.

Planned areas include:

- club finances;
- transfers;
- contracts;
- scouting;
- youth generation;
- player development;
- ageing;
- retirement;
- form;
- morale;
- injuries;
- team familiarity;
- facilities / club development;
- long-term career history.

These systems are not presented as already complete.

---

# 23. Monetisation Philosophy

## Status: OPEN DESIGN

The current product principle is:

> Monetisation must not destroy simulation integrity.

Possible future monetisation categories may include:

- cosmetic presentation;
- convenience features;
- optional content;
- additional career/leagues/content packages where appropriate.

The project does not currently depend on selling direct competitive power.

Exact monetisation design remains open until the core game loop proves itself.

---

# 24. Why Investment Can Matter

Investment can accelerate areas that are expensive in time and specialist effort:

- mobile UI/UX;
- art direction;
- animation;
- engineering capacity;
- QA and device coverage;
- content pipeline;
- commercial data/licensing review;
- backend/cloud services if required;
- store readiness;
- legal/compliance;
- marketing and user acquisition;
- closed testing and analytics.

The proposition is not only “fund an idea.” It is “accelerate a simulation product whose technical foundation is already under active construction.”

---

# 25. Roadmap

## Phase 1 — Foundation
**Status: substantially completed**

- player attributes;
- positions;
- roles;
- formation architecture;
- MatchState / transition model;
- deterministic runtime.

## Phase 2 — Match Engine V1
**Status: active**

- physical football geometry;
- passing;
- reception;
- interception;
- defensive block;
- local pressure;
- possession contest;
- loose-ball recovery;
- remaining off-ball / sequence structure.

## Phase 3 — Club & Career Systems
**Status: planned**

- squad lifecycle;
- transfers;
- finances;
- contracts;
- youth;
- long-term club progression.

## Phase 4 — Playable Mobile Alpha
**Status: planned**

- production UI;
- end-to-end season loop;
- save/load;
- onboarding;
- match presentation modes.

## Phase 5 — Closed Testing / Calibration / Release
**Status: planned**

- QA;
- device coverage;
- balancing;
- realism calibration;
- performance;
- store packaging;
- launch.

---

# 26. Current Risks & Open Questions

## Match Engine still evolving
Loose-ball recovery and off-ball support remain active areas.

## Final realism not yet calibrated
Mechanics are being validated before release-level distribution fitting.

## Production UI is not finished
Current UI screens are product concepts.

## Career systems remain incomplete
The product is not yet a full playable football-manager career.

## Licensing/data decisions remain open
Real teams, players and commercial data sources require separate legal/product decisions.

## Monetisation remains intentionally open
The core gameplay must prove itself before monetisation is allowed to distort design.

---

# 27. Investor View: What Exists vs. What Does Not

## IMPLEMENTED / VALIDATED FOUNDATION

- deterministic headless Match Engine;
- canonical 105×68 physical pitch model;
- explicit MatchState transitions;
- BallControl and PossessionSequence separation;
- formation anchors;
- role-behaviour foundation;
- passing;
- physical pass terminal;
- reception / First Touch;
- interception;
- collective defensive block;
- local carrier engagement;
- pass-flight defensive coverage;
- direct possession contest;
- heterogeneous ability probe;
- 90-minute deterministic batches;
- replay equality infrastructure.

## LOCKED DESIGN

- visible player-attribute philosophy;
- 14 positions;
- position familiarity;
- role mastery separation;
- role catalogue foundation;
- basic tactical vocabulary;
- presentation-independent simulation principle;
- real-football-time simulation principle.

## IN DEVELOPMENT

- loose-ball physical recovery timing;
- failed-reception recovery consequence;
- remaining Match Engine structural gaps;
- long-possession/off-ball support behaviour.

## PLANNED

- full club/career systems;
- transfers and contracts;
- youth and development;
- finances;
- production mobile UI;
- onboarding;
- save/load career;
- final realism calibration;
- QA, device testing and store release.

---

# 28. Product Thesis

The product can be summarized in one sentence:

> **Classic football-manager clarity on the surface; modern deterministic football simulation underneath.**

The user should never need to understand the engine’s state machine, physical-distance conversion or semantic RNG.

He should simply feel:

- this player is better at controlling the ball;
- this role changes how the team behaves;
- this defender actually arrived in time;
- this failed touch mattered;
- this tactical choice changed the match;
- this club became mine.

That is the product.

---

# 29. Current Internal Status Reference

For technical traceability, the landing-page status is based on the latest **accepted gameplay milestone E8S**, where the First Touch reception envelope V1 was promoted to canonical gameplay.

Later work in the current project stream is observer/research work around loose-ball physical recovery timing and does not yet represent accepted gameplay changes.

This reference is included for status clarity and is not intended as a marketing claim.

---

# 30. Closing

# Fudbal Manager Simulator Mobile

**Easy to play. Hard to master.**

A football-management game built for the phone, for long careers, and for people who want their decisions to matter on the pitch.