Open byorgey opened 2 years ago
Honestly, ints as physical entities sounds kinda weird. So far the game seems (at least to me) to be sort of realistic, i.e. robot have to have a specific device to do something, with various mechanics tied to devices like scanners. Summoning values into real world feels like cartoonish magic and out of place.
For poor man's versiof of #94 something like "data port" could be done, which is like antenna with 1 tile radius. Which also can be used for #22
So far the game seems (at least to me) to be sort of realistic
It's not that realistic (and I don't intend it to be): there are lambdas and bits you can harvest! And you make branch predictors out of tree branches! The world is already full of cartoonish, whimsical magic.
Oh, ok! Well then, pile of numbers and throwing ints around definitely fits this setting.
One thing we are currently passing between robots is the log by logger device (and also zero count of discovered entities) by upload
ing, but there is no way to "stringify" values (#248) or test for inventory count (#88) in the game yet.
A fun idea would be to make
a "log copy"
from current logger output and one log, kind of like how Minecraft allows maps to be copied and passed around. Trees are easy to cut down and grow, so passing around logs would be cheap. :evergreen_tree:
Lists would be useful to read the log (#97) but we could (initially) live with log_entry : int -> log -> () + string
as its a safe and efficient lookup on Seq
.
Another idea would be allowing more entities in one world cell stacked on each other with an advanced command to pickAll : cmd (list string)
which also adds the entities to inventory*.
This obviously works as a poor mans passing of ints, just by stacking 1
, but even that could be useful to compile Karel language** to swarm-lang.
If we allow heterogeneous stacking of entities, then binary encoding is suddenly very powerful. :smile:
*) This could also work with the previous idea by having the type cmd string
with the name of the log of picked entities.
**) The robot Karel can stack "marks" in cells, though some versions limit that to 0..9.
I don't really want to allow multiple entities stacked on one cell unless there's a good reason; I'm imagining we would use #115 for this kind of thing.
Hmm, how about a "paper" entity and a way to "print" a value onto a piece of paper and then "read" a value from a piece of paper? Maybe reifying values into physical objects is not so magical after all... =)
So I'm going to make this concrete: how about designing a new printer
device, which works as follows:
print : a -> cmd ()
. If you have at least one paper
entity in your inventory, then one is consumed, and you end up with a printoutNNN
entity (the NNN
should be chosen to make it unique, I guess?).scanner
device enables read : string -> cmd a
which takes the name of a printout entity and reads it back into a value of the expected type (if possible).Now that I write this down it seems like there are still some issues to be worked out...
I like the printing idea 👍
Would the expected type be determined from context? Sounds like it would be necessary to check for escaping type variable like in #351. 😟
Also what is going to be the “paper” recipe? I would like something like wood+water+furnace so that I could stock up quickly on such useful entity. 🙂
Yes, the expected type would be determined from context, just like Haskell's show
and read
. #351 seems unrelated, I don't foresee any particular issues in terms of the type system.
wood+water+furnace sounds like a good recipe for paper. I guess the more interesting question to me is what is going to be the recipe for a printer
?
Some questions I still have:
printout
once you are done with it?About the uniqueness, is there a reason why we can not just modify the entity map?
If we wanted to thwart instant communication via entity numbering, we could make it per robot. So "printout #1 by mad_max"
.
Getting rid of it is also interesting, we could add a crusher tool to recycle paper into dirt. ♻️ Maybe trees could only be planted on a dirt layer. EDIT: I was also thinking about throwing it into the water, but that is irresponsible and there is already an entity there.
Yes, we can just insert a new entry in the entity map, that's not what I was worried about. I like the idea to name printouts by robot, like printout #1 by mad_max
. However that is not really guaranteed to be unique, because robot names are not unique. I guess we could just append the robot's internal ID as well, or something like that. Or maybe better, we can just make sure the name is unique before inserting in the entity map, and only modify it to make it unique as necessary.
Maybe the tool to recycle paper could be a shredder
instead of a crusher?
We could add some lava
terrain that you could throw things into... :thinking:
So we now have a printer
entity since 34db400 . However, it doesn't yet do anything. We are probably going to change the name to typewriter
(see #563). Actually printing things on paper probably should wait until after #455 .
EDIT: as of https://github.com/swarm-game/swarm/commit/e1728a37ba1cd3fded04e073057f1c41e4ad4265 the entity is named typewriter
.
Note for posterity: there is now a linotype
device (#1339) to convert a Value to a string
.
A robot has entities in its inventory, and also has values referred to by its running program. It's fun to contemplate ways to blur the lines between the two. This ticket is really meant more to spur discussion than to represent a specific task that needs to be done (perhaps some specific tasks may spin out of it later).
cons
entities in your inventory? Surely this isn't a great idea in general---it would be way less efficient---but it's fun to think about.give
it to another robot, who could reflect it back to anint
value. This would be like a poor man's version of #94 before you have developed the necessary tech to properly send values over channels.See also #455 which is probably a prerequisite.