Add subroutines for bot programms

[paulsonnentag]

How esper.js works

I just looked at the feautures which seemed usefull for my problem. Here is my basic understanding of how esper.js works:

• the main component is the engine this bundles all the components of the interpreter and most of the time we interact with this object
• every engine has a realm which represents the javascript state of the programm (global variables and functions)
• you can fork an engine. This means you can create another engine with separate code which shares the same global state

Current implementation

An simple robot program could look like this:

robot.onMarker = function (marker) {
  // do something with marker
}

while (true) {
  robot.move('FORWARD')
  robot.move('FORWARD')
  robot.move('FORWARD')
  robot.move('FORWARD')
  robot.rotate('LEFT')
}

If this program is executed an esper engine is created which runs the code. When an event is triggered a fork of the engine is created which has just the call to the event handler as a code. The robot runtime switches then to the forked engine and executes it until it terminates. Then the robot runtime returns to the main engine.

const subEngine = engine.fork()

subEngine.load('robot.onMarker({x: 0, y: 6})')

...

I've changed the api a little bit so its more friendly if you write it by hand.

TODO

• [x] trigger events in runtime
• [x] trigger events from game

Original idea

Main routine and event routine are stored separately with each of them running in their own esper.js interpreter. If an event is triggered the robot runtime switches to esper runtime of the event and executes it until it terminates. Then it switches back to the main runtime

Disadvantages:

• no shared global state

• no nice way to support writing JavaScript directly instead of using blockly

• [ ] extend create bot function. Bot program consists of one main routine and multiple optional event routines - [ ] store currently executed routine and triggered events in interpreter for each bot.

• [ ] when executing next step of bot program, check before if event has happened. If an event has been triggered for the bot the interpreter should switch to the event routine.

• [ ] if the end of a subroutine is reached continue executing the main routine

Open for discussion:

• What should happen if multiple events have been triggered?
  • Current Implementation: Second Event is ignored
• What should happen if an event is triggered while the bot program is inside an event routine?
  • Current Implementation: Ignore Event

[paulsonnentag]

In my opinion we should discard any events if the bot program has already received an event or is currently executing an event routine

[timgrossmann]

In my opinion we should discard any events if the bot program has already received an event or is currently executing an event routine

I think this would be the best approach, too...
Another idea is, that events get a priority which determines how important they are.
I'm thinking about a case where a marker for "resources" is dropped and after that one of "help me fight" is dropped.

[perguth]

I could imagine such a case (ignoring technical probs of the issue for now):

// code: go find ressources!
game.on('ressourceFound', e => {
  // code: mine and bring home!
})
game.on('enemyDiscovered', e => {
  // since we want to run away, we ignore `ressourceFound` events:
  game.removeListener('ressourceFound') 
  // since we're running away, we're now looking for allies:
  game.on('allyDiscovered', e => {
    // code: group!
  })
  // code: run!
})

(Along the lines of Node EventEmitters)

[H3rby7]

I was also thinking about this issue. My Idea would be to have the robot/unit "know" its current subroutine. When a new event occurs the programmer has access to that information and can decide himself in the event handling how he wants to continue. In your example @timgrossmann

Unit State

• current order: "get ressources"

  Event (enemy detected)

• has information on the unit and the Unit state
• when handling this event can check for the current order of the unit

Inside Event: event.ENEMY_DETECTED

if (unit.getCurrentOrder() === action.GATHER_RESSOURCES) {
  unit.issueOrder(action.FLEE)
}

This way we pass the problem and soultion and power to the programmer. He could also not check for the event and always take the newest event, or check if an order is present and just continue. As he pleases.

[H3rby7]

Addressing the multiple Actions event I would suggest to have a list of events that happened in the entity as suggested here in the Object>Unit section. There is an example there.
Again this empowers the coder to chose which event to handle.