Javascript is a single threaded language but when developing point-and-click adventure games, it's often advantageous to have 2 "threads" running, the rendering/logic thread and the game scripting thread.

The rendering/logic thread runs every game-loop to render the scene and move the characters around and so forth.

The "scripting" thread is a simple interface for the game maker to script interactions. In Adventure Game Studio, the scripting might look something like this:

function onRoomLoad() {
    myCharacter.Walk(200,300); // Walk to a point on the screen
    myCharacter.Say("I'm selling these fine leather jackets"); // Say a line of dialogue
    myCharacter.Walk(100,300); // Walk back to where they came from

These functions should all "block" the scripting thread until they have completed and then continue with the next one while not blocking the rendering thread.

In Javascript I can see three possibilities for how to handle this:

Generator functions everywhere.

function* onRoomLoad() {
    yield* myCharacter.walk(200,300);
    yield* myCharacter.say("I'm selling these fine leather jackets");
    yield* myCharacter.Walk(100,300);

(Note that all these yields would eventually boil down to a yield* wait(t) call which would wait t game loops before finishing.)


function onRoomLoad() {
        then(x => x.say("I'm selling these fine leather jackets")).
        then(x => x.walk(100,300));

Defer the rendering inside blocking calls

I'm not sure if this one is actually possible since it would constantly block the browser but basically it would work the same as a normal game loops with an infinite while loop which just drew to the canvas element whenever it could. I think the browser would probably think the site had crashed if it never yielded and fully held control.


None of these solutions seems particularly satisfactory to me. Are there any options that I have missed that would allow arbitrary, blocking scripting behaviour in a browser?

  • I really want to answer this! But, I think it's a much better fit for gamedev.se.
    – svidgen
    Apr 13, 2017 at 14:36
  • The promises look very sound to me for that usecase. After all, in JS philosophy, blocking calls are evil. Promises would be the Most idiomatic solution.
    – marstato
    May 14, 2017 at 8:36
  • So my main question for you is why are you using JavaScript for a game? This is a great question and I'd love to answer it, though I'm more curious why you wouldn't just use another language that lets you use threading off the bat.
    – Rhys Johns
    Jun 13, 2017 at 5:26

2 Answers 2


Web Workers allow for background threads that do not block the main thread and communicate via messages/events.



I would implement polymorphic coding techniques to achieve what you're looking to do. This way you could have two basic classes and inherit those classes into sub classes which alter the frames progressively throughout the program. Then if you implement an a-sync function to step through each sub class after the previous function has completed dependent on other variables specified by the user you will have a program that essentially responds to the users action and then process that information accordingly. I hope I understood your question correctly.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.