Your CMF application may make perfect sense to your team and still be unclear to the analyst reading it.
That is one of the hardest parts of writing a funding application.
Inside your studio, everyone has context. You know the genre references. You know the internal shorthand. You know why a mechanic matters, why a feature is exciting, and why a certain design choice solves a real problem for the player.
The analyst does not have that context.
That does not mean the analyst is uninformed. It means they are not inside your team’s head.
A strong CMF application explains the project in a way that someone outside the team and who's not as familiar with industry conventions as you can understand.
Meet the analyst
When I write CMF applications, I often imagine a fictional CMF analyst named Jessica.
Jessica may not resemble the actual person reading the application. That is not the point.
The point is that Jessica reminds me to write for someone who is intelligent, busy, and evaluating the project against specific criteria, but who does not share my team’s shorthand or familiarity with gaming culture.
She may understand interactive digital media. She may understand basic game terminology. She may have read hundreds of applications across different types of projects.
But she should not be expected to understand every genre convention or technical term.
Thinking about Jessica helps me ask better questions while writing:
Would this sentence make sense to someone outside the team or games industry?
Am I assuming the analyst already knows the genre convention I am challenging?
The real analyst may be different from Jessica. That is fine.
The exercise still works because it forces you to write with the intended audience in mind.
Your analyst is not your teammate
Your teammates know the project history.
They know why a system was designed a certain way. They remember the old version of the mechanic. They understand the references from other games.
The analyst does not have that same history.
This is why a sentence that feels clear internally can be confusing in an application.
For example:
“Our game uses roguelite progression to create replayability and deepen the cozy farming loop.”
That may be true, but it leaves several questions open.
- What does roguelite really mean?
- Why does it create replayability?
- How does this support the player experience?
- Why is this relevant to the application?
A stronger version might be:
“The game uses run-based progression, where each attempt gives the player new choices, upgrades, and strategic lessons for the next run. This structure supports replayability by making each session feel different while still giving the player a sense of long-term growth.”
In the end, you are trying to remove any unnecessary ambiguity.
Jargon is useful only if defined
Game terms are not bad.
Words like roguelite, friendslop, cozy, tower defense, deckbuilding, procedural generation, etc. can be useful. They help position a project quickly.
But those terms should not carry the entire argument.
If a term matters to your application, explain it in plain language.
This is especially important when the term is tied to originality, innovation, interactivity, or commercial potential.
For example, if you say your game uses procedural generation, the analyst needs to know what is being generated and why it matters.
Are you generating levels?
Enemy waves?
Dialogue?
And more importantly, what does that generation improve?
Does it create replayability?
Does it support production efficiency?
Does it create emergent player stories?
The term itself is not enough. The value of the term needs to be clear.
Explain the convention first
If your project is original because it challenges a familiar genre, the analyst needs to understand the familiar expectation first.
You cannot assume they will know the convention you are changing.
A useful structure is:
- Most games in this genre usually do X.
- Our project does Y.
- This matters because Z.
For example:
“Farming games often treat crops as resources to collect, sell, or craft with. In our project, crops also shape the player’s defensive strategy. This means that farming is not only a preparation phase, but a direct part of how the player survives.”
This structure helps the analyst understand the originality claim.
It does not simply say the project is different. It explains different from what, how it is different, and why that difference matters.
That is much stronger than expecting the analyst to understand the innovation automatically.
Be careful with CMF terminology
The language CMF uses does not always match the language game developers use and it can have huge repercussions on your score.
Sometimes a word that feels normal in a studio context may create confusion in a funding context. Audience terms, genre labels, platform language, and monetization language can all carry specific meaning.
For example, if CMF uses a specific definition for an audience category, do not assume a similar everyday term means the same thing.
If your game has chance-based mechanics, be careful with wording so the project is not misunderstood as something it is not.
If your application depends on a specific form of innovation, make sure the wording matches what the program is asking for, not just how your team normally talks about the feature.
This is why reading the guidelines and supporting documents is crucial.
The goal is to avoid creating unnecessary questions.
Unclear wording can make them pause, question, or misunderstand something that could have been simple, and could outright disqualify your project.
Clarity helps the analyst champion the project
A strong application does more than avoid confusion.
It gives the analyst the language they need to understand and explain the project.
Your project is being evaluated alongside many others. A clear application makes it easier for the strongest parts of your project to stand out.
If your application is difficult to follow, the analyst has to spend extra energy untangling what you mean.
If your application is clear, the analyst can spend that energy evaluating and getting excited about the project.
That is the experience you want to create.