swarm-game / swarm

Resource gathering + programming game
Other
835 stars 52 forks source link

Use `typewriter` device for reifying values as entities #116

Open byorgey opened 2 years ago

byorgey commented 2 years ago

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).

See also #455 which is probably a prerequisite.

Anrock commented 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

byorgey commented 2 years ago

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.

Anrock commented 2 years ago

Oh, ok! Well then, pile of numbers and throwing ints around definitely fits this setting.

xsebek commented 2 years ago

One thing we are currently passing between robots is the log by logger device (and also zero count of discovered entities) by uploading, 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.

xsebek commented 2 years ago

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.

byorgey commented 2 years ago

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.

byorgey commented 2 years ago

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... =)

byorgey commented 2 years ago

So I'm going to make this concrete: how about designing a new printer device, which works as follows:

Now that I write this down it seems like there are still some issues to be worked out...

xsebek commented 2 years ago

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. 🙂

byorgey commented 2 years ago

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:

xsebek commented 2 years ago

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.

byorgey commented 2 years ago

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:

byorgey commented 2 years ago

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.

kostmo commented 1 year ago

Note for posterity: there is now a linotype device (#1339) to convert a Value to a string.