When describing a scenario, it is now possible to use characters to draw the location of a particular robot. This can also be used to easily make many copies of the same robot.
- Robots in the `robots` list with a concrete `loc` will actually be created in the world. Those without a `loc` are only templates.
- A `palette` entry can now optionally have a 3-tuple, indicating terrain, entity, and robot name.
- Add a Game of Life example making use of the new functionality.
- Did a lot of code refactoring along the way.
Closes#557 .
- add iron ore, iron mine and iron vein (closes#93)
- split gear into iron/wooden gear
- add metal drill
- add faster recipes with the metal drill
- add compass (closes#341)
- handle multiple entities providing the same capability
- try to find if the robot has at least one entity providing the capability
- when no entity could provide the capability rejects it too
- list required devices in the `Incapable` error (closes#342)
Generalize challenges + various modes to all be "scenarios" which are described by `.yaml` files in `data/scenarios`.
- Both challenges and classic/creative modes are now subsumed under the more general notion of "scenarios".
- A scenario describes how to set up the world etc. when starting a game; all scenarios are stored in a `.yaml` file in `data/scenarios`.
- "New game" menu item now lets the user choose a scenario.
- Some small improvements to the way seeds are handled.
See #296. This will enable #35 and #25 .
Fixes#82.
Right now it only works in classic mode. It wouldn't be too hard to
make it work with challenge mode as well, but that would require some
more careful thinking about whether every challenge is required to
have a 'base' and how we identify which robot that is, so that we run
the given file on the right robot.
See the discussion at
https://github.com/byorgey/swarm/pull/303#discussion_r817471340 .
This seems like an unqualified success: no more hacky (-1)'s, and
doing the refactoring actually uncovered a bug! Previously, we were
not actually assigning ID's to the robots that were read as part of a
challenge. This means that in a challenge with multiple robots, all
but one of them would instantly disappear since they all shared the
same ID number.
The basic idea of this change is to create a new `robot` type and use it to identify robots instead of `string` names. Internally, a `robot` value is just a (unique) `Int`.
Closes#212 .
This ended up turning into a sort of constellation of related changes.
- Add the `robot` type and change the type of various built-in functions which used to take a robot name so they now take a `robot` (`give`, `install`, `reprogram`, `view`, `upload`) and change `build` so it returns a `robot`.
- All internal data structures that store robots are now keyed by a unique (`Int`) robot ID rather than by name.
- Add a `setname` command for setting a robot's display name (which no longer needs to uniquely identify a robot).
- Import a big list of words which we can use to randomly pick names for robots, just for fun. This is why the diff says "+31,050 -265"; I did not write 31 thousand lines of code.
- Add constants `base`, `parent`, and `self` for getting a `robot` value referring to the base, one's parent, and one's self, respectively.
- Top-level binders like `r <- build {move}` now export a variable binding which can be used in later expressions entered at the REPL; additionally, unlike Haskell, a binder can now appear as the last statement in a block.
- Fix the pretty-printer for `Value` by doubling down on our current strategy of injecting `Value`s back into `Term`s and then pretty-printing the result. I am now convinced this is the Right Way (tm) to do this; it only required adding a couple additional kinds of `Term` which represent internal results of evaluation and cannot show up in the surface language (`TRef`, `TRobot`).
- Update the tutorial.
- While updating the tutorial, I noticed that #294 had introduced a bug, where the inventory display no longer updated when 0 copies of an entity are added to the inventory (as with `scan` + `upload`), so I fixed that by changing the way inventory hashes are computed.
I tried running the benchmarks both before & after this change. I was hoping that it might speed things up to be using `IntMap` and `IntSet` instead of looking things up by `Text` keys in a `Map` all the time. However, if I'm interpreting the results correctly, it seems like it didn't really make all that much difference, at least for the particular benchmarks we have.
Make explicit in the type system when evaluation of a computation should be delayed. This gives the user fine-grained control over selective laziness (for example, once we have sum types and recursive types, one could use this to define lazy infinite data structures). It also allows us to guarantee that certain commands such as `build` and `reprogram` delay evaluation of their arguments, and lets the user e.g. define their own modified versions of `build` without compromising those guarantees.
- Delay is indicated by curly braces both at the value and type levels, that is, if `t : ty` then `{t} : {ty}`.
- `force : {ty} -> ty` is now exposed in the surface language.
- Change from a CEK machine to a CESK machine. Recursive `let` and `def` delay via allocating a cell in the store. For now, there is no other way to allocate anything in the store, but see discussion at #150 for some possible future directions.
- change the types of `build` and `reprogram` to require a delayed program, e.g. `build : string -> {cmd a} -> cmd string`
- `if` and `try` also require delayed arguments.
- don't elaborate Build and Reprogram with extra Delay wrappers since one is now required by the type
- Division by zero, negative exponents, and bad comparisons now throw exceptions.
Closes#150. Closes#226.
Improve the benchmark and add more scenarios.
Improvement are:
- Run each benchmark for 10 seconds to get enough samples in more costly scenarios
- Run benchmark on a blank terrain to avoid crashing into mountain and boulders
- Take advantage of the seed in tests using randomness
New scenarios are:
- A bunch of robots doing nothing. Will be useful for measuring the impact of removing idle robots from the active robots set.
- A bunch of robots moving in circles.
- A bunch of robots moving forward. This surprisingly is slower than moving in circles.
Resolves#20 by introducing an active robots set and a waiting robots queue as discussed in the issue.
Growing trees benchmark before change:
```
benchmarking run 1000 game ticks/10 trees
time 141.1 ms (137.3 ms .. 146.4 ms)
0.997 R² (0.995 R² .. 1.000 R²)
mean 140.1 ms (138.5 ms .. 142.2 ms)
std dev 3.807 ms (2.703 ms .. 5.189 ms)
benchmarking run 1000 game ticks/20 trees
time 298.9 ms (281.7 ms .. 326.0 ms)
0.989 R² (0.972 R² .. 0.998 R²)
mean 301.7 ms (295.0 ms .. 311.0 ms)
std dev 13.93 ms (10.02 ms .. 19.92 ms)
benchmarking run 1000 game ticks/30 trees
time 470.9 ms (432.0 ms .. 513.0 ms)
0.991 R² (0.978 R² .. 1.000 R²)
mean 450.1 ms (441.9 ms .. 468.4 ms)
std dev 18.85 ms (5.941 ms .. 30.21 ms)
variance introduced by outliers: 11% (moderately inflated)
```
After change:
```
benchmarking run 1000 game ticks/10 trees
time 4.666 ms (4.529 ms .. 4.955 ms)
0.963 R² (0.899 R² .. 0.999 R²)
mean 4.447 ms (4.361 ms .. 4.668 ms)
std dev 539.2 μs (185.5 μs .. 1.097 ms)
variance introduced by outliers: 80% (severely inflated)
benchmarking run 1000 game ticks/20 trees
time 6.955 ms (6.826 ms .. 7.122 ms)
0.996 R² (0.993 R² .. 0.999 R²)
mean 6.855 ms (6.795 ms .. 6.936 ms)
std dev 262.8 μs (197.0 μs .. 340.6 μs)
variance introduced by outliers: 25% (moderately inflated)
benchmarking run 1000 game ticks/30 trees
time 10.53 ms (9.738 ms .. 11.47 ms)
0.954 R² (0.914 R² .. 0.988 R²)
mean 9.504 ms (9.226 ms .. 9.974 ms)
std dev 1.211 ms (809.9 μs .. 1.948 ms)
variance introduced by outliers: 76% (severely inflated)
```
- adds CLI option `--seed` and propagates it to `testWorld2` (Closes#14)
- moves the base in the tree shade (Closes#90)
- makes the `random` command depend on initial seed (Closes#13)
