Give view a limited broadcast range
#17
Comments
byorgey
added
Z-Feature
|
Would also be nice to have API for antenna to allow some semi-autonomous robots maybe. |
|
Hi @Anrock , thanks for the idea! However, I'm not sure I understand what you mean. What kind of API do you imagine? And can you explain what you mean by "semi-autonomous"? |
In Colobot there were "Exchange posts" buildings, where robots could store/retrieve info. API was basically a wrapper for string-string map, like So if we replace "exchange post" with "any entity with antenna" that would go as API for swarm. Distance argument in Colobot was there since every robot had depletable battery and distance affected how much energy was spent for a broadcast, we can drop that since bots seems to have indefinite batteries in swarm. Further improvement of API could include storing something more interesting than strings for values, for example scan data or functions. Some kind of callback/notification mechanism when some broadcast is received seems to be good to have too.
If understand correctly, in Swarm once robot is built it will execute its program and there is no way to alter it or control robot dynamically. With antennas you can write something like that by broadcasting commands from base and writing an interpreter on bot side to execute those commands. Using base REPL it can be done interactively. |
|
Ah, now I see what you mean. Yes, inter-robot communication is absolutely something we want! It should definitely require an antenna but probably more stuff as well. The antenna described in this issue is for a capability you should be able to get pretty early on, whereas inter-robot communication seems like a much more powerful feature that should only be obtained deeper into the game. Anyway, I've created a new issue to track this idea: #94. |
|
Note, I think we need to implement #35 before we implement this. Without the initial use of the |
|
For limited broadcast ranges, I had a fun idea: instead of just being a sharp cutoff at a specific distance, there could be a gradual falloff in signal strength, such that when you Concretely, for each cell we could generate a pseudorandom number which is a deterministic function of its coordinates, uniformly distributed between 0 and 1 (i.e. via some kind of hash function on the coordinates); we display the cell or not depending on how its number compares to the visibility probability. This means the pattern of visible and invisible cells would remain stable as the robot moves around etc. Or, if we want to simulate more dynamic "static", we could e.g. have a counter which goes up once per second or something like that, and include the current counter value as an input to the hash function along with the coordinates, so that the pattern changes every second (having the static pattern change every frame would probably be too much). |
…e logs (#128) The original main goals of this PR are to (1) solve #36 , that is, make the bottom-left info area fully wrapped and scrollable; and (2) solve #40 , that is, persist the info in that bottom-left info area even when switching to other panels. In order to address those I ended up making a rather large constellation of related changes, which in the end I hope work well with each other. Eager to hear others' feedback either from looking at the code or just trying out the game with this PR. - In order to make the bottom-left area scrollable, split it out into its own panel. Now we can focus it and then use normal keybindings to scroll it. - The bottom-left info panel now indicates whether it has additional content scrolled off the top or bottom. - The bottom-left panel used to display a global list of log/error messages when the inventory was not focused. So where will those messages be viewable now, if the information displayed in the bottom-left panel persists? My answer: there is a special `logger` device (#39) which, when focused, now displays the log messages. - This means that logs are now per-robot instead of global. - The base starts with a `logger` installed. - A `log` command can be used to write to a logger. - Uncaught exceptions also now write to a logger (instead of using `say`), or are simply discarded if there is no `logger` device installed. - The first time a robot's inventory is viewed after a message has been appended to its log, the `logger` device will be automatically focused and the log scrolled all the way to the bottom to show the new entry. This means that e.g. typing `move` at the REPL will immediately show an exception in the lower left. - Add a `salvage` command, making it possible to access the log of a dead robot after the fact, once we implement #17 . There are still a few issues to address which I think can be done in separate PRs: - The global message log still exists, and the `say` command still appends to it, but there is no way to view it. Obviously we need to do something with this --- either get rid of it, or figure out a sensible way to view it, etc. - Exception messages should probably be reformatted to not include any newlines, now that we know they will be wrapped. Closes #36. Closes #40. Closes #39. Closes #21.
|
I intentionally did not include this issue in the roadmap for an alpha release (https://github.com/orgs/swarm-game/projects/1) --- I don't think it's critical, and it would actually make the game harder. Perhaps we might consider having this be part of some kind of "hardcore" mode. |
byorgey
added
C-Moderate Effort
byorgey
changed the title
view a limited broadcast range
|
So as of #483 we have a robot list panel. At this point I think we should just say that standard robot chassis have a basic antenna built in, and not require installing them separately for purposes of viewing robots in the list or executing |
|
This is now the least-recently-edited issue, and also one of our oldest, and I think it shouldn't be too hard to tackle now. Here's my current plan: (1) make visibility drop off with distance when |
|
Terminology for reference: Fog of war |
The basic principle here is that you cannot communicate with robots that are too far away. We also want to uphold the principle that it is not possible to instantly communicate information over arbitrary distances. Concretely, there is now an "inner radius" (16 by default) and an "outer radius" (64 by default). * Inside of the inner radius, communication is perfect. * Between the inner and outer radius, the `view` becomes increasingly covered with "static". * Outside the outer radius, the view is completely static, *and* it is impossible to see a viewed robot's inventory. In particular there should be absolutely no difference between trying to `view` a robot that is deceased vs a robot that is too far away. A nice bonus feature is that if you are `view`ing a robot that is suddenly destroyed, e.g. by driving into the water, the entire view instantly turns to static, which looks cool. The static is based on a hash of the offset from the view center to the cell + the current tick count / 16. That means that the static pattern (1) doesn't shift when the viewed robot moves around, and (2) randomly changes every second or so. [See this asciinema cast](https://asciinema.org/a/564988) for a demo of it in action. Closes #17 . - [x] update `antenna` description
This issue used to be about adding an
antennaentity to enableview, but see comments below for some reasons why I no longer think we should do that.I'm thinking there can be an "Antenna" entity.
broadcastcapability, with a correspondingbroadcastcommand.base) which have executedbroadcastcan be viewed with theviewcommand.The text was updated successfully, but these errors were encountered: