We should follow the best practices behind: https://github.com/trainyard/choo-cli

I want to deal with this right now because when starting to implement #33 I realized that a lot of the "RobotRuntime" code is running outside of choo. This means that when ever we want to change the behaviour of how units are crated we have to change the runtime. These two things should not be coupled. Instead we should follow the choo pattern more strictly and push non-choo code towards the edges of our application.

Robots are able to collect/mine resources from a resource-point and increase the players vault

5 Points

• Implement resource "counter"
• Add resource "mine"

Currently the rotate command cost 1 turn. This makes this command far less attractive then using move(up/down/left/right). There are still use cases for rotate though. For example walking in a square requires far less code:

repeat 4:
  move('FORWARD')
  move('FORWARD')  
  move('FORWARD')
  rotate('LEFT')

My suggestion is that the rotate command should be free and cost no turn.

Tasks

• add terminatesTurn flag to api definition of robot
• make rotate free

• choo
• sheetify

Examples

• Pers choo project
• Choo examples

2 story points

• store health of entity:
  stores max health and current health
• add action 'heal'
  cap health regeneration at max health
• add action 'damage'
  trigger destroy Entity if health <= 0
• render health bar

• simple-peer
• webrtc-swarm
  • Maybe see: Peermesh
• signalhub

• replace current interpreter with esper.js
• use external step event to step through program
  • a step event is triggered every n millisecond
  • the robot program is executed until it triggers a game action or the maximum number of cycles is reached
• add more controls, pause, stop, change speed

• Clicking Restart Button will create a new Challenge for the side
• Clicking the right "tile" will send the same Challenge to the other frame together with the time taken and mistakes done (time taken and mistakes done are logged to console) - Currently creates a new Challenge on the side that solved.
• GameJS is responsible for the logic and only the logic
• GameUIjs is responsible to make the gamelogic visible to the user -> transfer to html

4 story points

discovere component

• add simple data component

discoverable component

• store which teams have discovered entity
• add 'markAsDiscoveredByTeamId' action
  gets team passed in which is saved in discovered
• implement update handler which checks for discoverers

blockly

• add discovered event block

10 story points

• Rename Robot-IDE to Robotopia
• Integrate Networking Files repo into Robotopia Structure
• Change Architecture of Client and Server Side to be one page each, with the other pages being represented by 'elements' as seen in the Robotopia Repo
• Refractor Modules to make them smaller
• Integrate IDE, Runtime, GameView into the new Presenter / Client Pages

4 story points

Global resource actions:

• add resources object to global game state. We need to store how much resources each team has
• add 'addResources' action
  add resources to team storage
• add 'removeResources' action
  remove resources from team storage
• add helper function to check if resources are available

Collector component:

• store whether or not the robot is currently carrying resources
• add 'takeResource' action:
  if bot is near resource => set carrying resource flag to true
• add 'depositResource' action:
  if carrying resource flag is true and bot near base => add resource for team, clear carrying resource flag

• create canvas component
• render robot
• render grid
• render base

As first quick draft to get into all this.

Very much like the marker event, there is a separate event which is triggered if an enemy robot gets in the specified range of the robot

2 points

• Add enemy event block
• Add global check to detect enemy units which are near each other
• Execute event blocks when enemy is near

The robots can now place walls on empty places -> wall will block the way

2 points

• Add build wall block
• Add wall entity
• make wall destroyable
  -> #35 has to be implemented first

• create summary document in research repo

Questions to answer:

• How to establish the initial connection?
• How to sync data via p2p? (look at Permusic, Secure-WebRTC-Swarm)

• blockly editor
• basic code execution controls
• game runtime

Blockly uses the module system of the google closure compiler. There are existing bundles but they are either outdated or don't work. Including the javscript files directly with script tags is not an option (at least not with budo). There exists a loader for webpack which has support for closure modules: https://www.npmjs.com/package/webpack-closure-compiler. My proposed solution is to create our own blockly repo which bundles everything toghether with webpack.

• add block which returns the base position of the current bot

• add collect resource code block
• add collectable collector component
• add resource entity
• destroy resource entity when block is executed and bot is near resource

Description

I want to be able to see the code blocks of the selected robot and which block is currently executed

7 Points

Todo

• Clickable robots
• Highlight currently executed block
• Show code blocks of currently selected robot

3 story points

tower entity

• add tower entity which is rendered as simple sprite

towerSpawner entity

Add spawn action

• spawn new tower entity
• check that there are enough resources (requires #41)
• enforce tower is at least 4 blocks away from base (use spiral iteration implemented here)

distance to base block

• add distance to base variable block

• add create bot function to spawn new bots
• on step event iterate over each bot and execute it's programm one step further
• [ ] shuffle execution order to preserve fairness
  (has no effect right now, we'll deal with this later when bots can actually block each other)
• destroy bot if it finished its script
• [ ] stop simulation state if all bots terminated
  (lead to buggy behaviour if no bots are there, simulation is paused immediately again)

#12 has to be implemented first

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

• trigger events in runtime
• 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

4.0.0 The routing patch

This patch changes the way we handle routes. It introduces query string
support (!), and changes the router to use a lisp-like syntax. It also inverts
the argument order of effects and reducers to be more intuitive. We also
managed to sneak in some performance upgrades ✨ - We hope you enjoy
it!

changes

• ❗ slim down server side rendering API |
  issue |
  pull-request
• ❗ update router API to be lisp-like
• ❗ swap state and data argument order |
  issue
• ❗ remove choo/http. Use xhr
  instead | pull-request
• update router to use memoization |
  issue |
  pull-request
• support inline anchor links |
  issue
• allow bypassing of link clicks in sheet-router |
  issue |
  pull-request
• update router API to handle hashes by default
• update router to provide out of the box support for Electron
• update location state to expose search parameters (query strings) |
  issue

Todo

• swap state and data argument order

• add game engine from IDE to presenter
• run all commited bot scripts simultaneous

#11 and #13 need to be implemented first

Implement the logic needed to create tutorial levels

7 Points

• Test for winning condition
• Reset level
• Load next level (tutorial)
  • Load new tutorial game
  • Load new workspace
  • Load new toolbox
• Story -> display short story at the start of every tutorial level
  -> e.g. A bit of Story

• players can connect to the presenter by entering their name
• client connects to presenter with name and generated connection token

• create bot with custom id
• reload bot code

4 story points

Currently we will limit the attack to static entities (towers)

attacker component

• require movable component
• add attack action
  attack if there is a entity with health in front of current entity

attack block

• add attack action to robot-api
• add attack block (move towards position if necessary then attack)
• add destroy block (calls attack repeatedly until entity is destroyed or bot is destroyed)

Game Engine

• reducer
• effects
• dynamic entitiy creation

Gameplay

• move commands
• [ ] set marker
• [ ] goto point

Robots meet at the marker and act depending on what kind of marker was placed

2 Points

• Robot has a "blob" over his head which displays the color of the current mode

Implement the single tutorial levels and make them pretty

5 Points
Check the research repo for detailed a more detailed description
#31 - Tutorial mechanics - has to be implemented first

• Simple movement -> e.g. move to given position to finish tutorial
• Loops -> e.g. similar to simple movement but greater distance
• [ ] Actions
  • [ ] Collect resources
  • [ ] Build Wall
  • [ ] Build Tower
  • [ ] Find and attack enemy
• [ ] Combine learned things -> e.g. go to resource, collect resource, return with resource
• [ ] Survive incoming enemies for x minutes (collect resource and build towers)
• [ ] Events -> Marker and enemy
• [ ] "Real" fight against a computer enemy

Striked ones will be implemented at a later point

• NPM init
• budo
• standard
• tape
• atom
  • minimap
  • linter-js-standard

- [ ] add main routine start block might be added later

• add marker creation event routine start block
• trigger interpreter event on marker creation
• add move to position
• add move to marker command

#14 has to be implemented first

Robots meet at the marker and act depending on what kind of marker was placed

4 Points

Task Component

• Saves the number of workers assigned, and workers required
• In update event: get unassigned worker and assign them task until number of workers required is satisfied
• Render status of task: how many workers are assigned
• Delete task entity if all assigned workers have completed

Worker Component

• Worker can be assigned to a marker
• Runtime triggers complete event if event block is finished

https://github.com/mafintosh/hyperlog

Automatically spawn new robots from each teams base

2 Points

• Add update hook for components, which is called on beginStep
• Spawn new robots in an interval
• Add Team component as token to associate entities like markers/robots with their team
• Add namespace to runtime, so events will be only propagated inside one namespace

• add place marker code block
• add marker entity
• spawn new marker entity when block is executed

Rotation commands are currently from the perspective of the player. Which makes it hard to reason about the code is rotated to the left or the right. The directions should be switched around

• switch the directions around

• save current username/connection token locally
• reconnect if browser is reopened
• save code locally

3 story points

shooter Component

shooter attacks one entity with the least health per round which is in its range

Implement update action

• get entity in range with least 'health' (only enemies)
• trigger damage on target
• store selected target, reset if not target is in range (this will be later required for the renderer)
• [ ] render laser from tower to target

• clients can send arbitrary JSON to presenter (this will later contain the actual code)
• presenter stores history of different versions of commited data

• create research document in todo

Robots meet at the marker and act depending on what kind of marker was placed

11 Points

Load code

Actual implemented

• add 'on' method to register event handlers
• add switch mode to switch between differnent mode handlers

2nd Idea

• [ ] add events with urgent flag (for things like discover enemy)

Initial idea

• [ ] Handler are initialised once at loading
  bad idea forcing all blocks to be wrapped, makes pure javascript api really ugly
• [ ] Executing events must be prevented
  obsolete when event handler are always registered at start of programm (see #51 )

Event handling

• agent switches to handler mode if event is triggered
• agent jumps back into main mode if mode handler is finished
• trigger events if mode has been completed

The robots are able to attack other robots or walls

7 Points

• Change 'moveTo' to allow to move towards blocked fields
• [ ] check if field is empty before walking
• Check if enemy is near bot
• Add attack action
• Add destroyable component
• Add hit points
• Add attack block
• Prevent spawning robots on the same spot

• remove the <script> tags from index.js and move them into an index.html

1 story point

At the beginning of a game the bots need to explore the map, searching for resources. Player need randomness in order to build this behaviour into their robots

• add random block which returns integer in defined range
• add default control blockly blocks to toolbox (e.g. if, comparators)

Description

Robots should be animated. Instead of abruptly jumping from one field to another they should smoothly move between fields. This helps understand what the bots are actually doing, especially if there are multiple bots on the board.

Todo

• pass current and passed state to renderer
• use onAnimationFrame to rerender canvas on every frame
• pass time elapsed since last tick as value between 0 and 1
  • 0 means no time has passed since last tick, 0.5 means half the time has passed until next tick ...
• interpolate position of entities, to enable smooth move animation
• add commit action so prev state is only updated on every clock tick instead of every action
• [ ] add sprite animation