^ the "actual" values - used by the game - might be different as to what is shown onscreen. Eg: you have 5 balls, but ingame 20 (or whatever) is used as count/reference_value. Also, that value could be "disguised" in so many ways: eg actual value = (5 + 22) / 7 - 2 (possibilities are endless of course); iow in some way obfuscated. (and perhaps even hashed ~ which is where i stop researching...
)
That said: at some point you will (always) find that particular/ingame value on the stack... (usually taking some - time-consuming - debugging).
My approach would be:
1. scan for either: integer - 2byte - byte value, and go for increased. (if the game is 32bit, you might find some values quickly)
~> pretty rare that such values are float
2. scan for the above decreasing. note: in both cases i would start with 'increase/decrease by 1' every time you consume a ball...
3. scan for ANY value_type, and perform very same as in 1./2.
ps: usually you should be able to find the onscreen/display value; and manipulate that one. But: if they recalc with every frame(s) update, that value will/might "move" accordingly in memory, so...
But if you do find it, check out what code accesses it, and start your debugging from there... either the actual value is updated beyond that point, OR before that point. "Follow" that value up (or down) the stack untill it "disappears"; then from that point move back to the point where it will appear again on the stack... this will give you the register value that holds the actual value, and the opcode should tell you where it got that one from... (~ some structure -> offset)
to answer your next Q: no
ps2: i recently added a 'skill points' feature to my AC Syndicate table, which is a good example of what I mean. in fact, ACU does something similar with the 'Sync Points'... (it took me 4~6 hrs of debugging, just to get that one particular value; AND i was actually looking for a different - related - value then
)