There's no set way to write for video games. As a medium it's relatively young and the methodologies are constantly changing as the technology changes. Compare that to other mediums and you'd be amazed that anyone can get anything done. But then a project that requires more than one person is a feat of social engineering.
"You must stay drunk on writing so reality cannot destroy you." - Ray Bradbury
Writing became standardized in other mediums for a number of reasons. Probably the most prominent factor is the commercial aspect of them and the need to turn around and create content quickly. It's a demand on time that leaves little room for niceties, but does allow a great amount of experimentation - it's just another constraint. But one that serves a good purpose. For more on such constraints be sure to check out the episode on just such a topic Rule The World.
Cinema has been an industrial artwork for over 100 years. Theater, opera and other performance arts for even longer. So it makes sense that they'd develop best practices for their crafts to smooth out the production process, which of courses includes writing.
Hell, I write this series using the screenplay format on Scrivener. Why? Because while it eventually becomes a blog post I need it structured in such a way that it makes reading it easy for when I record. Shakespeare may like soliloquies but that doesn't make them very natural. The constrained format of the screenplay offers a concise measurement of how long a particular piece will take to read aloud as well a clear delineation between lines and who's speaking.
Whatever format you write in isn't terribly natural. All forms have been created and evolved by humans to serve a particular purpose. And the same is true for whatever form you work in when writing video games - it has to serve your purpose. The difficulty in writing for video games comes in deciding on the form. There are numerous ways to do it and inevitably every team develops their own methods, tools, markup or language for addressing the inclusion of text. Whatever you do, whatever tool you use, you need to be consistent.
Make a model. To help you be consistent. Make a model to aid programmers, narrative designers, UI/UX designers, game and sound designers, really anyone else working on the game. Anyone who needs to read or interact with what you're writing will need to know how you structured everything. So make a model.
It's not uncommon to hear games writers talking about working in spreadsheets. Fact is spreadsheets are a common site amongst game developers because they're incredibly useful for how they display information both vertical and horizontally. Traditional word documents and even developer environments work vertically with a limit to their horizontal width. And while dialogue may be written in the traditional manner of whatever language you're working in, there's a lot of other details you'll probably find yourself having to add. Notably which character is speaking, camera and character directions, inputs, variables and more.
Spreadsheets can make that easier to write and, most importantly, parse. Again it's not just you who has to read what you've written, but your teammates, and computers. Surprisingly, or maybe unsurprisingly, both people and computers can be quite literal in their interpretations of what you've written. They don't automatically comprehend your intentions, so anything vague or ill-defined will either be dismissed outright or provoke some sort of an error. With computers errors are relatively easy to understand and fix. With humans - not so much.
Whatever way you write your script, in whatever program you use, in whatever language you're fluent in - be consistent. Consistency counts far more than good writing. When it comes to getting a game made it's the first priority. It may sound sad but if you're not writing everything in the same manner then what you do write won't necessarily end up in the game.
You as a writer can't be precious about your words and want to expand the form and show people a new truth, to drill down into the soul and the essence of what makes us human. You can't aim to delight, entertain, offend, provoke or intrigue a player if your words can't be placed in the game. You can bleed on the page all you want but that page still needs to be legible and turned in Hemingway
What Makes a Model
So what does a model look like and what's it entail?
To begin with it can be one file or many files. It depends how you structure everything. If you're working in a narrative scripting language like Ink then you can readily create projects that call files and reference lines written in those files. This is perfect for writing things in small batches that pertain to certain variables within your game. But more on that in a bit.
If you're working in something like Twine, then chances are you'll be making something more visual in its structure. This method is great if you're a visual thinker and need to separate things out, or you want to see how they flow together. Of course, as mentioned before if you're using a spreadsheet then... well... things will be very condensed. The beauty of spreadsheets is the ease in which you can add in variable lines of dialogue. Branching paths takes some extra work.
Whichever means you choose to write and structure your video game script you're still going to need to go one step further when it comes to being concise. You need to have consistent markup.
Every time you write a URL you're writing markup, specifically Hyper Text Markup Language, or HTML. Whatever form of markup language you use, whether it is something like HTML, or Ink's own markup, or even Twine's three varieties of markup, you have to be consistent. That's the purpose of markup languages. They tell the computer how to treat different parts of your script. And as mentioned before they tell programmers and designers how to work with your text.
Markup is used to differentiate between just about everything your script can be used for. So you signify which characters are speaking, where and when the lines are to be used, if something is part of the UI or other element, even what variables are going to affect and/or trigger. If you're using a narrative scripting language like Ink, then the markup can be used to affect most aspects of the game. That ability is dependent upon many factors including design and integration of any required plugins. In Ink's case, its creators Inkle have released a plugin for Unity.
So... You're probably asking yourself what should be in the script for my video game. If I say everything you're going to run away screaming. If I say just the text that doesn't convey anything. Mainly because in a video game unlike other mediums there's context to be taken into account.
Context matters because without it anything could happen at any time and the entire purpose of any structure, especially for the story, would be lost. Player characters wouldn't be able to say the lines assigned to them. NPCs could be sprouting anything, including variables or spoilers. UI elements may mislead players. In essence a game would be unplayable.
That's why with you need to be consistent with your markup and signify the difference between the various types of dialogue a particular character can say. Those times include dialogue for idle situations, failure states both big and small, success, item interactions, and combat barks; animations; cutscenes; tooltips; tutorials; and anything else that needs to be written.
Most games and game companies don't have editors. The few that do tend to be RPG-focused studios like Bioware or Larian. They have to deal with so much text and story that to handle it all and keep track of it requires an editor or editors. But most game companies don't work that way. It's not like working on an article or book, where everything you write is being scrutinized by someone else or a couple of people. Sure others may interact with what you write but they aren't there to check it for mistakes or make sure the story works. They're just trying to implement it.
It leaves all that work on your shoulders, so it's best to save yourself and anyone you're working with some trouble if you learn to be consistent sooner rather than later. Markup languages aren't any harder than basic punctuation. You're simply using them more often.
The other major aspect of writing for video games when making your model is identification. Everything needs to be easily accessible by the computer and that means it needs an ID.
It's not a passport, but it's a string, or in more common parlance a name, similar to that of a file or a folder on your computer. Only it's good practice not to include spaces but rather use underscores.There's a lot of ways to name things, whether it's a folder, file or string. But again, here is where consistency counts. Mainly because humans, mainly you, are going to be using the IDs. It's not just the computer.
If you need to find a particular line, and you may be writing thousands of them, then you want to do it swiftly. Looking for particular words is likely to throw up dozens if not hundreds of times that word occurs. IDs save time. But to save that time you need to have a consistent way of naming each line. The ID can include the name of the character speaking the line, the location it occurs and when. Naming conventions can get quite complex depending on the game.
Take any open world game, like Far Cry 5, there are countless NPCs. Each of which needs lines that are dependent on age, gender, time of day, location, and situation. And to keep it from getting boring there needs to be variation of each. For that game alone there's something like 15,000 lines for the NPCs alone. That doesn't include story.
Where to Start
So the big question is - where to start when it comes to making your model? One talk to your team. Find out their needs. You're not doing this alone, so the model has to be usable by both artists, designers and programmers. Two, plan out all of the different types of text you'll need. And all of the situations in which dialogue will occur. As mentioned before that includes dialogue for idle situations, failure states both big and small, success, item interactions, and combat barks; animations; cutscenes; tooltips; tutorials; and anything else that needs to be written.
That's not even thinking about what needs to be possible in a game like Firewatch which had thousands of lines, many of which only occur if the player picks a particular one hours earlier. Granted Firewatch is an open world but it's one devoid of crowds of NPCs, so the complexity comes in modeling the story and not everything else. However Campo Santo did it, consistency was inevitably the key. And your success at writing a video game script will require the same thing.