Using Lua coroutines to create an RPG dialogue system

You give up: 1. Extra cognitive load every time you need to await. 2. You've got to be more careful when designing some generic higher-order functions (you need to decide which color their function arguments should be).

In return you get: 1. Explicit concurrency. No function that you call unexpectedly suspends behind your back. In some cases this explicitness could be actually important (e.g. when using per-thread/process shared memory). 2. Futures/promises/tasks are first-class values. You could pass them along, save them for later, await on all or any of them and so forth. 3. Theoretically speaking, promises can be more memory efficient than coroutines since you don't need to allocate a full stack for each of them - just the state you need.

"What Color Is Your Function" is misleading: there is no strictly superior solution for this tradeoff.

Futures/promises encode concurrency as a monad and like every monad they are viral and once you start propagating them around, they can be a pain. But the alternative for not encoding some concern of your program as a monad is to let it pass through an implicit side-channel (I/O, error-handling, global state, built-in scheduler) that is harder to control and can't be treated as first-class object in the language.

Go itself chose to go the explicit with error-handling. It doesn't even uses Monads, so it gets the worst of both worlds in my opinion, but the designers' main concern with exceptions which they managed to avert is still valid: with (unchecked) exceptions you never know which function you call is going to raise an error on you somewhere down the line.

So yes, with Go you'll never have with unexpected throws, but you'll have to deal with unexpected goroutine suspension. In Go all of your functions will be happily colorless with regards to concurrency but will be colored with regards to error-handling.

Again, both choices here are valid, but they are not so brain-dead simple or universal as this article is trying to put them.

JavaScript promises do (Promise.all).

Say you have an AI that's made 3 decisions and you're in the MIDDLE of a coroutine where it's waiting for the next criteria that will shift it to its next state. So the AI code looks like:

   local player = lookForAPlayer()
   if navigateToPlayerLocation() then
      local quest = givePlayerQuest();
      while (!quest:done()) do
        waitWithStandardReply("Waiting for you to finish the quest!");
      end
      if (quest:resolved()) then
        giveQuestReward();
        while (true) do
           waitWithStandardReply("Thanks for finishing that quest for me!";
        end
      else -- quest abandonded        
        while (true) do
           waitWithStandardReply("Thanks for nothing!");
        end
      end
   end

Yes, it's awesome to be able to code AI logic that way. But how do you save the coroutine state? The actual execution state of the coroutine itself, including what line it will resume next, the values of any bound variables, the values of any local variables, are all part of the state of the AI in that case.

In C, you've got functions that may be relocated somewhere else in RAM and potentially stacks to save (if you're using a "real" coroutine library), so just doing a memcpy won't work. What would you memcpy to save the line that the script is paused on? In Lua, it can be done with Pluto, but then you can't use LuaJIT. I see libdill has the ability to use a user-supplied stack, but it doesn't appear to have a "resume" call that takes such a stack memory block, so the best that would happen is that the coroutine would start over from the beginning. Meaning that if you saved the above coroutine in the middle of a quest, the character involved would offer you a new quest when you saw them instead of accepting the result of a successfully allocated quest.

If your object states are all being handled in traditional objects, then you're not using the coroutines in the way described by the article.

Most of the games and engines I've ever worked on that have dialog systems expressly avoid encoding things into the program state as much as reasonably possible. This is not only for restoring state, but also making for a saner experience editing and changing things during development. Very rarely does the format you encode things like dialog stay the same during a dev cycle unless you're using a canned engine and don't make any serious changes.

Using Lua program state itself seems like a way to drive yourself mad by the end of the dev cycle, and make it incredible unfriendly to work with writers and other content creators. People who work with asset pipelines often do a lot of cruel and unusual data conversions and munging to bridge how different people and systems need to work, but eventually things in the actual game engine are best kept as simple data that can be read in and reproduced at any time. Moreover, as a developer, I should be able to load up any state of my game at any point in the game just by providing the necessary input data as possible, and like a pure function, it should produce the same game state every time if possible. Let's also not forget other things like internationalization and localization.

As far as interfacing with Lua, I've mostly done it in the last few decades in a simple way where we handed entity component-style data that is just pure data, i.e. no function pointers and crazy stuff, and either let Lua do the rest with that state, or send pure data back to the C++ when needed. As for the data format itself, I've seen everything from XML to custom binary formats to CSV and Excel used for dialog. I think I'd sooner murder someone if game dialog lived in code, even in a Lua script.

For a similar problem of making the AI code for a bullet hell shmup, I thought it was very important to be able to edit the AI code easily to try out a lot of stuff. I've had decent experiences using BulletML and Lua for this, but both of them provide no path forward if I want to update the game and load an old save. Like, because I was not asked to explicitly name every single state in my "AI program", I cannot create a mapping between the possible old states and the possible new states to use when running the updated software against an old save. Then again, the fact that I was not asked to explicitly name every single state in my program feels like a pretty central component of the short iteration time I was after to begin with.

For shmup AI this maybe ends up being acceptable because the game doesn't need to run new behaviors against old save files. But if I did need that, maybe I should be using two systems, one for experimentation and another one for making something upgradable?

The term component here would be incorrect, rather "system" would be a better term.

There are many variations and approaches to what I am talking about so I'll stick to one very common approach used by a lot of studios and engines today. A typical more cache-friendly update cycle goes like this, calling "update" as a function of time/state on each system:

System A -> System B -> System C -> System D -> etc. (loop and repeat each frame)

This cycle sometimes skips certain systems for either performance or sim reasons. Each system tends to have inner loops and the overall system loop is often broken up a bit into sub-loops or separate loops, ex: render vs. physics for purposes of separate sim-time looping. The idea here is you do a single operation over and over again on the same type of data, avoiding lots of pointer chasing, v-tables, and so on along the way. The code branches very predictably and it becomes easier to avoid loading data into the cache that will blow it up or not fit into a page.

What makes this friendly to a data-driven approach is if you're working mostly with systems that operate on pure data, your update each frame from a purist point of view approaches a functional reduction. In practice, there are certain things that don't fit perfectly into this paradigm, but the idea most engines take is this approach + cut corners when necessary.

I am contending that your point data == code is wholly false. Again, this is well-known in computer science to the point where your argument only stands if you're looking at code from a very low-level point of view. Again, all current game development trends refute what you are saying - almost every year there's one or more GDC speaker sessions about this topic, see the GDC vaults, see Unreal Engine, Unity, CryEngine, etc.

Yes, to a degree code can be data, but it becomes exponentially difficult to manage and process vs. simple representations that tend to be language, runtime, and network agnostic - i.e. data structures. Lua tables and other things inside Lua are not the same (at least not until serialized to a more language agnostic format), especially in the face that in most real game dev situations, you're passing data between tools and languages, and in several different flavors of run and design time. I've done quite a bit of code as data approaches to know that even when it can be done, it has many drawbacks - see object databases, Smalltalk continuation serialization, code gen tools, etc.

Functional languages and several more fringe languages tend to be closer to code == data, the most wildly known and regarding being Lisp-like languages. Typically these languages have a minimal amount of abstractions and power things like first-class macro systems. Even in the face of macros, there are many drawbacks to dealing with code this way in general, and even more in a game. For instance, restoring state exactly as it was and is, and using that state in the face of updates to the game itself are paramount to the point where few games can survive without it otherwise. Data makes this easy.

What you are asserting as more power is exactly the opposite and I'm not sure how I can make this any clearer. Your code can freely operate on data any way it wishes, not the other way around. Code operating on code is generally a bad idea which is why clever meta-programming techniques and code generation are things you would rarely see in any game engine unless it was a hack or a bad implementation.

You are losing little by making things a data representation and gaining much in terms of what I already listed. All the benefits of data are far more valuable for game development and I am not sure what cannot be achieved by forward-loading or pipelining data into an asset pipeline and operating on that data doesn't achieve that this does. Beyond performance, the other benefits like editors, network transparency, easy loading and saving of state, and so on make it easier and faster to develop even small games.

What you are proposing is a solution looking for a problem. I'm not denying it's a fun thing to do, especially if we're talking about a regular "app" rather than a game. Personally, I like coroutines, fibers, CSP, continuations, multiple dispatch, and other fun CS tools but not for game programming in most of the time, and certainly not at the level of an important game system. I am asserting that in the game dev world, treating code as data is a really bad idea, which several other people have also pointed out here. Your solution adds very little, while adding unnecessary complexity to check a "cool" computer science box.