It looks like you're new here. If you want to get involved, click one of these buttons!
screen_point = world_point * object_position_matrix * inverse(camera_position_matrix) * camera_projection_matrix
world_point = screen_point * camera_position_matrix * inverse(camera_projection_matrix)
world_point_a = vec3(screen_point, 0.0) * camera_position_matrix * inverse(camera_projection_matrix)
world_point_b = vec3(screen_point, 1.0) * camera_position_matrix * inverse(camera_projection_matrix)
Heck if it did run on a pi it could be configured as its own wifi hotspot, making it a fully self contained bridge game
Some games lack this meaningful decision aspect at all. If there is only a single path forwards, no difference between decisions you make. Then you have a story (movie/book) not a game.
I feel like this is missing from this genre, where the game server also serves a simplified, phone sized web UI for simpler, shorter crewing.
EE1 only has a http interface, which will depend on polling. It can access a lot of things to make a web based user interface. However due to the polling it might be a bit slower in response times.
EE2 will have a websocket API for fast realtime interfacing to the game.
Cool! BTW also interesting that you now have chosen SDL2 for EE2, as that was not among your considerations in the "pondering" thread. But it is surely a good choice and well supported.
Yeah, I get distracted with other work and projects too, haha. But I keep an eye on development on the current EE, so I'm keen to follow and help v2 where I can as far as design and UI/UX go.
EE1 has keybindings, they just don't work as well, only allow keyboard bindings (not mouse/joystick/gamepads) and are a bit more hacked into it.