One of the ideas I had for identifying position/orientation variables is to pay attention to user input. So, if there is a value that consistently changes either liniearly, or with constant acceleration, when a directional button is held, it's a strong candidate for position, angle, or velocity. If it's the sort of game where it's practical to look at the screen directly, it'd be possible (if horribly inefficient) to do some kind of motion-detection, and notice when regions of motion tend to correspond with changes in pairs or triplets that could be coordinates or velocity, and eventually refine this with more data until there's a usable model of where object positions are found.
With modern stuff, you'll run into some common or very similar physics engines, some of which will neatly track objects such that finding the necessary chains would be fairly easy. Or, at least, I should hope so. If it's not C/C++/assembly, memory allocation gets "fun". So the more information on what was used to develop any particular game, the more techniques for hunting down the most relevant information can be refined.
SoR2 is extremely low in complex layouts (at most, there are 3 levels with diagonel sections), so my program just tracks the player, enemies, items, and a few other variables like screen/settings/time. Item detection is kinda unreliable, as it's bad at distinguishing active items from uninitialized junk, but it has no trouble finding enemies. The biggest weakness is probably the refresh rate. It offers two ways to get information: examine the enemies via tts, and just get names/numbers directly, or loop a sound at their position (iirc, individual enemies can be muted if the noise outweighs the usability). The sound files are easily replaced, and there's a default for any enemies or items that don't have associated files. It uses pitch-bending for y position, but that's because I prefer clarity to realism most people seem to prefer the opposite.
I've tried accessifying Mario and Sonic, also, but couldn't really use a single method for both. And in both cases, I wound up trying to rebuild the games from scratch (there was a Sonic 3 savestate reader, but it was way less developed than the SoR2 one). Mario is simple enough, with enemies playing sounds as they move, and sweeping ahead every time Mario moves to a new x position (measured in blocks, because anything else would be overkill). The sweep could be set to find blocks above, and drops by counting the distance to blocks below. It only looks ahead... 5 blocks, I think? It also identifys glowing blocks, pipes, and coins with sounds during the sweeps. (my coin sound is kinda terrible and I should have just pitch-bent the normal coin sound ). In addition, there's a cursor which the player can move around block-by-block, to hear what's there, and it has a keystroke to scan the column it's in to more quickly find platforms/drops. The cursor does speak the name of any enemies or powerups it passes over. Moving platforms play a distinct sound to indicate which direction they're moving. And that more or less covers it.
Sonic was harder. I tried breaking up the track into linear segments, straightening out any curves, and have a sound play to indicate the angle of a section when Sonic gets close. There was also a way to have Tails fly along the track, to give a more continuous idea of its shape. There was also an object list to give raw information to screen readers, pits all played 16-bit noise on a loop, enemies and rings made sound in accordance with their animation, and pitch-bending for y was a togglable feature. This did not work past the second act of Green Hills Zone.
Bokurano Daibouken 3 uses something like an improved version of what I did with Mario, and includes a cursor, an object viewer for raw info, echoes player footsteps from the nearest ledge, and can scan ahead every second or so for the nearest blocks ahead and above.
So anything which can be neatly divided into rectangular grids almost has a standard, which can be adapted for 3d. More complex layouts are harder and I keep coming back to a vOICe-like model of tonal scans. I don't see this program supporting that sort of thing very easily, but more discrete scanning like BD3 seems manageable.
Swamp has a very cane-like scanning, which can be set to the direction of interest as needed (ex, if you're looking for an opening in a wall to your left, it can just scan a few rows to your left). I feel like something like this would make a ton of 3d games far more playable, if not completely so, much like a cane makes the real world more accessible. To the extent that someone could almost certainly slap together a generalizable version for Unity in an hour or 3. But I'm not familiar with Unity's approach to physics, so I could be horribly mistaken.
This brings us back to the question of what this software can do . I expect the ability to scan for things wouldn't be too difficult once one has a good map of the way the game stores layouts, so stereo pan and the ability to put this on a timer would cover most of it. Going full vOICe would require rather different features than what this is designed around, I think.
看過來!
"If you want utopia but reality gives you Lovecraft, you don't give up, you carve your utopia out of the corpses of dead gods."
MaxAngor wrote:
George... Don't do that.