I think it is too easy to be the 'wither-than-white' guy and recommend warmly using an external text resource file.

Why? Because there's a choice here that's about balancing each solution's cost/issues/advantages.

When using an external file... Well, I guess the other answers explain the benefits well enough. But what about the costs? You have to define a valid formalism, build a interpreter, agree on a file format, and worse... build another application -an editor-. Which is a 0.00% issue if you're a member of a 50 coder team building a large project. But if you're alone: you're stalled.

Again, I don't under-estimate the huge flexibility benefits of an external resource: data-driven programming seems to me the way to go for video-games. But let's not forget the cost.

On the other hand, having the text inside the code allow for quick prototyping, so it should be preferred in a first time. Then my advice would be, as the project mature, to analyse the kind of data required to modelize the dialogs (mood/history-state/...). Then at some point you decide of some classes/rules/file format and go for the real thing, allowing other people to edit/decoupling the code from the content and so forth. OR for a game with simple dialogs (Mario...) you just consider the cost too high, and you keep the few strings/behavior hard-coded.
Your call.

(Request about localisation: it's just a hash table away, so it's an independent and easily solvable issue.)

I think it is too easy to be the 'wither-than-white' guy and recommend warmly using an external text resource file.

Why? Because there's a choice here that's about balancing each solution's cost/issues/advantages.

When using an external file... Well, I guess the other answers explain the benefits well enough. But what about the costs? You have to define a valid formalism, build a interpreter, agree on a file format, and worse... build another application -an editor-. Which is a 0.00% issue if you're a member of a 50 coder team building a large project. But if you're alone: you're stalled.

Again, I don't under-estimate the huge flexibility benefits of an external resource: data-driven programming seems to me the way to go for video-games. But let's not forget the cost.

On the other hand, having the text inside the code allow for quick prototyping, so it should be preferred in a first time. Then my advice would be, as the project mature, to analyse the kind of data required to modelize the dialogs (mood/history-state/...). Then at some point you decide of some classes/rules/file format and go for the real thing, allowing other people to edit/decoupling the code from the content and so forth. OR for a game with simple dialogs (Mario...) you just consider the cost too high, and you keep the few strings/behavior hard-coded.
Your call.

(Remark about localisation: it's just a hash table away, so it's an independent and easily solvable issue.)

I think too easy to be the 'wither-than-white' guy, and recommend warmly using external text resource file.

Why  ? Because there's a choice here that's about balancing each solution's cost/issues/advantages.

When using an external file... well i guess the other answers explain well enough the benefits. But what about the costs  ? You have to define a valid formalism, build a interpreter, agree on a file format, and worse... build another application -an editor-. Wich is a 0.00% issue if you're member of a 50 coder team building a large project. But if you're alone  : you're stalled.
Again i don't under-estimate the huge flexibility benefits of an external resource  : data-driven programming seems to me the way to go for video-games. But let's not forget the cost.

On the other hand, having the text inside the code allow for quick prototyping, so it should be preferred in a first time. Then my advice would be, as the project mature, to analyse the kind of data required to modelize the dialogs (mood/history-state/...). Then at some point you decide of some classes/rules/file format and go for the real thing, allowing other people to edit/decoupling the code from the content and so forth. OR for a game with simple dialogs (Mario...) you just consider the cost too high, and you keep the few strings/behavior hard-coded.
 Your call.

(Rq about localisation  : it's just a hash table away, so it's an independent an easily solvable issue)

I think it is too easy to be the 'wither-than-white' guy and recommend warmly using an external text resource file.

Why? Because there's a choice here that's about balancing each solution's cost/issues/advantages.

When using an external file... Well, I guess the other answers explain the benefits well enough. But what about the costs? You have to define a valid formalism, build a interpreter, agree on a file format, and worse... build another application -an editor-. Which is a 0.00% issue if you're a member of a 50 coder team building a large project. But if you're alone: you're stalled.

Again, I don't under-estimate the huge flexibility benefits of an external resource: data-driven programming seems to me the way to go for video-games. But let's not forget the cost.

On the other hand, having the text inside the code allow for quick prototyping, so it should be preferred in a first time. Then my advice would be, as the project mature, to analyse the kind of data required to modelize the dialogs (mood/history-state/...). Then at some point you decide of some classes/rules/file format and go for the real thing, allowing other people to edit/decoupling the code from the content and so forth. OR for a game with simple dialogs (Mario...) you just consider the cost too high, and you keep the few strings/behavior hard-coded. 
Your call.

(Request about localisation: it's just a hash table away, so it's an independent and easily solvable issue.)