Well, on my third level, with autoplay, all the breakable bricks were killed, but it kept on going… there were four unbreakable bricks, but of course, they should not count.The “BreakableCount” variable is public static, so does not show up on the inspector. I’d like to see what it’s value is, but it seems the only way is to stop the game, add some debug code, then hope I can duplicate the situation.I know on Linux with GNU tools, I could “attach a debugger” to a running process. I wondered, does Unity allow something similar? I’m using version 5 with Visual studio.
Well, I did find, in VS, under the Debug menu item, is an “attach Unity debugger” option. But I didn’t figure out how to use it. The only “window” populated was “modules”, which had “Symbols not loaded” for every one, and I didn’t even know which module was the right one (there were 50 of them).
In the time it took to get this far, the autoplay (which I left running) managed to lose the game (proving it IS possible).
So, unless someone knows otherwise, I guess my bottom line is:
“you can’t (easily) debug a running game after it’s started; you have to add debug lines/etc. before running”
Edit: Well, it is repeatable, I guess. It happened the second time. Off by one error, when empty, the game thinks there is one block left. And…I used the old-fashioned “just count them on the screen” method: I have 159 bricks but at startup, it thinks I have 160. Now…have to figure out why…
Edit 2: no, that’s not right–it DID correctly think 159 to start, but hitting one brick “disappeared” a brick not even touching it. And I see why–one brick is under the other in the hierarchy… a “mouse-o” (like a typo) I guess. I think that should fix it. A tough one to debug, showing a good reason to check the hierarchy for cleanliness.
Edit 3: For others’ information, I’ll show something I did that ultimately helped me find the problem. My debug lines in Brick.cs were thus, and I could see immediately when my count differed from reality:
