Mirrors and cameras would work similarly. For performance reasons, the game calculates what squares you can see in a big batch and writes them to a big table using a technique called shadowcasting, like so: (the @ is just there for illustration)
In a car it might look something like this:
(Car for reference, the boards “|” block sight)
0==0
|""|
+@#+
+##+
|HH|
0++0
00111111111
00111111111
11011111110
11101111100
11111111011
11111@11111
11111111111
11111111111
11100111011
11000111001
11001111100
A mirror would have a facing and a width, like headlights. As a final step (after shadowcasting) when determining FOV, the code would check if you can see any mirrors, and if you can, it will project cones from the mirrors to their facing that make tiles visible if they aren’t already.
If we stick mirrors on the forward boards of the car vacing backwards at an outward angle, it’ll reveal something like:
00000000000
00000000000
00000000000
00000000000
00000000000
00011@01100
00011001100
00111001110
00110000110
01110000111
01110000111
Merging the two, you get:
00111111111
00111111111
11011111110
11101111100
11111111011
11111@11111
11111111111
11111111111
11110111111
11110111111
11111111111
You still have a bit of a blind spot, but that’s normal. There might be some fixups we need to do to keep this from messing up other parts of the code, but that’s basically how it’ll work. Probably won’t allow mirror->mirror bouncing, because that could get really expensive if we’re not careful.
The only difference with cameras is the spot that’s required to be visible (the screen) might be in a different location than the spot that projects vision (the camera).
Was discussing towing/trailering just yesterday on IRC, it’s feasable, it turns out making a flatbed that can pick up cars is easier to code, go figure.
