Closes#1641
The `data/terrain.yaml` file is now the authoritative source of terrains, though `BlankT` is still a hard-coded special case.
I have not changed the underlying integer representation of terrain in the world function, which means that the `terrainIndexByName` Map in the `TerrainMap` record is needed for translating between `Int` and `TerrainType`.
# Demo
scripts/play.sh -i data/scenarios/Testing/1775-custom-terrain.yaml
# Changes
* There used to be a function called `integrateScenarioEntities` that combined the `EntityMap` stored in the `Scenario` record with the global entity map. However, the global entity map is accessible at parse time of the `Scenario`, so we do the combining there and only ever store the combined map in the `Scenario` record.
* JSON Schema for terrain
* Removed the distinction between "World" attributes and "Terrain" attributes
* Unit tests for scenario-defined terrain and related validations
* Validate existence of referenced terrain at scenario parse time
* Validate attributes referenced by terrains at parse time
scripts/play.sh -i data/scenarios/Challenges/gallery.yaml --autoplay
## Code changes
In addition to the new scenario, this PR includes a code change to allow the order of items returned by the `tagmembers` to be specified by the scenario author.
In support of #1598 (for #1739).
Runs the `idle` benchmark for many more ticks and with many more robots to try to emphasize the effect of regressions and mitigate jitter.
Also factors out common code from the `benchmark-against-parent.sh` script.
Closes#1715
Extract scene renderer to its own binary with `swarm-scenario` as its only dependency.
This was mainly enabled by moving the `Landscape` sub-record out of the `swarm-engine` sublibrary and into `swarm-scenario`, and refactoring rendering functions to only depend on `Landscape` rather than the entire `GameState`.
# Demo
stack build --fast swarm:swarm-scene && stack exec swarm-scene -- data/scenarios/Fun/horton.yaml --png -w 180 -h 150
Measures the volume of an enclosed space.
A useful alternative to the `path` command for goal checking.
## Demo
scripts/play.sh -i data/scenarios/Testing/1747-volume-command.yaml --autoplay --speed 2
Closes#1741
Remaining blocker was to move logging to concrete robot.
Most notably, the `swarm-scenario` sublibrary has been purged of its temporal component, corroborated by the removal of the `time` package dependency.
Towards #1715 and #1043
Creates a new `swarm-scenario` sublibrary intended for scenario data that is independent of game state.
# Planned follow-ups
This PR is already pretty large, but there is still more that can be done regarding sublibrary reorganization/splitting.
* May want to pare-down a sublibrary exclusively for world-generation without all the other baggage of scenarios.
* `Swarm.Game.ScenarioInfo`, `Swarm.Game.Tick`, and `Swarm.Game.Scenario.Status` could probably be moved from `swarm-scenario` to `swarm-engine`.
Continuation of #1731.
Towards #1715 and #1043.
This refactoring step is a prerequisite for #1719 to extricate references to the `CESK` module from the base `RobotR` definition.
# In this PR:
* Extracts the `RobotContext` type to a new module
* Introduces a type family for the `RobotContext` field
# Motivation
Want to remove dependence of `TRobot` on the `RobotContext` record. However, a lens `trobotContext` had been added in #817 to fix#394.
# Test
scripts/run-tests.sh --test-arguments '--pattern "394-build-drill"'
Towards #1715 and #1043.
This refactoring step is a prerequisite for #1719 to extricate references to the `CESK` module from the base `RobotR` definition.
In this PR:
* `Swarm.Game.CESK` is imported qualified to more easily track usages
* A new `RobotMachine` type family is added to parameterize the `_machine` field.
* `CESK` is a new parameter to `addTRobot`
Closes#1644.
The `"recognize"` property in scenario `.yaml` files is changed from a boolean to a list of "up" directions.
The structure recognizer adds a rotated copy of each supported orientation to its automaton. Rotational symmetry is accounted for to avoid duplicate work in the recognizer.
Also in this PR:
* Add cardinal directions to the JSON schema
* Tetromino packing challenge scenario
## Demos
scripts/run-tests.sh --test-arguments '--pattern "1644-rotated"'
### Structures dialog
### Tetromino packing
scripts/play.sh -i data/scenarios/Challenges/pack-tetrominoes.yaml --autoplay
Closes#1443.
Also added `-Wunused-packages` to clean up dependencies.
## Demo
This still works as usual:
stack run
Output editor keywords:
stack run swarm-docs -- editors --emacs
This is a continuation of #1652.
Most of the sub-records are bundled into `Swarm.Game.State.Substate`, but we create a `Swarm.Game.State.Robot` module just for robots.
We introduce a `zoomRobots` function so that applicable functions can operate directly on `Robots` state instead of `GameState`.
## Size comparison
### Before
| File | Lines |
| --- | --- |
| `State.hs` | 1569 |
### After
| File | Lines |
| --- | --- |
| `State.hs` | 812 |
| `Substate.hs` | 497 |
| `Robot.hs` | 395 |
| `Config.hs` | 21 |
## For follow-up PR:
- [ ] Remove exports of `_viewCenter` and `_focusedRobotID` from `Swarm.Game.State.Robot`
Add another subrecord to `GameState` dedicated to robot fields. This shrinks the size of `GameState` by 8 more fields. It's getting reasonable now!
The `_viewCenter*` fields were put there too, for now, because the manually-defined `setter` of the `viewCenterRule` lens needs access to the `robotMap` field.
Structure recognition already supports overlapping bounding boxes between two structures (where one of the structure templates has vacant cells). This PR adds test coverage for this.
More importantly, this PR makes sure that structures can be recognized even with non-participating entities within their bounding box. The same integration test (`1575-bounding-box-overlap.yaml`) covers this case as well.
A "non-participating entity" is an entity that is not an ingredient to any structures participating in structure recognition. Such entities are "masked out" when the world cells (i.e. the "haystack") are queried to apply the Aho-Corasick matcher to.
## Example
Given a structure defined as `boulder`s (`@`) in a backwards "L" shape, it will be recognized despite a `mountain` (`A`) within its bounding box:
This is because `mountain` is not a member of any recognizable structures.
## Caveats
This PR strictly increases the situations in which valid structures may be recognized.
However, it is still the case that encroaching entities that **are** members of some structure template will thwart structure recognition. One consequence of this is that the order in which structures are completed can matter.
If some partially-built but incomplete structure lies within the bounding box of another candidate structure, the candidate structure will not be recognized as "complete" unless (1) the offending entities are removed first, or (2) the other structure is completed first.
Closes#1631
## Design
* Entities have a new property: a `Set` of textual tags.
* Two new commands are introduced:
* `HasTag` checks whether a single entity has a given tag
* `TagMembers` allows cycling through all members with a given tag
* `TagMembers` may be considered more powerful than `HasTag`, so has its own separate capability (`CTagmembers`).
* A map is computed at scenario initialization to facilitate `TagMembers` lookups.
* Tag names are highlighted in yellow in markdown.
## Demo
scripts/play.sh -i scenarios/Testing/1631-tags.yaml --autoplay
## Other changes
* Incidentally, changed `knownEntities` from a list to a `Set` so that `Set.member` can be used instead of `elem`.
Closes#1569
## Performance
Path cache invalidation upon world modifications (i.e. entities inserted or removed) entails iterating over all of the previously-cached paths [here](https://github.com/swarm-game/swarm/pull/1595/files#r1390158411). For efficiency's sake, we avoid iterating over "all existing robots".
Any scenario that does not use the `path` command is entirely unaffected by this change.
## Demo
Previously, this demo was virtually unplayable, since when moving between widely-spaced "clusters" of flowers, an expensive A-star search was invoked at almost every tick. Now, the vast majority of moves utilize the cache, and the demo exhibits minimal stuttering (e.g. when a single A-star search is performed when moving between distant clusters).
scripts/play.sh -i scenarios/Fun/horton.yaml --autoplay --speed 7
### Event log
An event log specific to the path cache is maintained with its own ring buffer:
scripts/play.sh -i scenarios/Testing/1569-pathfinding-cache/1569-harvest-batch.yaml --autoplay
and view http://localhost:5357/paths/log
* Highlight occurrences of structures in markdown in red
* Add a new `blueprint` entity to provide `floorplan` and `structure` commands
* new `floorplan` command to get the dimensions of a structure
* structure location is southwest instead of northwest corner
* handle structures with "holes" for statically-recognized structures and when modifying interior cells post-recognition
Each of these is its own commit for reviewability's sake.
Closes#1575
Implements structure recognition.
## Features
* Structure browsing dialog (`F6`) that becomes available if a scenario declares any recognizable structures
* Automatically recognizes statically-placed structures upon scenario initialization, accounting for occlusion by other entity/structure placement
* New `structure` command for querying location of recognized structures (primarily intended for system robots and goal checking)
* Efficiently recognizes structures immediately upon completion
* Accounts for removal of structures
* Several new integration tests
* Structured web-interface log to help understand/debug the recognition process
* Re-uses much of the functionality built previously for defining structures (#1332)
Other changes:
* Improved validation for static structure placement (ensure valid structure names instead of failing silently)
* Moved a few functions (`getNeighborLocs`, `zoomWorld`, `entityAt`, `robotWithID`, `robotWithName`) out of `Step.Util` and into `State` so that recognizer initialization, which becomes a field in `GameState`, could use them
* split `scenarioToGameState` into pure and non-pure functions
## Optimizations
Scenarios that do not make use of structure recognition are entirely unaffected, performance-wise.
Some optimizations include:
* Structure definitions must "opt-in" to participate in automatic recognition
* Aho-Corasick automatons optimized by:
* only initiate structure search if a placed entity exists on a participating structure template
* initializing different automatons for each type of "placed entity"
* pruning inapplicable row candidates for 2-D search
The row-level structure recognition cache described in #1575 was not implemented; it's probably not worth the complexity cost.
# UI Demo
scripts/play.sh -i scenarios/Testing/1575-structure-recognizer/1575-browse-structures.yaml --autoplay
1. Press `F6` for Structure Browser dialog
2. View http://localhost:5357/recognize/log and http://localhost:5357/recognize/found
# Future improvements
* Refactor `State.hs` so that the new helper functions can live elsewhere
* Support non-rectangular recognizable structures
* Allow flip/rotate of recognizable structures
* Structure ownership by robots
* Consolidate code between the Goals and Structures modal dialogs, and the Achievements browser
* Enforce minimum/maximum dimensions for structure definitions
* add wave program and parametrise it to compare inlined/generic version
* use [`tasty-bench`](https://hackage.haskell.org/package/tasty-bench) library to show comparison
* move benchmarks to test folder as they can now share tasty code
* closes#1574
Using the recursive definition with ifs leads to a 3x slowdown:
```
wavesInlined
10: OK
361 ms ± 29 ms
20: OK
718 ms ± 35 ms
30: OK
1.066 s ± 28 ms
40: OK
1.437 s ± 37 ms
wavesWithDef
10: OK
1.052 s ± 51 ms, 2.92x
20: OK
2.117 s ± 34 ms, 2.95x
30: OK
3.144 s ± 80 ms, 2.95x
40: OK
4.191 s ± 91 ms, 2.92x
```
But if we just inline and simplify the code, we can remove the runtime overhead completely.
In preparation for #1483. `LogEntry` started life as something specific to robot logs. It then evolved to be used in the system log as well (see #1039 and #652), but in a sort of hacky way. This PR refactors `LogEntry` to be more generic.
- Move `Swarm.Game.Log` -> `Swarm.Log` since it's not specific to gameplay.
- Rename `ErrorLevel` to `Severity`, add a new `Info` level, and add a top-level `leSeverity` field
- Rename `leRobotName` to just `leName`, since it was already being used to name both robots and system components anyway
- Move robot-specific fields (*e.g.* robot ID) into the new `RobotLogSource` type, and add `LogSource` to differentiate between robot and system logs
- Various other minor improvements and tweaks
This adds two files. The first is the syntax file responsible for basic highlighting. The highlight categories are based roughly on those seen in the Emacs file ([swarm-mode.el](https://github.com/swarm-game/swarm/blob/main/editors/emacs/swarm-mode.el)). The second is the file for configuring the language server. Since it is based on Neovim's native LSP client, it only works with Neovim and not Vim.
`README.md` in the `editor` folder has also been updated to include instructions for setting these up.
Towards #872
Previously, the `GameState` record had `41` toplevel members. It now has `22`. Logical grouping of the fields makes it easier to peruse the code and paves the way to split `State.hs` into smaller modules. Some functions now may even be able to operate exclusively on subsets of the game state, rather than having to pass in `GameState` as a whole.
There is potential to go even farther, by extracting view-related and robot-related members to their own records, but I figured I'd pursue this refactoring incrementally.
Closes#351.
I sat down with @ccasin today to look at #351. He convinced me that it is actually fine to return `forall a. a -> a` as the type of `r` in `r <- return (\i.i)`, even though `return (\i.i)` has type `forall a. cmd (a -> a)` and we can never have a type `cmd (forall a. a -> a)`. Basically, in a Hindley-Milner-style system it is always safe to generalize at any time.
The real problem --- which I was very close to discovering in https://github.com/swarm-game/swarm/issues/351#issuecomment-1146274801 --- is simply that we need to generalize the type of variables bound by `<-`. However, we need to make sure to do so before putting that variable in the context, which I apparently failed to do when I tried fixing this before.
- give lambdas lower precedence (9) then application (10)
- closes#1468
Before (with #1459):
```
❯ cabal run swarm -O0 -- format <(echo '\\m. case m (\\x. x + 1) (\\y. y * 2)')
\m. case m \x. x + 1 \y. y * 2
```
After:
```
❯ cabal run swarm -O0 -- format <(echo '\\m. case m (\\x. x + 1) (\\y. y * 2)')
\m. case m (\x. x + 1) (\y. y * 2)
```
- improve layout of terms:
- break lines on binds, unless it fits on one line
- lambdas go on same line, but the body _can_ go to next line
- def and let can have long body on next line (indented for def)
- parens and braces have body indented if it does not fit on line
- closes#11
Example using `--format` from #1459:
```
> cabal run swarm -O0 -- format scenarios/Challenges/_blender/patrol-clockwise.sw
def forever = \c. c; force forever c end;
def encircle = \lDir. \rDir.
turn lDir;
b <- blocked;
if b {turn rDir} {wait 1};
fwBlocked <- blocked;
if fwBlocked {turn rDir} {move}
end;
def patrolCW = force forever (force encircle right left) end;
force patrolCW
```
