44 minutes ago, Tom Sloper said:

It's a terrible practice, period. Makes polishing, editing, and additional DLC more time-consuming than necessary.

We'll, except when you need specialised writing tools to effectively manage massive non linear stories, so you invest in building your own tools that make this job easier, and your writers agree and love writing content directly in the engine... 

In a typical month, I'll work on nonlinear dialogue with a dozen different developers, from AAA to lone indies. Many prototype in-engine. All use some kind of node-based or outline-based editor that facilitates linking. But, almost invariably, their actual production workflow will also incorporate a way to import and export to a standard format such as Excel or dedicated authoring software such as articy:draft or Chat Mapper. Excel is still a popular import/export format because translators are comfortable working in it for localization and spell checking.

I realize this is getting a bit off-topic. For the original poster, if you're still looking for writing examples, you could search public github and bitbucket repos for files in these formats: Excel (.xls/.xlsx), Final Draft (.fdx), Chat Mapper (.cmp), and articy:draft (.aph). For the latter three, you'll need those applications to be able to read the files.

I concur that you’re probably best off just playing the games and paying attention to the writing wherever it is, whether it’s audio, text, or in-game objects, subtitles on cutscenes, whatever.

To add to the growing subtopic: adding text straight into the engine is ok for prototyping but if you ever want to translate your game into another language, you’re going to want a dedicated file with the text values you’re using... localization any other way sounds like an absolute nightmare.

To add to the growing subtopic: adding text straight into the engine is ok for prototyping but if you ever want to translate your game into another language, you’re going to want a dedicated file with the text values you’re using... localization any other way sounds like an absolute nightmare.

Just use gettext. That's what I do. You can even auto-detect the strings that need to be translated with xgettext, and then localization is just a matter of using msginit, then filling in the values in the created .po file.