Debug information is crucial
Center position of offseted character sprite
Recently I'm working on one of my game project after having fun with Ludum Dare 25 event. One of the thing I've found that is pretty much important is debug information.
Hell yeah, it's so usual and very normal to talk about it but I believe most of programmers out there still regard it as a low priority or things that can be skipped if we don't really need it. It's kind of lazy stuff, you know, if talk about debugging.
I'm one of them, at least in the past before this post popped up. Easy to medium technical problems might not need any debugging information while you're working on it. But hard to very complex task actually need it. I admit that I treat debugging information as the task to be mostly avoided. It's like lines of code that don't get into production or real use, you will remove it or disable it anyway at the end. So mostly I skip it left around only the most important one that I need during solving some problems.
Anyway I found out that you may want it even if you don't need it in some cases. Those cases may block your sight to see the clearer solution in the future if you don't show out those debug information while you're working. Take my case as example here, I were working on larger spriteframe size than the actual character fitting in. That means your character sits around in the corner while left most of the space for future addition if need to. These things need offsetting and resetting pivot (or anchor) position. Sure things, stuff I mentioned is regarded as not too hard problem and my decision as you might expect was not to include debug information from the start time working on it.
What debug information I may need is
Center of mass (or just plain center position or pivot position in my case) of character rendered on screen.
I mostly noted out and calculated stuff in a paper and simulately map those things into the screen manually. That's kind of experience is cumbersome in some cases, and might prove nothing because it may be wrong!
Yes, something went wrong and the exact calculation or things I expect to perceive was not there. Until I include such debug information and render it on screen, I clearly see what's right or should be fixed right away. It turns out to help most of my messy and un-happy code and twists it up-side-down. A better and well organized code version.
It shows that I were using a bad approach as I used manual offsetting. It has painful problem with bounding and collision checking code as I need to manually incorporate character's offset position in addition to positioning it properly in case of flipping. The sense of position of character is not in natural way, pretty weird and not like normal thinking process to deal with. Very painful to talk about. It turns out that a better solution is just to set a new pivot position instead of manual calculations I all worked on from the start. I removed most of the code there, and the new code version is pretty much I'm happy with.
Yes, it's because I saw a trigger! I saw that wrong center of mass position of a character itself.
I take this as a top priority while you're brewing stuff. You should render it out on screen from day one. It might be case that XCode may fail in building your project silently but it shows you simulator to test things on. You think it's okay and not even look at the error message pops up in the editor. You just test a wrong build version!
As you need to test things out on various devices, it will prove to be good practice. Such case is if you build your project for iPhone 4' as selected in simulator's hardware. You tested it, and now willing to switch to another hardware device. Switching is done but the build version on target device is wrong as in some cases XCode needs to rebuild stuff and it's not always there across iDevice to be tested on simulator. Build number as showed on screen will indicate things at the first go.
Happy coding and brewing stuff!
