Terrain types and resistance to movement

[jrvieira]

It's interesting having different types of terrain have different levels of resistance to movement, meaning that the move command takes a different ammount of ticks to execute depending on what type of terrain we're on.

The ability to pave the terrain (building roads and such) for some advantage would be nice.

[jrvieira]

It can be very useful for robots to synchronize their movements. Roads can guarantee that all robots take the same ammount of ticks per move.

This can also contribute to scaling difficulty with expansion!

[byorgey]

I think this sounds like a fun idea. A few thoughts:

• I guess we would update the terrainMap to also store something like a friction value for each terrain type.

  swarm/src/Swarm/Game/Terrain.hs

  Line 52 in 7d2339f

  terrainMap :: Map TerrainType Display

• The friction value could be an Int representing the number of ticks required per step.
• We could then update the implementation of the Move command:
  • Make a new (internal, i.e. not available in the surface syntax) "immediate move" command which simply does what the Move command does now.
  • The new implementation of Movewill look up the friction value for the current terrain (one could also imagine basing movement on the terrain we are moving into, but for some reason it makes more sense to me to use the friction value for the terrain we are moving out of).
  • If the friction value is 1, it will just call ImmediateMove.
  • If the friction value is > 1, put the robot to sleep for an appropriate amount of time (one less than the friction, I guess) and schedule it to perform an "immediate move" when it wakes up.
• This also made me think that it could be fun if ice terrain has a friction value of 0, meaning that once you start moving on ice you keep moving in the same direction until running into something (or landing on terrain with a nonzero friction).
  • This could create possibilities for some fun puzzles.
  • I am not sure off the top of my head how we would implement it. I guess we add a "velocity" field to robots, which is normally zero; after every move we look at the friction of the terrain we are moving to, and set the velocity accordingly. On every tick, robots with a nonzero velocity are moved automatically; any move command they execute is ignored, although any other commands will continue to operate as normal.

[byorgey]

Some ideas for terrain types, with suggested friction values:

• Stone (1)
• Grass (2)
• Dirt (2)
• Swamp (5)

Maybe mountains, instead of being impassable, could just have a very high friction value (e.g. 10 or 20).

Also, perhaps tank treads could reduce the friction by a certain factor (say, half, rounded up).

[byorgey]

Also, if we want to allow road-building, then there would need to be a way to "terraform", i.e. change the terrain value.

[xsebek]

@byorgey terraforming would be useful for system robots. 👍

I wanted to reveal new rooms in a challenge but realized I could not change the terrain. I can work around it using blank terrain everywhere or with entities that obscure the terrain, but being able to change it would be nice.

[byorgey]

Right now terrain is immutable but there's not really any good reason for that.

[xsebek]

This also made me think that it could be fun if ice terrain has a friction value of 0,... I am not sure off the top of my head how we would implement it.

I guess we would need a map of sliding robots. 🤔 That way, whatever the robot is doing it will slide on the ice at the end of the tick. A funny consequence of that design would be that moving and sliding in one direction would be the fastest way to move with 2 squares per tick.

  , slidingRobots :: Map RID Direction

^{If we wanted to see the individual moves, I think we would have to refresh the UI before and after the sliding.}

[byorgey]

I don't understand, why would they move twice per tick? My idea was that if a robot is sliding then any move command it might try to execute is ignored. Though maybe it would be fun if move commands just add to your velocity... 🤔 Could be a fun way to get places quickly: build an ice track, then you can accelerate continuously until the halfway point, then turn around and decelerate until reaching the destination. I don't know what should happen if you e.g. run into a boulder while traveling very fast...

In any case, a slidingRobots map makes sense.

[xsebek]

@byorgey I was thinking about sliding in a different way - a bonus move at the end of the tick. Executing move would change the direction of sliding or stop.

In that system we can have fun with adding the direction of slide and move and possibly moving diagonally.

Making velocity more than one extra move is a bit more complicated and I am afraid it would be hard to see on the map.

[xsebek]

But a frictionless ice where you keep your direction from stepping onto it also sounds like fun! 👍

[kostmo]

It could make for a fun programming challenge to cross a swamp/quicksand with a pair of leapfrogging robots. The property of this type of terrain would be: a tile is only passable of it is occupied by another robot.

An extension would be: after completing one challenge with a pair of robots, the next challenge is to make a long bridge of robots.

Continuing a stream of consciousness: can we make a wolf, goat, cabbage game out of river-crossing?

[kostmo]

Taking some inspiration from an ice surface that only allows travel in a straight line...
And the fact that one cannot "turn" to cardinal/"absolute" directions unless a compass is equipped...

What if we took that idea a step further, and made it so that on any terrain, robots can only travel forwards or backwards along a straight line from the base, unless equipped with a "steering wheel". To put another way, only longitudinal, not lateral, movement is allowed by default.

Perhaps this mechanic would only be exploited in niche challenges, and robots would normally have steering wheels equipped by default, like solar panels are in the tutorials.

[kostmo]

Back to the ice sliding mechanic, I recall playing a game where tiles that represented 45 degree walls could "divert" the "missile" to the side by one tile, and thereafter the missile continues along the original direction (now offset laterally by one tile). Such "sloped" environmental obstacles might also work into puzzles with the "no steering wheel" mechanic.

[jrvieira]

Chip's Challenge

[kostmo]

Chip's Challenge

Such nostalgia!

That's a great source of inspiration for tile-based puzzles.

[kostmo]

I recall playing a game where tiles that represented 45 degree walls could "divert" the "missile" to the side by one tile, and thereafter the missile continues along the original direction (now offset laterally by one tile).

In fact the game I was thinking of is called Hero's Heart (DOS), or Hero's Hearts (Windows). Coincidentally, a comment on this page described it as similar to Chip's Challenge.