Reference Works Are More Than a Watchlist: How to Analyze 5 Competitors Without Copying Them
The purpose of competitor research is to find verifiable design relationships, rather than collect “works I like”: which mechanisms deliver a particular promise to players, how much content production costs, and where players feel confused or disappointed. The most effective approach is to choose five works that each answer a different question and analyze them using the same table, rather than imitate the subject matter, characters, and plot sequences of one work.
Introduction
The purpose of competitor research is to find verifiable design relationships, rather than collect “works I like”: which mechanisms deliver a particular promise to players, how much content production costs, and where players feel confused or disappointed. The most effective approach is to choose five works that each answer a different question and analyze them using the same table, rather than imitate the subject matter, characters, and plot sequences of one work.
This article presents five sample categories and an analysis method suited to planning interactive movie games. It relies on public store pages, official descriptions, public videos, and traceable player feedback; pacing, the feel of making choices, and performance effectiveness still require hands-on play.
Give the Five Samples Five Different Jobs
The first is a direct competitor: its target audience, platform, and content format are all close to those of your project. It helps you determine what expectations players have already formed about the category.
The second is a mechanics benchmark: its subject matter can differ, but it clearly implements a mechanic you plan to use. For example, if your project includes timed decisions, choose a work with clear feedback for timed choices.
The third is a cost benchmark: its team and asset scale are close to yours. Large productions can provide inspiration, but they cannot answer how a three-person team should schedule its work.
The fourth is a failure sample: public feedback repeatedly mentions problems such as “choices do nothing, pacing drags, and branches are impossible to track.” It helps the team establish examples of what to avoid in advance.
The fifth is an adjacent medium: this could be a short drama, visual novel, escape-room experience, or investigative podcast. Use it to learn ways of organizing and communicating information, rather than directly copying gameplay.
If all five samples are popular works with the same subject matter, the research can easily become a collection of art and plot references that cannot support product decisions.
Start the Analysis with the Promise, Rather Than a Plot Summary
First, record how the store page or official page describes the product. Steam’s store page documentation requires developers to prepare descriptions, trailers, screenshots, and other content. These materials are also the work’s public promises to players. Circle the verbs in the short description: investigate, choose, escape, build relationships, or change history?
Next, record how the first ten minutes deliver on that promise. When does the player first perform the core action? Do they have enough information? After a choice, is feedback immediate, delayed, or is there no visible change?
Then record the branching structure and production approach: the number of choice points, distinct scenes, characters, reused material, convergence points, endings, and replay features. Only then examine the subject matter, visuals, and writing style.
Use Consistent Fields to Avoid Recording Only “It Feels Great”
Record at least the following fields for each sample:
| Field | Question to Answer |
|---|---|
| Target players | Who comes to the work, and to meet what need? |
| Public promise | What does the official description explicitly say players can do? |
| First delivery | How long before players perform the core action? |
| Main mechanics | Choices, QTEs, evidence gathering, resources, or relationships? |
| Feedback method | How do players know their actions have changed something? |
| Branching cost | Which content is truly distinct, and which is reused? |
| Replay support | Returning to earlier states, chapters, skipping read content, route hints? |
| Publicly reported problems | What specific problems recur in reviews? |
| Transferable principle | What method can be abstracted, rather than what content can be copied? |
| Conditions where it does not apply | Why might it be unsuitable for your team? |
Public reviews can only serve as leads about problems; a few reviews do not justify writing “players generally believe.” Record the original links, dates, and versions; when you need to reach a conclusion, verify it through hands-on play or additional sources.
Turn Examples into Principles to Avoid Copying
Suppose a work makes players decide whether to answer a phone call before a countdown ends. You cannot simply transplant the “countdown phone call” into 《零点回拨》. Instead, keep asking: what problem does the countdown solve? If the answer is that it forces players to reveal whom they trust when information is incomplete, the transferable principle is “use time pressure to amplify a character’s stance, rather than increase the difficulty of execution.”
Likewise, when you see a work display clues through a phone interface, you cannot just imitate its chat bubbles. You need to determine whether the phone interface allows repeated review of information, reduces the amount of filming, or puts the player in the role of an investigator. Preserve the functional relationship and redesign its presentation.
One practical method is to write two columns: put “what the work specifically does” on the left and “the problem it solves” on the right. Only the content on the right may enter the project’s design discussions.
A Demonstration Using 《零点回拨》
This project needs five types of references: an FMV work driven by pivotal choices, to observe the transitions between video and options; an investigation game, to study evidence credibility; a high-pressure short drama set in a single location, to study pacing on a low budget; a visual novel with multiple routes, to study state convergence; and an interactive work with poor public feedback, to collect examples of illusory choices and replay friction.
The final conclusion should be three to five constraints, rather than “make it like such-and-such work.” For example: verify a call from the future once within the first three minutes; allow key evidence to be reviewed; each choice must change at least one of information, relationships, or the path; major branches must converge within one scene; failure endings must provide new information.
The Completion Criteria for Competitor Research
After analyzing all five samples, delete every note that cannot change a decision. What remains must answer: what we should uphold, what we should avoid, what we should verify, and which capability still lacks evidence.
If the research only adds reference images and plot summaries without changing the scope, mechanics, or prototype, it is still just a watchlist.
