One of the biggest mistakes game developers make in CMF applications is treating the application like a game design document.
As developers, we understand our projects through mechanics, characters, and stories. When someone asks us to explain the project, our instinct is to go straight to what is most exciting to us:
- How does the gameplay loop work?
- What makes the progression interesting?
- What is the lore?
- What are all the features we want to build?
Those things are important but they belong in your game design document, not necessarily your CMF application.
A design document and a funding application have different jobs
A game design document is an internal tool. It can be messy, super detailed, technical, and specific to your team’s process.
It can include:
- mechanics
- controls
- systems
- lore
- enemy behaviours
- future feature ideas
- team-specific jargon
That is useful when you are building the game or onboarding new people to your project.
But a CMF application is not written for the same purpose. It is written for evaluation.
The application should help someone understand:
- what the project is
- what makes it distinctive
- why the audience will care
- why the team can execute it
- how the project fits the program criteria
That means your CMF application should not be a compressed version of your design document.
It should be a curated argument.
More detail is not always better
When teams are close to a project, every detail can feel important.
You may want to explain every system because they all connect. You may want to describe the full world because the story feels central to the experience.
The problem is that too many details can make the application harder to understand.
An analyst should not have to dig through a long gameplay explanation to find the main argument. They should not have to figure out why a mechanic is innovative or increases commercial potential by themselves.
Every detail in the application should have a job.
If a detail supports a clear claim, keep it.
But if the detail is only there because it exists in the design document, it may not belong in the application.
If the game is unclear to you, it will be unclear to the analyst
If the team does not have a clear grasp of the core experience, the application will usually reveal it. The draft may become too long or too vague, because the team is still trying to figure out what the game actually is while writing the application.
That uncertainty is super obvious to an analyst.
This does not mean every detail needs to be final before you apply. Games evolve, and analysts understand that. But the central argument should be crystal clear.
You should be able to explain:
- What is the core experience?
- What makes the project distinctive?
- What does the player do repeatedly?
- Why will the audience care?
- Which parts of the design best prove the project’s originality, innovation and commercial potential?
If those answers are not clear yet, it will be difficult to write a convincing application.
Turn features into arguments
Developers often write in feature language.
For example:
“Our game blends farming and tower defense.”
That sentence explains what is in the game, but it does not explain why the blend matters.
A stronger version turns the feature into an argument:
“Our game connects farming choices directly to defensive strategy. What the player grows affects how they prepare, take risks, and survive, turning farming and defense into one connected core loop.”
The first version lists the genre blend.
The second version explains the impact on the player experience.
That is the kind of shift you want throughout the application.
Instead of only asking:
“What feature does the game have?”
Ask:
“What does this feature actually prove?”
Use examples, but choose them wisely
Specific examples are important in a CMF application. Broad claims are rarely enough on their own.
If you say the mechanics are innovative, show how one mechanic changes the player experience compared to other games in that space.
If you say the project has commercial potential, point to actual data and evidence.
The goal is not to include as many examples as possible. The goal is to choose examples that prove the claim best.
A useful example should help the analyst understand one of three things:
- What the feature is.
- Why it matters.
- How it supports the application’s argument.
For example, if your game has ten enemy types, you probably do not need to describe all ten in the application. But if one enemy type perfectly demonstrates your innovation, that example is definitely worth including.