The game's programming is more robust than I would have expected. It's possible to adjust the camera position in various ways (see screenshots). However, the game's logic is based on the partial player model which is included in the scene (in addition to the visible arms, you need to imagine a "hitbox" or "collision space" near the camera itself) and so if you attempt to zoom in on the girl's cleavage then you'll probably trigger a collision and get knocked back to the standard camera position.
You must be registered to see the links
You must be registered to see the links
You must be registered to see the links
The surprising thing is that collisions were registered even after I had used the "passive behaviour" trick described in a previous post. Incidental animations (such as splashing water, stretching her legs, or leaning back in the tub) are all candidates for collision behaviour - it isn't limited to slaps and punches. Of course, the game doesn't actually subtract HP if you trigger one of these accidental collisions; it merely resets your camera position to the default.
Corollary - if you simply zoom out a bit (I suppose "dolly out" would be more precise) or offset the player model sideways, then she'll attack empty air. The AI doesn't actually "aim for the player"; it's apparently hardcoded to throw attacks at a standard position. It's possible to put the player model in a position which will consistently be reached by some of her attacks while others will consistently miss.
You must be registered to see the links
You must be registered to see the links
Please note that no matter how much cheating or hacking I do, the game is
not going to provide a rich or immersive third-person experience. The player model used for the bath scene is incomplete (see screenshot above). If I put in a lot of effort, I *might* be able to substitute the "ghostly" player model from the HScene. Since that model would still be headless, and the legs would be un-animated, the end result would be silly and not worth the work involved.
The player's attack animations use a separate set of camera values, so it isn't possible (yet!) to really do anything with the unusual camera positions.
If* I can get the animations to work with non-standard positions then I might try to actually expand the gameplay a bit. I'm thinking:
- WASD to shift the camera position position (standard FPS control scheme)
- Ctrl key recenters camera at standard position (it normally resets only rotation along the X and Y axes)
- Plus (+) and minus (-) keys adjust zoom level.
- PgUp and PgDown keys control elevation.
Does this sound useful for anyone? It would require a fair amount of work, so I'm not going to bother unless there's some interest. I would also need some volunteers to help me screen out false positives among the pointer chains.
This is a big "if" - I can't promise that it will work.
Limitation -
camera adjustment and third-person view does not work in the HScene. The game uses a similar camera data structure for the HScene, but during that scene the camera parameters are actively and continuously modified by the game (which makes sense: camera motion is integral to a first-person experience). It's possible to modify values (e.g. zoom out to get a wider FOV) but the game
immediately reverts the change. This is a "roadblock" for me at the moment; I can't find any way to influence the HScene (not even cosmetically!) via memory manipulation.
