Mithfindel
Gallente
Gariushi Foundation
   |
Posted - 2008.10.17 10:36:00 -
[1]
Edited by: Mithfindel on 17/10/2008 10:38:02
View from the ship wouldn't actually be that bad if we consider prime fiction. If the pod is able to produce a (simulated "computer-generated") view from the perspective of a camera drone a few hundred kilometers away, I'd expect mounting a camera on the hull of the ship wouldn't be that bad. Okay, okay, it could get fried if battle damage happens. How come camera drones don't get fried in, say, doomsday/smartbomb blasts? The ship has a practically never ending supply of new drones? Alright, just make a mechanism that uses that practically never ending supply to replace the hull-mounted sensors. (Btw, your main sensors - that is RADAR, LADAR, gravimetric etc. never seem to get fried. Time to give a hint to the camera manufacturers about what "rugged military tech" means.)
So, the fluff excuse is manure. "First person" or rather "hull" view is certainly possible. I'd personally do one-up, scrap the "camera drones are the pilots eyes" idea and call the view the capsuleer sees completely computer generated based on multiple sensor input from sensors mounted both on drones and on hull. For example, the fiction does mention that sound doesn't transmit well in near-vacuum conditions and credits the sounds the capsuleer hears to the advanced pod interface generating audio feedback from sensor data. In real-life technical terms, this is a client-side thing and I assume it's just the matter of fixing the camera (i.e. what you see on screen) location on the ship coordinates, and hide the hull of your own ship. It could even have the camera mounted on the surface of the hull, showing your own hull in the view for those cinematic shots.
The "FPS-like" movement is completely another thing. With point and click movement you can do things like "start moving at that direction with this speed", "approach this target", and "orbit this target at x km". Technically you can do the same on "joystick-like" controls, just send control input when it's needed. However, things like orbit change from "orbit at x km" to gazillion-times "change course to (x, y, z) at speed v". Possibly in the order of multiple times per second. Which isn't nice for performance. Technically the client could moderate the amount of requests sent to the server as a kind of an anti-flood measure, but this would likely make the controls seem choppy and still cause more requests to the server overall - while there are people who can "fly manually" with the mouse-based interface, their amount is smaller by a very large fraction that people who would use a "joystick" interface if one would be provided.
If we have a look on how the game engine reacts now, we do notice that even on nearly lagless, modules seem to activate in a turn-based fashion. (Can't even be completely without lag, though if you're physically gaming from the building hosting the TQ cluster you could get pretty short response times.) The turn length seems to be in the order of a second or two, though when no commands are taken and the modules have autorepeat active, I'd expect the server to do firing time calculations as accurately as its floating-point algorithms allow. (In other words, if the turret firest every 2.5 seconds, it doesn't get stuck firing "every third turn" (assuming turns of one second). Also on turn-based and real-time games: No games are really real-time, they just use turns that are so short that we can't perceive them. EVE's turns appear (even when the server doesn't lag) to be of longer duration likely because of longer turn times (tics) to save on computing time lost on overhead (book-keeping done on every turn etc.) and because of network lag.
|