Skip to main content

Can the game do it?

Every line of your design document is written in plain language, and you understand it. The game does not read your design document. "The buyer holds eye contact", "the scene happens in an alley", "the deal goes down in gang territory": for the game to bring those sentences to life, something inside the engine has to be able to do it, and something has to be able to detect it. Your design job at this stage is to ask the question before your first line of code: can the game do it, and how will it know?

I learned this the hard way, and AI made the lesson more expensive. Ask a chatbot what animation the game plays for "a discreet gesture": it invents a name, full of certainty. That name produces nothing once the game runs, no error, no crash. So we do not guess a name. We check that it exists in the game, or we record that it is still to be found before moving on. The rest of this lesson shows the difference, and why it decides the fate of your design document.

What the game needs to know​

Every intention in your design document deserves the same four questions:

  • What do I want the game to do?
  • What does the game have to know to do it?
  • Does the game have a way to know it?
  • What do I need to detect or measure, exactly, to turn my plain-language sentence into a checkable fact?

Take the intentions of your own scene, one by one, and ask them these questions.

"He holds eye contact": the game must be able to direct one character's attention at another. Does a behavior exist for that? You search the native tables, and until confirmed, the intention remains marked as unverified.

"In an alleyway": nothing in the engine wears an "alley" label. The world is geometry and roads. You invent the definition, and a definition has to be measurable: walls tight on both sides, a narrow opening, away from a busy road. Once you have chosen, you check the game can measure distance and detect walls nearby.

"In gang territory": no map draws gang borders for you. You decide what proves it: a map zone, gang members around you, or a territory list you define and feed to the game. Every option is a capability to check.

"Making a discreet gesture": an animation has to exist in the game files, and a small object has to exist to place in the character's hand. You find both by their real names in the real lists, not in your imagination.

The trap of invented names​

Skip this check and your design document fills with things the game has never heard of. You write an animation name like anim@drug_deal@nod that no dictionary contains, or a prop hash pointing at nothing. These are strings: nothing screams the moment you type them sentence by sentence, because the game only finds out when it tries to load them. But you are not blind to it. A guessed animation name fails to load, and the engine has a way to tell you — request it and check the load status. A guessed method on a typed API like World.IsPlayerInAlley() does not even compile: C# rejects it at build time. Failure occurs whenever an asset name is used without verifying its load status.

How the game can answer​

"Can the game do it?" receives three kinds of answers, and knowing them lets you search instead of guess:

  • A native is a function the engine exposes to your script, one engine behavior under a public name. Whenever you want the game to do something, your question becomes: is there a native for it?
  • An animation covers the gestures the game never invents by itself. Every walk, every signal, every punch is a clip stored in the game's files and played on a character. Your intention can rest on an animation; you need its dictionary and its clip, both real.
  • A model or a prop is whatever you place in the world. A bag, a phone, a gun laid on the table: each has a name in the game's lists. If the name does not exist, nothing appears.

These lists are public: CitizenFX's native index documents native names and arguments, while Pleb Masters Forge animations and objects help identify assets. Check an identifier in the reference and, later, in the game. Do not fill the GDD with names recalled from memory.

Keeping unknowns visible​

At this stage of design, every intention falls into one of two states: either the capability exists in the game and its verified identifier is recorded, or it has not yet been verified.

The dangerous shortcut is filling the gap with an approximate name to make the document look complete. An invented name creates false confidence. Keeping the uncertainty explicit shows exactly what remains to be investigated in the reference databases before writing a single line of code. If the search comes up empty, the intention gets rewritten while the scene is still just a sentence.

The output of this stage​

By the end of conception, the design document is accompanied by a list: every intention calling for a native, an animation, or a model appears with its verified identifier or the note that it still needs to be confirmed. Intentions without a technical anchor become immediate candidates for redesign. Changing a sentence now costs nothing. Finding out halfway through the build that the game cannot do it costs you an afternoon.

Before writing code, update the mod's GDD with this list. It gives the first code increment a concrete starting point; revise it again when a test disproves an assumption.