We’ve been working on updating In The Dark to the latest version of box2D and while we’re at it are rewriting and optimizing pretty much everything a long the way. My goal is to hit 50 average FPS on my netbook. If we can manage that then I think mobile ports will be significantly more feasible in the near future. Unfortunately this has also opened up quite a few little bugs that we have to work out, and thats eaten up most of our time over the last 2 weeks. As an example I recently wrote about how the lights for ITD are calculated. The old version was 460 lines of code, the new one is only 240. That doesn’t always mean faster, but I think most programmers will agree that “less is more”.
Sadly on rare occasions the new lighting makes mistakes.
In any other game the developer would probably say “meh” and just leave it, but in In The Dark that sliver of light could make a puzzle impossible. The tough part is deciding the level of error checking to include. You usually can’t make something 100%, so you just have to make do with 99.9% and hope that that other .1% doesn’t ruin the game for someone.
I’m sure almost anyone who has played a few modern video games has seen a physics engine fail, if it sends an object flying into the distance or makes it fall through the ground thats fine as long as that object wasn’t important and it didn’t fly through you and kill you or something. The industry standard says this is ok, but I would rather make games that have an order of magnitude lower rate of failure.