To expand or not to expand the map interface...

[JonathanArns]

This is related to this PR and is also sort of an answer to today's "battlesnake codes" stream to continue the discussion here.

@coreyja and I were recently brainstorming some map ideas with moving hazards (dodgeball) and we came to the conclusion that the current map interface does not support this in a way that makes sense to the viewer, since hazards can only be moved after damage is applied. The problem with that is that for example a dodgeball that looks like it did hit will not do any damage and one that looks like it missed by one turn will actually apply damage.

I would really like a way to implement moving objects in maps, since it enables a bunch of cool maps that are also visually appealing.
The PR that was linked above is a version of this that we came up with and were able to implement as a proof of concept. Please also propose alternative approaches.

Of course I also see some downsides... some less beginner friendly maps, the option to build maps that feel like the bad kind of rng.

In terms of not wanting to do anything to the snakes that they couldn't predict, I think most tree search snakes already precompute future hazard placements whenever possible. To my snake at least, this would really not be any different than existing maps like spiral and sinkholes.

So let's discuss :)

[coreyja]

👋 Just caught up on the latest "Battlesnake Codes" VOD so leaving some comments about things here!

In terms of not wanting to do anything to the snakes that they couldn't predict

Ya I think I agree with Jonathan here! I totally get wanting things to be predictable, but that already isn't 100% possible today with food and hazards spawns. While it does create the possibility of 'bad' maps/modes I think thoughtful modes could take advantage and work really well!

Maps vs Stages

But that said, I'm not sure if these things should be Maps vs Stages 🤔 Like should Dodgeball be more of a 'Map' or a 'Stage'? Like Chris was talking about on stream, the distinction seems a bit fuzzy to me!

Moving objects could probably be implemented as a 'stage' today, on top of an existing map! But I think basically anything could be implemented as a stage today, so what should be a map?

In terms of custom things I've worked on (or brainstormed):

• Single Player Maze
  • I think this feels correct as a map. Didn't interact with game mechanics, map feels right!
  • If some other settings like hazardDamagePerTurn were map settings I think this could feel even better
• Snail Mode
  • Currently implemented as a Map, but maybe this is really a stage? I think we could make some adjustments to have this work as a stage, and potentially not need to store state! [If the stage ran first and places a hazard on tails before moving happened, I don't think we'd need state
• DodgeBall [or other moving hazards]
  • Maybe this is implemented as a stage too? The moving hazards feel like being a 'stage' would work better, if it was an 'early' stage in the list

[robbles]

Hey @JonathanArns and @coreyja - thanks for your thoughts on this!

We've discussed a few options related to this internally, and I wanted to confirm a few things to make sure I understand the use case.

It sounds like the main idea here is being able to move or place a hazard before damage is applied, but after the last turn has been shown on the board already. So currently, if you move a hazard to where it's supposed to be on the current turn, it'll appear to damage snakes incorrectly (as described above), and you can't move it one turn ahead because the board is shown immediately after the map takes affect.

I think that means providing more information to the UpdateBoard methods will not help, because it's primarily the order that matters here - right? One variation we discussed recently was to pass the original board state to UpdateBoard so that it can see what the board was like before the rules pipeline took effect - e.g. something like:

UpdateBoard(initialBoardState *rules.BoardState, currentBoardState *rules.BoardState, settings rules.Settings, editor Editor)

I think that's potentially helpful for checking what's occurred on the current turn, but without expanding what maps can do to the board state, that still wouldn't work for this particular use case.

Just to expand a little on what Chris was saying about predictability - it's not about the RNG aspect of where hazards/food spawn, but whether snakes have made a decision based on incorrect data. With the current suggested implementation, we would be sending the current board to each snake, then moving some stuff around on the board, then applying their moves and other rules. So they've made decisions based on a board that has already changed.
I think we can resolve that pretty easily though, if we change the order to something like this:

1. PreUpdateBoard
2. Send /move requests, with the updated board state
3. CreateNextBoardState
4. UpdateBoard
   I think that would allow moving or placing hazards or food at the right point in time, while still making sure snakes can react to them. Does that still make sense? Let me know if I've missed something here, or completely misunderstood!

[JonathanArns]

First of all, thank you for taking the time @robbles, I appreciate it a lot! :)
I think you understood everything correctly and your solution sounds good. I think it's important to include the "display the board to humans" step in the order though, since the problem we are trying to solve is mainly a visual one.

So in my mind that step is implicitly at then end of your list to look something like this:

1. Map.PreUpdateBoard
2. Send /move requests
3. Apply rules
4. Map.UpdateBoard
5. Display current board to users

Then we have effectively no change from the snakes' point of view. The only change is that we can choose to move things before or after the user sees it.

I like that solution a lot!

[JonathanArns]

One thing that just occurred to me is that this would still break some stuff like the JSON exporter browser extensions on maps that use this, because the displayed game state is not the one that is sent to the snakes.

[robbles]

@JonathanArns / @coreyja I think we're in agreement on this - are either / both of you interested in working further on it? I'm happy to review an updated implementation and figure out how to work it into the production engine afterwords, but probably won't be working on it for a while otherwise.

[JonathanArns]

Yeah I'm down to work this further for sure, I'm guessing @coreyja and I will coordinate somehow and come back with a proper go at the implementation :>

[robbles]

Closing this because we integrated PreUpdateBoard in BattlesnakeOfficial/rules#118!

Just to be fully transparent, this has not been fully integrated into the production engine yet because we delayed rolling out the new version until after the Fall League tournaments.

The snail_mode map and any others that might use this feature are usable "in beta" via the CLI though.