1. Co-routines

Co-routines (co-operative multi-tasking?) mean you can do stuff like

    while (isWalking()) {
      advance();
      yield();
    }
    

2. Iteration time

You can usually swap script code live. This project aims to fix that for C++ though I'm a little skeptical it can stay robust

https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledC...

Boost has a c++ implementation but it looks quite different:

http://www.boost.org/doc/libs/1_55_0/libs/coroutine/doc/html...

[1] http://supercollider.github.io

edit: pythons new asyncio stuff looks very interesting:

https://docs.python.org/3.4/library/asyncio-task.html

I really need to get around to writing a blog post to explain this in detail since this misapprehension is endemic. Python and JavaScript do not have coroutines, they have generators. Lua has actual coroutines.

The latter is dramatically more expressive than what you can do with what Python, JavaScript, and C# offer. This mistake drives me crazy because it means people don't know what they're missing.

Here's a quick example. Let's say we've got a little Python class for binary trees:

    class Tree:
      def __init__(self, left, data, right):
        self.left = left
        self.data = data
        self.right = right

    def walk(self, callback):
      """Traverse the tree in order, invoking `callback` on each node."""
      if self.left:
        self.left.walk(callback)

      callback(self.data)

      if self.right:
        self.right.walk(callback)

    tree = Tree(Tree(Tree(None, 1, None), 2, Tree(None, 3, None)), 4, None)

    tree.walk(print)

Later, we decide we want to iterate over the items in a tree. Easy-peasy, Python has generators! We can just make a function that takes a Tree and returns a generator. We already have a method to walk the nodes, so we just need to call that and then yield the items, like so:

    def iterateTree(tree):
      def callback(data):
        yield data

      tree.walk(callback)

    for x in iterateTree(tree):
      print(x)

Actually, no. This doesn't work at all. You can't yield from the callback passed to walk. That's because walk() itself doesn't know that the callback is a generator.

This is the problem with generators: they divide all functions into two categories: regular functions and generators. You run a regular function by calling it. You run a generator by iterating over it. The caller must use it in the correct way.

At its simplest level it means you have to be careful when refactoring. If you have a generator function that gets too big and you want to split it up, you have to remember that the functions you split out are also special generator functions if they contain a yield. You have to remember to flatten it when you "invoke it".

It's more than just annoying though: it means it's impossible to write code that works generically with both kinds of functions. In other words, all of your higher-order functions like map, filter, etc. now only work with some of your functions. (Or, I suppose, you could explicitly implement them to support both but that's more work and I don't think most languages do.)

In languages like Lua, the above code just works. You can yield from anywhere in the callstack and the entire stack is suspended. It's fantastic.

(If I can be forgiven a bit of self-promotion, I'll note that my programming language Wren[1] can not only express full coroutines like Lua, but also supports symmetric coroutines which can express some things Lua cannot. They are roughly like the equivalent of tail call elimination for coroutines.)

[1]: https://github.com/munificent/wren

I realized this limitation one day while trying to do it in python. You cannot just yield another stream.

SuperCollider has proper co-routines: http://danielnouri.org/docs/SuperColliderHelp/Core/Kernel/Ro...

and the pattern library is built entirely around embedding in streams and yielding others streams. it uses this for very interesting numeric music patterns.

Python 3.4 also now has co-routines: https://docs.python.org/3.4/library/asyncio-task.html

esp this is interesting:

result = yield from future – suspends the coroutine until the future is done, then returns the future’s result, or raises an exception, which will be propagated. (If the future is cancelled, it will raise a CancelledError exception.) Note that tasks are futures, and everything said about futures also applies to tasks.

result = yield from coroutine – wait for another coroutine to produce a result (or raise an exception, which will be propagated). The coroutine expression must be a call to another coroutine.

Javascript does/will have simple generators

  CurrentCoroutine = None


  def run(main, arg):
    global CurrentCoroutine
    CurrentCoroutine = main
    while CurrentCoroutine is not None
      CurrentCoroutine, arg = CurrentCoroutine.send(arg)


  def corodecorator(coro):
    @functools.wraps(coro):
    def init():
      c = coro()
      c.next()
      return c
    return init

  @corodecorator
  def coro1():
    # yield nothing on first call to receive args
    arg = yield None
    friend = arg[0]
    while True:
      print('coro1')
      arg = yield friend, (CurrentCoroutine,)
      friend = arg[0]


  @corodecorator
  def coro2():
    arg = yield None
    friend = arg[0]
    while True:
      print('coro2')
      arg = yield friend, (CurrentCoroutine,)
      friend = arg[0]


  run(coro1(), (coro2(),))

Think of it like this. Let's say you have a chunk of code that you want to refactor out into a separate method. The usual way to do that is to pull it out into a separate method and then call it from the place where the code used to be inline.

In languages with coroutines, you can just do that, regardless of what's in that chunk of code. In Python, you have to think, "Oh, does this chunk of code contain a yield?" If so, you need to do a "yield from" the function you pulled out instead of a regular call.

It forces you to constantly be cognizant of and design around the split between normal code and generators.

Every place that I'm tempted to write an event-driven finite state machine, or something similar, I spawn a thread instead. I get to write synchronous code, which feels much more natural to me.

For instance my actor, running in a thread, calls a function like advance(). That drops data into an object, and wakes up the main thread, and blocks.

The next time the main thread wants to give processing time to the actor, it describes the world into the same shared object, waked up the actor's thread, and blocks.

Doing a switch like this dozens or even hundreds of times per second seems to work pretty well, especially if the main thread only gives execution to the actor thread when it needs to - inputs have changed, etc.

For my use cases, it radically simplifies my code, and I have a small number of different inputs to handle, so it has been scaling well.

Remember not everybody has the luxury of working on a system where you can spawn 10,000 threads without breaking a sweat.

However this territory of literally hundreds of thousands of programmed agents participating in a game does not seem to be very populated. Perhaps part of the reason is that very few languages had efficient (this eliminates stack copying), scalable and portable support of coroutines. This is starting to change, but not as fast as I would like.

I think C is to be blamed for the long under appreciated status of coroutines. It is one abstraction that C left out, although the VM C had as its execution model (the PDP) had excellent support for coroutines at the instruction level. C exported pretty much every abstraction of the underlying instruction set, but not coroutines.

EDIT: @VikingCoder Replying here as HN wouldnt allow me to respond till some time has past. Yes I have looked at asio although just scratched the surface. It looks very interesting, as far as I know they are not threads though (which is a good thing), they use macro and template metaprogramming trickery to turn producer-consumers into one big switch case. If you interested in coroutines and seamless interaction with C++ I can recommend http://felix-lang.org

My hunch is that the designers of C would have said "goto" and "switch" cover the use case where you have a bunch of peer chunks of code that you want to freely bounce between.

Remember, at the time function calls were considered expensive, so not support full coroutines across function call boundaries may not have been on their minds as much.

Quoting the most interesting bits from that thread, (although I urge you to read the original):

  Of the many styles of subroutine calls on the PDP-10, JSP ac,addr is the fastest,
  as it's the only one that doesn't require a memory store.

  Its ISP is something like:

        ac = PC
        PC = effective address [addr in the usual case]

  The subroutine return, of course, is:

        JRST (ac)

  Here, the efective address is the contents of the register.

  The coroutine instruction combined the two:

        JSP ac,(ac)

  This essentially exchanged the PC with ac.

Overall, it has been fun reading on all the variants of this idea.

side note: in my first job, there were a few PDP-11s in the lab that I was responsible for. We never turned them on though.

Also, the PDP 10, which you mention above, was one of the most revered machines by hackers.

I'd need one lock per actor thread and its communication object.

I say again, this works in my problem domain, and probably wouldn't work in other domains.

An ideal scripting language:

- Allows designers to build complex gameplay elements, define complex ai behaviors, create gameflow with minimal work from the software engineers.

- Handles memory allocation/destruction behind the scenes

- Does not crash the game when an error occurs

- Handles multithreading and/or events

- Does not allow designers to shoot themselves in the foot

- Has a simple and clean syntax

- Allows software engineers to expose their APIs to it easily

- Can be reloaded on the fly

If you control the feature set of the scripting language then it becomes a crucial tool for rapid development of your game - empowering the creative team to make their game and allowing the software engineers to concentrate on all the other stuff that needs their attention.

In my opinion visual scripting and component systems can be a useful addition to an engine, but I have always seen a usefulness in having a scripting language layer.

(I have shipped multiple high profile console games with more lines of script code than of game code and design teams matching the size of the programming teams)

On the projects I worked on script performance wasn't too much of an issue, the scripts were used to control state and flow, not to do any number-crunching.

If you control what is exposed to the scripting then engineering will know when design asks for access to something that should be implemented outside of scripts. Which in my experience seemed to have minimized performance issues.

One concerns when switching over to a development system such as Unity or Unreal 4 is that your gameplay 'scripts' have access to the entire engine. It seems very easy at that point for your game to turn to unintentional spaghetti.

I disagree that it has to follow that scripting -> bad code. I think of the C <--> scripting integration that I do as a Judo secret weapon. I get to easily fling "high-performance" C around in a super-dynamic way (REPL, easy-to-use high-level abstractions)... I think the problem you're describing is real (possibility to abuse/mis-use scripting power), but dismissing the notion of scripting plus C/C++ because of possibility of abuse seems like throwing out the baby with the bathwater. Better addressed with training and culture.

It sounds like having a real software engineer do code reviews and/or rewrite the poor scripts before they get committed would be a solution to this problem. Presumably giving level designers the ability to script things is good for the game play.