September 23, 2026
Stop Telling Boxing Fans It Cannot Be Done: Difficult Is Not The Same As Impossible
Today's Main Question
When a boxing videogame developer says:
"That feature is difficult."
What does that actually mean?
Does it mean the feature is technically impossible?
Does it mean the current engine was not designed for it?
Does it mean the development team did not have enough time?
Does it mean it was not considered important enough?
Does it mean another feature received priority?
Does it mean the design direction changed?
Does it mean the developers tried it and did not like how it affected gameplay?
Does it mean it created online synchronization problems?
Does it mean it was postponed?
Or does it simply mean:
WE DECIDED NOT TO PUT IT IN THIS GAME?
Those are completely different explanations.
And boxing videogame players should stop treating them as though they mean the same thing.
Today we're going to talk about:
referees,
clinching,
inside fighting,
rope interaction,
CPU versus CPU,
corner systems,
get-up systems,
delayed reactions,
block fatigue,
boxer individuality,
offline versus online architecture,
and the difference between:
TECHNICAL LIMITATION
and:
DESIGN DECISION.
We're also going to talk about something I think boxing videogame development desperately needs:
THE BOXING FEATURE FEASIBILITY AND ACCOUNTABILITY FRAMEWORK
Along with:
Feature Difficulty Classification
Feature Dependency Audit
Design Decision Ledger
Prototype Evidence Standard
Removal Reason Codes
Technical Blocker Report
Legacy Feature Benchmark
Cross-Genre Feasibility Test
Feature Regression Audit
Deferred Feature Register
Offline/Online Constraint Separation
Simulation Integrity Checklist
Boxing Completeness Matrix
and:
THE "SHOW ME WHY" TEST.
If something that existed in older sports games supposedly cannot be done today, I want to know:
WHY?
Not because every feature is easy.
Some aren't.
But:
HARD IS NOT IMPOSSIBLE.
And:
DIFFICULT IS NOT AN EXPLANATION BY ITSELF.
Let's get into it.
OPENING HOOK
POE:
Welcome everybody to another edition of Poe & The Community Speaks.
Today I want to talk about one word that gets used way too casually in videogame development conversations.
HARD.
"It's hard to put a referee in the ring."
"Clinching is hard."
"Inside fighting is hard."
"Rope interaction is hard."
"AI is hard."
"Online synchronization is hard."
"Physics is hard."
Okay.
I accept that.
Game development is difficult.
I have never said game development is easy.
But here's my question.
THEN WHAT?
Because "hard" cannot be the end of the conversation.
If you're building a boxing videogame, boxing itself contains difficult systems.
Two human bodies interact.
Feet reposition.
Hands collide.
Fighters clinch.
Fighters push.
Fighters lean.
Fighters work inside.
Fighters get trapped against ropes.
Referees move around them.
Referees separate them.
Fighters get hurt.
Their reactions change.
Their balance changes.
Their fatigue changes.
Judges interpret what happens.
Corners react.
That is boxing.
So if every complicated part of boxing gets removed because:
"THAT'S HARD,"
eventually what are we making?
A boxing videogame?
Or:
a punching game inside a boxing ring?
That's the conversation today.
SEGMENT ONE: TODAY'S RECEIPT CHECK
POE:
First, let's establish what is current and what is not.
UNDISPUTED 2
The latest substantial public information I could verify still comes from Steel City Interactive's September 9 community update.
Ash Habib confirmed that Undisputed 2 remains in development.
Daniel Dubois, Roberto Durán and Jermain Taylor were announced.
Dubois participated in motion capture.
Reporting also says SCI has expanded beyond 100 employees and that the sequel is being rebuilt on a new technical foundation.
That is confirmed reporting.
What we do not have today is:
a new complete gameplay demonstration,
a detailed clinching demonstration,
a full inside-fighting demonstration,
a complete referee demonstration,
a Career Mode demonstration,
or a technical breakdown showing exactly how the sequel handles all of the systems we're discussing today.
So:
I'M NOT GOING TO PRETEND WE KNOW.
That's the factual line.
SEGMENT TWO: EA FIGHT NIGHT
The other major boxing videogame story remains the September 18 Insider Gaming report concerning Fight Night.
According to that report, the previous plan for a Fight Night return was cancelled roughly a year ago.
The project reportedly had progressed beyond pre-production.
But the report also specifically left open the possibility that the franchise could be discussed again.
If something happens, according to the reporting, it would effectively be a new project.
So once again:
REPORTED:
The previous Fight Night plan was cancelled.
NOT OFFICIALLY ANNOUNCED BY EA:
Fight Night is permanently dead.
ALSO NOT CONFIRMED:
A new Fight Night has been greenlit.
Keep those three things separate.
SEGMENT THREE: 2K AND VISUAL CONCEPTS
As of today's show, I still have not found an official announcement that 2K or Visual Concepts is developing a boxing videogame.
I keep discussing Visual Concepts because sports videogames outside boxing demonstrate what modern sports-game ecosystems, creation systems, long-term simulations, presentation systems and athlete-specific data can become.
That makes them relevant to the design conversation.
It does not make a 2K boxing game confirmed.
That's the distinction.
SEGMENT FOUR: TODAY'S BIG QUESTION
Now let's get into it.
Why would putting an in-ring referee into a boxing videogame be considered difficult?
Let's be fair.
There are legitimate technical challenges.
The referee needs:
navigation.
Collision avoidance.
Positioning.
Line of sight.
State awareness.
Foul recognition.
Knockdown recognition.
Clinch recognition.
Break commands.
Count logic.
Stoppage logic.
Animation transitions.
Interaction with two moving boxers.
Online synchronization if the referee is authoritative online.
So yes.
THAT REQUIRES WORK.
But now comes the other side of the conversation.
Videogames have been putting multiple independently controlled or AI-controlled characters into confined spaces for decades.
Wrestling games have had:
multiple wrestlers,
referees,
managers,
tag partners,
interference,
weapons,
environmental interactions,
and numerous characters moving around a ring.
Sports games simulate:
players,
officials,
coaches,
crowds,
ball physics,
formations,
collisions,
and constantly changing game states.
So the argument cannot simply be:
"THERE'S A THIRD PERSON IN THE RING, THEREFORE IT'S TOO DIFFICULT."
That is not a sufficient technical explanation.
The real question is:
WHAT SPECIFIC PROBLEM DOES THE THIRD CHARACTER CREATE IN YOUR BOXING ARCHITECTURE?
Now we're getting somewhere.
SEGMENT FIVE: INTRODUCING THE FEATURE DIFFICULTY CLASSIFICATION
Whenever a developer says a feature is difficult, classify the difficulty.
TYPE A: ENGINE LIMITATION
The engine or existing architecture cannot support the feature efficiently.
TYPE B: ANIMATION COMPLEXITY
Too many transitions or interactions are required.
TYPE C: AI COMPLEXITY
The behavior requires sophisticated decision-making.
TYPE D: PHYSICS COMPLEXITY
Physical interactions are unstable or unpredictable.
TYPE E: NETWORK COMPLEXITY
The feature is difficult to synchronize online.
TYPE F: PERFORMANCE COST
The feature consumes too much CPU, GPU, memory or bandwidth.
TYPE G: CONTENT COST
The system works, but creating enough animations, assets or data is expensive.
TYPE H: QA COST
The number of possible interactions becomes difficult to test.
TYPE I: DESIGN CONFLICT
Developers believe the feature hurts their intended gameplay experience.
TYPE J: SCHEDULE
The team could build it, but not within the planned release window.
TYPE K: PRIORITY
Resources were assigned elsewhere.
TYPE L: COMMERCIAL DECISION
The company did not believe the feature justified the cost.
Now we know what:
"HARD"
actually means.
SEGMENT SIX: DESIGN DECISION IS NOT TECHNICAL IMPOSSIBILITY
This distinction matters enormously.
Suppose a developer says:
"We removed clinching because it slowed down the action."
That's not:
WE COULDN'T BUILD CLINCHING.
That's:
WE DIDN'T WANT CLINCHING TO AFFECT THE PACE OF THE GAME THAT WAY.
That's a design decision.
And that's perfectly legitimate for a developer to make.
But then players are equally entitled to say:
I DISAGREE WITH THAT DESIGN DECISION BECAUSE CLINCHING IS PART OF BOXING.
Now we're having an honest conversation.
SEGMENT SEVEN: THE SAME THING APPLIES TO REFEREES
Suppose the explanation is:
"We didn't want the referee obstructing the camera."
Fine.
That's a design problem.
Solutions might include:
dynamic transparency,
camera-aware positioning,
temporary fade,
intelligent navigation,
collision priority,
camera switching.
Now we're designing.
But saying:
"A referee is hard"
doesn't tell us anything.
Hard because:
camera?
Navigation?
Online?
Animation?
Performance?
Collision?
State recognition?
Tell us the problem.
Then we can discuss the solution.
SEGMENT EIGHT: INTRODUCING THE TECHNICAL BLOCKER REPORT
This becomes a new Blueprint development requirement.
TECHNICAL BLOCKER REPORT
For any major boxing feature that is removed, postponed or considered infeasible, document:
Feature
What was attempted?
Target Behavior
What should it do?
Technical Blocker
What specifically prevents it?
Affected Systems
Animation?
AI?
Physics?
Networking?
Performance?
Prototype Result
What happened when tested?
Potential Solutions
What approaches remain?
Cost
What would solving it require?
Priority
Why is another feature receiving resources instead?
Now "we couldn't do it" becomes something measurable.
SEGMENT NINE: CLINCHING
Let's use clinching.
Why is clinching difficult?
Because now two independently animated bodies become:
physically linked.
Their feet must remain plausible.
Their arms must interact.
Their torsos must maintain contact.
Their heads must avoid impossible clipping.
Their momentum must be resolved.
Short punches may occur.
The referee may intervene.
One fighter may initiate.
The other may resist.
One may hold.
One may work.
The clinch may transition into separation.
Yes.
THAT'S COMPLICATED.
But complicated does not mean:
remove clinching from boxing forever.
It means:
BUILD A CLINCH SYSTEM.
SEGMENT TEN: CLINCHING SHOULD NOT BE ONE ANIMATION
This is where older design thinking causes problems.
Clinch button.
Animation plays.
Wait.
Separate.
That's not enough.
The Blueprint needs:
CLINCH STATE MACHINE
States could include:
Entry.
Attempt.
Accepted.
Resisted.
Partial tie-up.
Full tie-up.
Overhook.
Underhook.
Head position.
Rope clinch.
Turn.
Short work.
Referee warning.
Break.
Exit.
Now clinching becomes:
a system.
Not:
a cutscene.
SEGMENT ELEVEN: INTRODUCING CONTACT ANCHORS
Another new Blueprint concept:
BOXING CONTACT ANCHORS
Instead of requiring every clinch animation to be perfectly authored for every body combination, the system defines contact targets:
shoulder.
Upper arm.
Forearm.
Torso.
Neck region.
Glove.
Then procedural animation and inverse kinematics help maintain plausible contact.
Authored animation supplies:
style and intention.
Procedural adjustment handles:
body differences and position.
Now we have a scalable solution.
SEGMENT TWELVE: WHY OLDER GAMES MATTER IN THIS DEBATE
Whenever somebody says:
"Technology makes this impossible,"
look backward.
Did an older game implement some version of it?
If yes, that does not automatically mean:
the modern implementation is easy.
Modern expectations are higher.
Animation quality is higher.
Online synchronization may be more complicated.
Physics may be more sophisticated.
But the older implementation proves something important:
THE GAMEPLAY CONCEPT ITSELF IS NOT IMPOSSIBLE.
Then the question becomes:
why can't the modern architecture improve it?
That's a much more useful question.
SEGMENT THIRTEEN: INTRODUCING THE LEGACY FEATURE BENCHMARK
Every major proposed boxing feature gets compared against:
previous boxing games,
wrestling games,
MMA games,
other sports games,
simulation games.
Not because:
"If Game X did it, copy Game X."
No.
The question is:
WHAT PROBLEM DID THEY ALREADY SOLVE?
Example:
Multiple characters in ring?
Solved elsewhere.
Dynamic officials?
Solved elsewhere.
Body contact?
Solved elsewhere.
Career negotiations?
Solved elsewhere.
Long-term sports simulation?
Solved elsewhere.
Creation sharing?
Solved elsewhere.
Historical eras?
Solved elsewhere.
Custom organizations?
Solved elsewhere.
Now ask:
How do we adapt those lessons specifically to boxing?
SEGMENT FOURTEEN: CROSS-GENRE FEASIBILITY TEST
Here's another new Blueprint tool.
CROSS-GENRE FEASIBILITY TEST
When somebody claims:
"This cannot be done,"
search other genres.
Does wrestling solve part of it?
Does basketball?
Football?
Hockey?
MMA?
Racing?
RPGs?
Strategy games?
Management games?
Maybe nobody has solved the exact boxing problem.
But pieces of the solution may already exist.
That's how technology advances.
SEGMENT FIFTEEN: INSIDE FIGHTING
Inside fighting is another example.
People hear:
inside fighting
and imagine:
a completely different videogame.
No.
The foundation requires:
range detection.
body positioning.
short-punch animation.
guard interaction.
head positioning.
foot positioning.
collision.
balance.
AI decisions.
Those systems also benefit:
mid-range boxing,
clinching,
rope fighting,
body work,
defense.
So once again:
BUILDING INSIDE FIGHTING IMPROVES OTHER BOXING SYSTEMS.
This isn't wasted engineering.
SEGMENT SIXTEEN: INSIDE POSITION SHOULD BE A PHYSICAL STATE
Don't create:
INSIDE MODE ON.
Instead calculate:
distance.
angle.
torso relationship.
foot relationship.
guard contact.
available punching lanes.
Then inside fighting emerges naturally from geometry.
That's more robust.
SEGMENT SEVENTEEN: INTRODUCING THE RANGE CONTINUUM
Another Blueprint addition.
BOXING RANGE CONTINUUM
Instead of:
Outside.
Middle.
Inside.
Treat range as continuous.
The game evaluates:
exact distance,
angle,
reach,
stance,
body orientation.
Different techniques become more or less viable depending on location.
Now there's no magical invisible line where:
inside fighting suddenly activates.
The fight transitions naturally.
SEGMENT EIGHTEEN: THE ROPES
Another supposedly difficult boxing system.
Ropes deform.
Fighters lean.
Bodies collide.
Footwork becomes constrained.
Punch trajectories change.
Defense changes.
Escape angles change.
Referee positioning changes.
Yes.
Complex.
But again:
THIS IS BOXING.
Ropes aren't decoration.
They're part of ring geography.
SEGMENT NINETEEN: INTRODUCING RING GEOGRAPHY
The ring should have gameplay zones:
Center.
Mid-ring.
Near ropes.
On ropes.
Corner approach.
Corner trapped.
Neutral corner.
Clinch against ropes.
Each zone modifies:
movement options,
AI decisions,
defensive options,
escape routes,
camera considerations,
commentary.
Now the ring itself matters.
SEGMENT TWENTY: STOP TREATING THE RING LIKE A FLAT SQUARE
This is important.
A boxing ring isn't:
a square texture.
It is a tactical environment.
Center control matters.
Ropes matter.
Corners matter.
Angles matter.
A pressure fighter should understand:
where the opponent is.
A mover should understand:
where escape routes are.
Corner advice should understand:
where the fight is occurring.
Commentary should recognize:
who is controlling geography.
That's boxing intelligence.
SEGMENT TWENTY-ONE: THE REFEREE CAN READ THE SAME WORLD STATE
Now look at the reuse.
If the game already knows:
distance,
ring position,
fighter state,
clinch state,
knockdown state,
foul state,
then the referee does not need magical awareness.
The referee reads:
THE SAME AUTHORITATIVE FIGHT STATE.
Then chooses:
observe.
Move.
Warn.
Separate.
Count.
Call doctor.
Stop fight.
That's why architecture matters.
SEGMENT TWENTY-TWO: REFEREE AI DOES NOT HAVE TO BE SUPERHUMAN
Referees make mistakes.
This actually gives developers more room.
Referee attributes:
positioning.
Awareness.
Strictness.
Foul tolerance.
Stoppage tendency.
Break speed.
Experience.
Now referees become:
PEOPLE.
Not perfect robots.
Different referees change fights.
That's another Blueprint opportunity.
SEGMENT TWENTY-THREE: REFEREE PERSONALITIES
Imagine:
Referee A allows inside work.
Referee B breaks quickly.
Referee C warns constantly.
Referee D allows rough fighting.
Referee E stops fights earlier.
Now selecting or assigning a referee has strategic meaning.
Career Mode can track:
referee history.
Commentary can mention it.
Corners can prepare for it.
One referee system feeds:
gameplay,
Career,
commentary,
strategy,
presentation.
Again:
reuse.
SEGMENT TWENTY-FOUR: GET-UP SYSTEMS
Another boxing system that should be deeper.
Don't make:
button mash.
Don't make:
identical minigame every knockdown.
The ability to rise should depend on:
damage.
consciousness.
balance.
legs.
fatigue.
heart.
recovery.
previous knockdowns.
injury.
fighter traits.
Now the player participates, but boxer condition matters.
SEGMENT TWENTY-FIVE: INTRODUCING RECOVERY STATE
RECOVERY STATE
After a knockdown, boxer transitions through:
disorientation.
orientation.
attempted rise.
balance recovery.
guard restoration.
movement recovery.
A boxer may beat the count but still have:
unstable legs.
Delayed defense.
Reduced awareness.
Now getting up isn't:
RESET FIGHT.
The knockdown has consequences.
SEGMENT TWENTY-SIX: DELAYED REACTIONS
Real boxers do not always react instantly to damage.
A body shot may produce delayed discomfort.
Leg instability can appear after an exchange.
Fatigue accumulates.
Damage can become visible seconds later.
So the damage model should contain:
IMMEDIATE RESPONSE
and:
DELAYED RESPONSE.
That creates much more believable fights.
SEGMENT TWENTY-SEVEN: INTRODUCING DAMAGE LATENCY
New Blueprint system:
DAMAGE LATENCY MODEL
Impact occurs.
System calculates:
immediate damage,
delayed neurological response,
localized pain,
balance effect,
stamina effect,
guard response,
behavior change.
Not every punch produces:
instant animation.
That prevents the videogame look where every landed punch automatically triggers exaggerated reaction.
SEGMENT TWENTY-EIGHT: BLOCK FATIGUE
Holding your guard should not provide permanent perfect defense.
Arms fatigue.
Guard integrity changes.
Damage accumulates.
Repeated impact matters.
But again:
don't create a videogame shield bar and call it realism.
Track:
arm fatigue.
impact accumulation.
guard position.
defensive technique.
glove placement.
reaction time.
Now guard breakdown emerges.
SEGMENT TWENTY-NINE: EVERYTHING IS CONNECTING
Notice what is happening.
Clinching uses:
contact system.
Inside fighting uses:
contact system.
Ropes use:
contact system.
Guard uses:
contact system.
Damage uses:
contact system.
Referee reads:
fight state.
Commentary reads:
fight state.
Corner reads:
fight state.
AI reads:
fight state.
So when somebody counts these as:
ten unrelated impossible features,
they're misunderstanding the architecture.
The challenge is building:
THE RIGHT FOUNDATION.
SEGMENT THIRTY: WHY I QUESTION THE "TIME CONSTRAINT" EXPLANATION
Here's where I want to be careful.
This is my opinion and inference.
I cannot prove internal SCI priorities unless SCI documents them.
But from the outside, I think players have every right to ask questions when a company continues producing:
boxers,
arenas,
events,
promotional material,
and other content,
while foundational gameplay systems remain absent or incomplete.
That does not prove:
THEY INTENTIONALLY HELD FEATURES BACK FOR A SEQUEL.
We should not state that as fact without evidence.
But it does justify asking:
WHAT WAS THE PRIORITY DECISION?
That's fair.
SEGMENT THIRTY-ONE: CONTENT TEAMS AND ENGINEERING TEAMS ARE DIFFERENT
Here's the counterargument we need to acknowledge.
Someone will say:
"Poe, the people creating an arena aren't the programmers building clinching."
Correct.
That's an important point.
Artists cannot simply be reassigned to solve network code.
A licensing team cannot fix AI.
A character artist cannot automatically build referee logic.
So continued content production does not automatically prove engineering resources were available for every missing gameplay feature.
Fair.
But:
management still determines:
staffing,
budget,
schedule,
hiring,
priorities,
scope.
So the larger question remains:
WHY DID THE PROJECT ALLOCATE RESOURCES THE WAY IT DID?
That's the fair version of the criticism.
SEGMENT THIRTY-TWO: INTRODUCING THE DESIGN DECISION LEDGER
Every major feature decision should internally have:
DESIGN DECISION LEDGER
Feature:
Clinching.
Original intent:
Full clinch system.
Decision:
Reduced / removed / deferred.
Reason:
Technical.
Design.
Schedule.
Budget.
Online.
Priority.
Date.
Responsible discipline.
Future status:
Cancelled.
Deferred.
Rebuilding.
Experimental.
Now years later the team doesn't have to guess:
WHY DID WE REMOVE THIS?
This is normal disciplined development documentation.
SEGMENT THIRTY-THREE: INTRODUCING REMOVAL REASON CODES
Simple system.
R1
Technical blocker.
R2
Design change.
R3
Budget.
R4
Schedule.
R5
Performance.
R6
Online architecture.
R7
QA instability.
R8
Licensing.
R9
Low player value.
R10
Deferred to later development.
Now a feature doesn't simply disappear into:
"WE COULDN'T GET IT WORKING."
There's a reason.
SEGMENT THIRTY-FOUR: WHY THIS MATTERS FOR UNDISPUTED 2
SCI has a new opportunity.
If the sequel is genuinely being rebuilt on a different foundation, then this is the time to revisit:
clinching.
Inside fighting.
Referee.
Ropes.
Movement.
Hit detection.
Get-up.
Fatigue.
Reactions.
Boxer identity.
CPU versus CPU.
Creation.
Career.
Not because every feature must be shown tomorrow.
But because foundational decisions happen early.
SEGMENT THIRTY-FIVE: DON'T WAIT UNTIL THE END TO DISCOVER BOXING DOESN'T FIT
That's the nightmare.
Build:
graphics.
Roster.
Menus.
Online infrastructure.
Career shell.
Arenas.
Presentation.
Then somebody says:
"Now let's add realistic clinching."
And engineering says:
"The locomotion architecture doesn't support it."
Too late.
The correct question during foundation development is:
WHAT BOXING INTERACTIONS MUST THIS ENGINE EVENTUALLY SUPPORT?
Even if they're not all finished today.
SEGMENT THIRTY-SIX: INTRODUCING THE BOXING COMPLETENESS MATRIX
Before production gets too far, list major boxing interactions.
MOVEMENT
Forward.
Backward.
Lateral.
Pivot.
Angle change.
Stance switching.
OFFENSE
Straight punches.
Hooks.
Uppercuts.
Body shots.
Feints.
Combinations.
Inside punches.
DEFENSE
Block.
Catch.
Parry.
Slip.
Roll.
Pull.
Pivot exit.
PHYSICAL INTERACTION
Clinch.
Tie-up.
Break.
Rope pressure.
Corner pressure.
Hand fighting.
OFFICIATING
Warnings.
Fouls.
Counts.
Stoppages.
Breaks.
Doctor involvement.
CONDITION
Fatigue.
Damage.
Cuts.
Swelling.
Recovery.
Delayed reactions.
STRATEGY
Corner advice.
Adjustments.
Scoring awareness.
Opponent recognition.
Then ask:
DOES THE FOUNDATION SUPPORT EACH CATEGORY?
Not:
Is every feature finished?
Does the architecture support it?
Big difference.
SEGMENT THIRTY-SEVEN: AUTOMATIC PHASE SELECTION
This connects to another Blueprint idea.
The engine should understand what phase the fight is naturally in.
Outside.
Entry.
Mid-range.
Pocket.
Inside.
Clinch.
Rope.
Break.
Recovery.
But the player should not press:
ENTER INSIDE MODE.
The game determines the physical phase from:
distance,
angle,
contact,
momentum,
position.
That creates continuity.
SEGMENT THIRTY-EIGHT: WHY THIS MATTERS FOR ANIMATION
If phases are understood by the engine, animation blending improves.
Outside footwork transitions into:
entry.
Entry transitions into:
short punching.
Short punching transitions into:
contact.
Contact transitions into:
clinch.
Clinch transitions into:
break.
No teleporting.
No magnetic snapping.
No sudden animation reset.
That's the goal.
SEGMENT THIRTY-NINE: THE FEATURE REGRESSION AUDIT
Another Blueprint addition:
FEATURE REGRESSION AUDIT
Before shipping a sequel or major update, compare it with:
the previous game,
older games in the genre,
the original design promises,
community expectations.
Ask:
What improved?
What stayed?
What disappeared?
Why?
Was the removal intentional?
Is there a replacement system?
Is the replacement better?
This prevents:
NEWER = AUTOMATICALLY BETTER
thinking.
SEGMENT FORTY: TECHNOLOGY ADVANCES, BUT DESIGN CAN REGRESS
This is important.
New hardware doesn't guarantee:
better boxing.
A PlayStation 5 can obviously process more than a PlayStation 2.
But if developers decide not to simulate:
clinching,
referees,
deep Career,
or certain interactions,
the more powerful hardware doesn't magically add them.
Technology provides capability.
DESIGN DECIDES HOW THAT CAPABILITY IS USED.
That's why older games can still contain features newer games lack.
SEGMENT FORTY-ONE: "OLD GAME DID IT" IS NOT THE WHOLE ARGUMENT EITHER
Let's be fair again.
Older games sometimes used:
simpler animation.
Simpler AI.
Simpler physics.
Lower visual fidelity.
Offline-only shortcuts.
Scripted interactions.
Lower frame-rate expectations.
Less network complexity.
So:
"A 2001 game did it"
does not prove:
a 2026 implementation requires no work.
But it does justify asking:
WHY DID THE FEATURE DISAPPEAR INSTEAD OF EVOLVE?
That's the stronger argument.
SEGMENT FORTY-TWO: OFFLINE AND ONLINE NEED TO BE SEPARATED
This connects directly to another major Blueprint issue.
Suppose:
a realistic feature causes online synchronization problems.
Does that automatically mean:
remove it from offline?
No.
Ask:
CAN ONLINE AND OFFLINE USE DIFFERENT IMPLEMENTATIONS?
Offline does not require:
internet latency.
Remote synchronization.
Anti-cheat authority.
Rollback reconciliation.
So some systems can be richer offline.
The modes can share:
boxing rules
without sharing every technical constraint.
SEGMENT FORTY-THREE: INTRODUCING CONSTRAINT INHERITANCE
New development concept:
CONSTRAINT INHERITANCE AUDIT
Whenever a limitation is imposed, ask:
Why?
Online networking?
Okay.
Then:
Does offline actually inherit that limitation?
If the answer is no:
DON'T FORCE IT.
Same with:
competitive balance.
Ranked restrictions should not automatically control:
offline sandbox.
Tournament rules should not automatically control:
Universe.
Realistic mode should not automatically control:
Arcade.
Different modes can have different authority.
SEGMENT FORTY-FOUR: THIS IS WHY OPTIONS MATTER
I keep coming back to options because options solve ideological fights.
Player says:
"I hate clinching."
Fine.
Clinching frequency:
Low.
Player says:
"I want constant referee breaks."
Fine.
Referee strictness:
High.
Player says:
"I want realistic stamina."
Simulation preset.
Player says:
"I want faster action."
Hybrid.
Player says:
"I want arcade boxing."
Arcade.
Why should one design philosophy erase everybody else's experience?
Build:
SYSTEMS.
Then expose:
OPTIONS.
SEGMENT FORTY-FIVE: BUT OPTIONS CANNOT FIX A MISSING SYSTEM
This is important.
People sometimes say:
"Just give us sliders."
Sliders cannot create:
a referee
if no referee system exists.
A slider cannot create:
clinching
if there is no clinch architecture.
A slider cannot create:
inside fighting
if the locomotion doesn't support it.
A slider modifies:
AN EXISTING SYSTEM.
So:
BUILD THE SYSTEM FIRST.
Then give me sliders.
SEGMENT FORTY-SIX: THE "SHOW ME WHY" TEST
Here's today's main community tool.
Whenever someone says:
"THAT CAN'T BE DONE,"
ask:
Why?
Engine?
Animation?
AI?
Physics?
Network?
Performance?
Budget?
Schedule?
Design?
Licensing?
Priority?
Then ask:
Has another game solved part of it?
Then:
Could it be implemented offline?
Could it be simplified?
Could it be modular?
Could procedural animation help?
Could data-driven architecture help?
Could it be phased?
Could it be optional?
Now:
"CAN'T BE DONE"
becomes:
ENGINEERING DISCUSSION.
SEGMENT FORTY-SEVEN: WHAT I DO NOT WANT THIS COMMUNITY TO DO
Don't harass developers.
Don't call individual programmers lazy because a feature isn't there.
You usually don't know:
who made the decision.
Developers work inside:
budgets,
schedules,
management decisions,
technical constraints,
production plans.
Criticize:
the product.
The architecture.
The design decision.
The company decision.
The explanation.
Ask hard questions.
But keep the criticism:
SPECIFIC.
That's much stronger anyway.
SEGMENT FORTY-EIGHT: DON'T GIVE COMPANIES AUTOMATIC EXCUSES EITHER
Respecting developers doesn't mean:
accepting every explanation without scrutiny.
Consumers paid money.
Players can ask:
Why was this removed?
Why was this advertised?
Why did this change?
Why wasn't this finished?
Why did another system receive priority?
Will it return?
Is it technically blocked?
Is it a design decision?
Those are legitimate questions.
Accountability isn't harassment.
SEGMENT FORTY-NINE: THIS IS WHY COMPETITION MATTERS
If only one major company makes boxing videogames, what pressure exists?
If players want:
boxing
and only one product exists,
the market has limited leverage.
Now imagine:
SCI.
EA.
2K.
Another AA studio.
Several indies.
Suddenly everybody compares:
clinching.
AI.
Career.
Creation.
Boxer identity.
Online.
Presentation.
Value.
Now if one company says:
"WE COULDN'T DO IT,"
another company may say:
"WE DID."
Competition changes expectations.
SEGMENT FIFTY: THE FIGHT NIGHT REPORT MAKES COMPETITION EVEN MORE IMPORTANT
The September 18 reporting about the previous Fight Night project being cancelled is disappointing to many players.
But I don't want the conversation reduced to:
EA OR SCI.
I want:
EA AND SCI.
And:
2K.
And:
independent developers.
And:
new studios.
Why?
Because competition creates:
experimentation.
Different approaches.
Different priorities.
Different technologies.
Different business models.
Boxing should not depend on one developer's interpretation of the sport.
SEGMENT FIFTY-ONE: INDIE DEVELOPERS ARE PART OF THE LABORATORY
Small projects may not have:
AAA budgets.
Hundreds of employees.
Major licenses.
But they can experiment with:
physics.
AI.
Career structure.
Management.
2D systems.
Procedural animation.
Alternative controls.
If an indie discovers a brilliant solution to:
range,
inside fighting,
AI adaptation,
or Career simulation,
AAA developers should pay attention.
Good ideas don't care about studio size.
SEGMENT FIFTY-TWO: TODAY'S SURVEY MODULE
POE:
Community, here's today's survey.
QUESTION ONE
When a developer removes a major boxing feature, should the company explain why?
Yes.
No.
Only for previously announced features.
QUESTION TWO
Which explanation matters most?
Technical limitation.
Budget.
Schedule.
Design decision.
Online limitation.
Low priority.
QUESTION THREE
If a realistic feature creates problems online, should developers consider keeping a deeper version offline?
Yes.
No.
Depends on feature.
QUESTION FOUR
Should clinching be a fundamental boxing mechanic?
Yes.
No.
Optional.
QUESTION FIVE
Should an in-ring referee physically exist during fights?
Yes.
No.
Optional visual setting.
QUESTION SIX
Should referees have individual tendencies?
Yes.
No.
QUESTION SEVEN
Should inside fighting be a fully developed gameplay phase?
Absolutely.
No.
Basic only.
QUESTION EIGHT
Should ropes materially affect gameplay?
Yes.
No.
QUESTION NINE
If an older boxing game contained a feature that a newer game removes, should developers explain the design tradeoff?
Yes.
No.
QUESTION TEN
WHEN A DEVELOPER SAYS A BOXING FEATURE IS "TOO HARD," WHAT EVIDENCE OR EXPLANATION WOULD YOU EXPECT BEFORE ACCEPTING THAT CLAIM?
That's the question I really want answered.
SEGMENT FIFTY-THREE: QUESTIONS I WOULD ASK SCI
If Ash Habib sat down with me today, these are some of the questions I'd ask.
Not insults.
Not gotchas.
Development questions.
What specifically made clinching difficult in the original Undisputed?
Was the problem animation, physics, networking, locomotion or design philosophy?
Was removing or limiting clinching primarily a technical decision or a gameplay decision?
Did online architecture influence offline mechanics?
What prevented a persistent in-ring referee?
Was the referee issue primarily navigation, collision, animation, performance or gameplay?
How does the sequel's new foundation address those limitations?
Was inside fighting difficult because of the locomotion architecture?
Will inside fighting be treated as a distinct physical range in the sequel?
Will ropes affect boxer movement and defensive behavior?
Can the sequel's offline simulation operate with systems that may be simplified online?
Which features from the ESBC vision were intentionally redesigned rather than technically abandoned?
And one of the biggest:
WHAT DID YOU LEARN FROM THE ORIGINAL ARCHITECTURE THAT YOU REFUSED TO REPEAT IN THE SEQUEL?
That's the interview I want.
SEGMENT FIFTY-FOUR: QUESTIONS FOR EA IF FIGHT NIGHT RETURNS
If another Fight Night ever gets greenlit:
I don't want:
Fight Night Champion with better graphics.
Ask:
What can modern technology add?
Real referee AI?
Dynamic clinching?
Deep inside fighting?
Individual boxer tendencies?
Career Universe?
Creation?
Historical eras?
Modern commentary?
Procedural interactions?
Offline simulation?
CPU versus CPU?
If we're waiting more than 15 years:
MOVE THE GENRE FORWARD.
Don't just remaster expectations from 2011.
SEGMENT FIFTY-FIVE: QUESTIONS FOR 2K IF IT EVER ENTERS BOXING
If Visual Concepts ever made boxing, I would want to know:
How would its experience with:
sports AI,
large rosters,
creation systems,
franchise simulation,
presentation,
historical content,
statistics,
and athlete tendencies
translate to boxing?
Not:
COPY NBA 2K.
Instead:
APPLY MODERN SPORTS-GAME SYSTEM THINKING TO BOXING.
Huge difference.
SEGMENT FIFTY-SIX: TODAY'S BLUEPRINT ADDITIONS
Today's new Blueprint development systems:
Boxing Feature Feasibility and Accountability Framework
Feature Difficulty Classification
Technical Blocker Report
Legacy Feature Benchmark
Cross-Genre Feasibility Test
Clinch State Machine
Boxing Contact Anchors
Range Continuum
Ring Geography System
Referee Personality System
Recovery State
Damage Latency Model
Design Decision Ledger
Removal Reason Codes
Boxing Completeness Matrix
Feature Regression Audit
Constraint Inheritance Audit
Show Me Why Test
These connect directly to:
WeightTransferController.
FootworkController.
GuardWearManager.
GetUpManager.
Parry AI.
Clinch AI.
Referee AI.
Decision Bias Tree.
Offline/Online Authority Separation.
Realistic/Hybrid/Arcade presets.
Creation Suite.
CPU versus CPU.
Career.
Universe.
SEGMENT FIFTY-SEVEN: TODAY'S COMMUNITY CHALLENGE
Pick one boxing feature somebody has told you is:
TOO HARD.
Don't respond:
"That's stupid."
Instead break it down.
What makes it hard?
Animation?
Physics?
AI?
Networking?
Then find:
three games outside boxing that solve part of the problem.
Then ask:
What can boxing borrow conceptually?
Not assets.
Not copyrighted code.
The engineering principle.
That's how the community can elevate this conversation.
SEGMENT FIFTY-EIGHT: RAPID-FIRE COMMUNITY QUESTIONS
POE:
Chat, answer quickly.
Referee in ring?
Yes or no?
Full clinching?
Yes or no?
Working inside the clinch?
Yes or no?
Rope physics?
Yes or no?
Corner stoppages?
Yes or no?
Doctor stoppages?
Yes or no?
Delayed reactions?
Yes or no?
Arm fatigue?
Yes or no?
Guard wear?
Yes or no?
Different referees?
Yes or no?
CPU versus CPU?
Yes or no?
Separate offline simulation settings?
Yes or no?
And:
WHICH BOXING FEATURE ARE YOU TIRED OF BEING TOLD IS TOO DIFFICULT?
Put it in the chat.
SEGMENT FIFTY-NINE: RECEIPTS AND CLAIMS TO VERIFY
POE:
Before we close, here's what needs to remain separated.
CONFIRMED OR REPORTED
Steel City Interactive is developing Undisputed 2.
SCI has said the sequel uses a new technical foundation.
Daniel Dubois, Roberto Durán and Jermain Taylor have been announced.
Dubois participated in motion capture.
Reporting says SCI has grown beyond 100 employees.
Insider Gaming reported on September 18 that the previous plan for a Fight Night return had been cancelled roughly a year earlier.
That report also said the possibility of future discussions remains and that anything resulting from them would effectively be a new project.
NOT CONFIRMED
EA has not publicly announced a new Fight Night.
EA has not publicly declared that Fight Night will never return.
2K has not announced a boxing videogame.
Visual Concepts has not announced a boxing videogame.
SCI has not publicly demonstrated every major gameplay system discussed today.
OPINION OR INFERENCE
My belief that some missing systems in boxing games may reflect design priorities rather than pure technical impossibility is:
MY ANALYSIS.
It should not be represented as confirmed internal knowledge.
My suspicion that some features could have been deferred for future products is:
A QUESTION AND AN INFERENCE.
It is not proof that any company intentionally withheld a completed feature.
That distinction protects the credibility of this show.
SEGMENT SIXTY: THE BIGGER POINT
The goal isn't:
CATCH DEVELOPERS LYING.
The goal is:
STOP USING VAGUE LANGUAGE TO END TECHNICAL CONVERSATIONS.
If it's difficult:
tell us why.
If it's a design choice:
say that.
If it's expensive:
say that.
If online prevents it:
say that.
If the schedule prevented it:
say that.
If you don't think players want it:
show us the research.
If it's coming later:
say it's deferred.
If you changed your vision:
own the design change.
That's communication.
CLOSING MONOLOGUE
POE:
I'm going to close today's show with this.
I am tired of seeing the word:
HARD
used like a period at the end of a sentence.
Clinching is hard.
Period.
Referee is hard.
Period.
Inside fighting is hard.
Period.
No.
Put a comma there.
Clinching is hard,
BECAUSE?
Referee is hard,
BECAUSE?
Inside fighting is hard,
BECAUSE?
That's where the conversation starts.
I don't expect game developers to perform magic.
I don't expect unlimited budgets.
I don't expect unlimited development time.
I don't expect every feature I've ever written about to appear in Version 1.0.
But I do expect something else.
DON'T TELL BOXING FANS THAT BOXING ITSELF IS TOO MUCH FOR A BOXING VIDEOGAME WITHOUT EXPLAINING WHY.
Because once we know why?
We can talk about solutions.
Referee causing camera obstruction?
Solve camera interaction.
Referee navigation?
Build referee navigation.
Clinch animation complexity?
Build contact anchors.
Use procedural adjustment.
Use state machines.
Online synchronization?
Ask whether offline needs the same constraint.
Inside fighting?
Build range and body-position systems.
Rope interaction?
Treat ropes as gameplay geometry.
Get-up system?
Track recovery state.
Block fatigue?
Track localized fatigue.
Delayed reactions?
Separate immediate and delayed damage responses.
These aren't guarantees.
They're:
ENGINEERING DIRECTIONS.
Some will work.
Some won't.
Some will be too expensive.
Some will need redesigning.
Some may have to wait.
That's development.
But at least now we're talking about:
THE PROBLEM.
And I think boxing videogame communities have been conditioned for too long to accept missing boxing features because:
"Well, game development is hard."
Of course it is.
Making an airplane is hard.
Building a skyscraper is hard.
Performing surgery is hard.
Nobody says:
"The brakes were difficult, so we left them off the car."
You determine:
which systems define the product.
Then you engineer around them.
For me:
clinching defines boxing.
Inside fighting defines boxing.
Ring geography defines boxing.
Refereeing defines boxing.
Fatigue defines boxing.
Boxer individuality defines boxing.
Defense defines boxing.
Damage defines boxing.
Strategy defines boxing.
Those are not decorations.
So when we're deciding what deserves engineering resources?
Start there.
And this is also why I keep talking about competition.
If SCI says:
"We chose this direction,"
fine.
Maybe EA chooses another.
Maybe 2K chooses another.
Maybe an indie solves something all three missed.
Then players decide.
That's how videogames improve.
Competition doesn't hurt boxing fans.
LACK OF COMPETITION DOES.
Because when there is no alternative, there's less pressure to prove:
why something can't be done.
And I don't want the next generation of boxing videogames built around:
WHAT CAN WE GET AWAY WITH LEAVING OUT?
I want them built around:
WHAT DOES BOXING REQUIRE?
Then:
How do we implement it?
How do we scale it?
How do we optimize it?
How do we synchronize it?
How do we test it?
How do we make it optional for people who don't want the deepest simulation?
That's development.
Realistic/Sim.
Hybrid.
Arcade.
Options.
Different players.
One boxing foundation.
And here's the challenge I want everybody to take from today's show.
The next time somebody says:
"POE, THAT'S TOO HARD TO PUT IN A VIDEOGAME,"
don't argue.
Ask:
WHAT SPECIFICALLY MAKES IT HARD?
Then listen.
If they have a technical explanation?
Good.
Now we have something to discuss.
If they don't?
Then:
"IT'S HARD"
was never the explanation.
It was the excuse.
And there is a difference.
This is Poe.
This is Poe & The Community Speaks.
My opinions are my own.
I don't owe SCI an automatic positive opinion.
I don't owe EA an automatic positive opinion.
I don't owe 2K one either.
And I don't automatically owe any company a negative opinion.
SHOW ME THE BOXING.
Show me the systems.
Show me the decisions.
Show me the improvement.
Show me what changed.
Show me what you learned.
And when something is missing?
SHOW ME WHY.
Community, put this in the comments:
WHAT BOXING FEATURE DO YOU WANT A DEVELOPER TO STOP TELLING YOU IS TOO DIFFICULT?
Then answer the second question:
HOW WOULD YOU TRY TO SOLVE IT?
That's where this community becomes more than people complaining about videogames.
That's where we start building the blueprint for what comes next.
A realistic boxing game can make a hardcore fan out of a casual.
Competition can make every boxing videogame better.
And technology should be used to represent more of boxing,
NOT TO EXPLAIN WHY WE SHOULD ACCEPT LESS OF IT.
Weekly Boxing Show Add-On: A Boxer Has to Be More Than an Action Figure
I keep hearing about how many boxers are in a game and how good their character models look. I appreciate a strong roster and accurate visuals. But when I select a boxer, I want to feel the difference before I ever look at the name above the health bar.
A boxer is more than a face, a pair of trunks, and a few signature punches. What makes that boxer recognizable is how they fight. Do they pressure behind a jab or wait for a counter? Do they cut off the ring or follow their opponent? What happens when they get hurt, tired, frustrated, or forced to fight at a distance they dislike?
That identity needs to come from mechanics, tendencies, attributes, traits, capabilities, and mannerisms working together. Footwork and balance should affect where a boxer can punch from. Defensive habits should shape what openings they leave. A boxer who likes to work inside should know how to get there, what to do there, and when to clinch or step out. A disciplined counterpuncher should not suddenly fight like a reckless pressure boxer just because every character shares the same basic AI.
And ratings alone cannot solve this. Giving one boxer an 88 jab and another an 82 does not tell us when they throw it, why they throw it, how they set it up, or what they do when it stops working. Deep sliders and boxer-specific tendencies should let developers build those decisions into each boxer. Traits should have visible effects, including strengths, limits, and habits an opponent can study and exploit.
That matters for player-controlled boxers too. The controls should let me express a boxer’s style, while their physical capabilities and learned habits give that style its character. If I choose a slick defensive boxer, I should have the tools to create angles and draw mistakes. If I choose a heavy pressure boxer, closing distance should involve positioning, risk, and work. Neither should feel like the same character wearing a different skin.
This is why I push for a realistic boxing game. I want the roster to represent the sport, not just resemble it in screenshots. I want to watch two CPU boxers and recognize their approaches. I want to pick a boxer and learn what makes them effective, what makes them vulnerable, and how they adapt over twelve rounds.
Give me the great likenesses. Give me the entrances, robes, commentary, and presentation. But make the boxer inside the ring worthy of the name on the selection screen. That is the difference between collecting boxing action figures and playing a boxing game that understands boxers.
Question for the community: Which boxer have you played in a game who looked right but fought nothing like themselves? And what specific behavior would have made them feel authentic?
.png)
.png)
