Bad Ports
When conversions fail
The phenomenon of poorly-executed platform conversions that failed to capture the original game's essence, from Pac-Man 2600 to countless rushed arcade conversions.
Bad ports are game conversions that fail to translate the original experience to a new platform. Whether due to impossible hardware limitations, rushed development, or incompetent execution, bad ports became a persistent problem throughout gaming history.
Fast facts
- Era: Ongoing since 1980
- Causes: Hardware limits, rushed schedules, low budgets
- Impact: Consumer distrust, returns, industry damage
- Notable: Pac-Man 2600, various US Gold titles
The conversion problem, from inside it
⚠ A cause the table below omits: the converters could not read the original.
Anthony Ball, who converted Mercs at Tiertex, puts it plainly:
The programmers had no access to the original arcade source code — the game had to be played over and over again in order to make the conversion accurate.
An arcade conversion was a reconstruction from observation. Whatever a home version got wrong, it got wrong having watched the coin-op rather than read it.
And the schedule was the business model, not a failure of it. The same account answers this entry’s “Various Tiertex — generic, rushed” verdict from inside the studio: “A lot of people used to complain about Tiertex games, but when you think that virtually every one from Tiertex was coded and published within six months it’s pretty impressive.” Speed is why the work came: “Tiertex was very quick at arcade conversions. US Gold must have been pleased with the speed of output and I had the impression that Tiertex had the pick of the best arcade games that US Gold licensed.”
That does not make a bad port good. It does mean “rushed” describes a contract rather than a lapse.
⚠ A caution about the evidence. Period review scores may not describe the game that shipped. On Mercs: “The magazines played easier versions of the game than were released. The game that came out was much harder than the review copy.”
Classic examples
| Game | Platform | Problems |
|---|---|---|
| Pac-Man | 2600 | Flickering, wrong maze |
| OutRun | Spectrum | No sprite scaling |
| Street Fighter II | 8-bit | Unplayable framerates |
| Various Tiertex | Multiple | Six-month schedules, no access to arcade source — see above |
Causes of Bad Ports
| Cause | Result |
|---|---|
| Impossible hardware | Core mechanics can’t work |
| Rushed schedules | No time for quality |
| Low budgets | Cheapest developer wins |
| Single developer | One person, complex game |
| No platform expertise | Generic approaches |
| No access to the original | Conversion by observation, not from source |
The Pac-Man 2600 Lesson
| Fact | Detail |
|---|---|
| Developer | Tod Frye, alone |
| Timeline | 5 weeks |
| Sales | 7 million |
| Returns | Millions |
| Impact | Helped cause 1983 crash |
Consumer Impact
| Effect | Consequence |
|---|---|
| Distrust | Check reviews before buying |
| Returns | Retailers lose money |
| Brand damage | Publishers lose credibility |
| Platform reputation | “Can’t do arcade games” |
Good Ports vs Bad Ports
| Good Port | Bad Port |
|---|---|
| Uses platform strengths | Ignores hardware |
| Captures essence | Misses the point |
| Appropriate adaptation | Literal but broken |
| Adequate time/budget | Rushed and cheap |
Legacy
Bad ports taught the industry that conversions require expertise, time, and money. The best ports reimagine games for new platforms; the worst fail to run the original.