Did you know that bullets (and other quick moving objects) in video games sometimes exhibit magical properties if they move too fast? If they gain enough speed, sometimes they can even pass completely through other objects without leaving a scratch or affecting them at all! You might have seen this happen occasionally in games that have a lot of complicated physics simulation. Sometimes fast moving objects just seem to pass through the ground or other objects. Unfortunately this is not a desirable user experience and it quickly breaks the illusion the game is trying to convey. This phenomenon is called “tunneling” and game developers attempt to deal with it in a variety of different ways. I thought I would share my unique combination of techniques to deal with it that I used in Cannonade. I have not seen this specific combination of techniques explained or suggested anywhere and so I thought it might be beneficial to share what I have learned with others who might also be suffering from object tunneling woes. First lets explain how most modern game physics simulation works and investigate why this problem crops up.

(more…)

The two most note worthy changes in this build are SPEED and WEAPONS! After spending two days on physics performance optimization and a week and a half on graphics performance optimization Cannonade now runs a lot faster on both the iPhone and the iPad! There are still speed gains to be had but the framerate difference is like night and day. Thanks to your voting, in this build we also have the debut of the Gravity Bomb, Fire Bomb and Friction Bomb weapons. They still need to be tweaked and balanced but they are still fun to play with. Give them a shot!

Complete Changelist:

• Bumped engineCompatibility to 0.5.7. (this means all games previously created by versions <= 0.5.6 will be deleted)
• Did a lot more investigation into physics performance. Content with how much I have for now.
• A HUGE graphics performance related commit.
• Added the Gravity Bomb, Fire Bomb and Friction Bomb weapons.
• Added powerSlider tuning buttons
• Added a block override fade timer
• Added all sorts of neat effects to the gravity, fire and friction bombs.
• Added a new lava island level to design around the !FOGENABLED and NONBLENDEDLAVA speedups.
• Initial “connection-less” Game Center implementation. Initial support for key-based communication (added libcrypto.a)
• Added a label toggle button in game and removed the reticle label fade.
• Reworked the visual styling of the shootMenu.
• Abandoned scrolling on weaponScrollView because UIScrollView is too buggy.
• Added BlockAttachements.
• Added CANNON_IMPACT and BLOCK_POOF emitter types.
• Tweaked Gravity Bomb effects.
• Removed old levels.
• Fixed a bug where resetCollisionFilters was not being called (killed replay).
• Extended ASGlassButton to handle corners.
• Fixed some ASGlassButton issues that were causing uneccessary redraw.
• Added a biased decal shape as a hack until http://aorensoftware.dyndns.org:8000/TRAC/ticket/145 gets fixed.
• Refined convex sweep tunnel protection even further.
• Added convex sweep querying to block movements as well.
• Added LOCALMODELVIEW so that we don’t stall OpenGL everytime we need to read/update the camera matrix.
• Added more benchmarking oriented functionality and updated libbullet.a.
• Tweaked build settings and switched compilers to llvm-gcc4.2.
• Fixed the editor back into working shape.
• Fixed cull and texture state for projectiles until they get their real objects.
• Fixed big in terrain removal code that was smashing memory.
• Fixed some block label override bugs.
• Fixed key loading.
• Fixed projectile state dirtying.
• Added an in-game fps counter.
• Added server games auditing to the ADMIN_MENU.
• Checks first before copying into history now.
• Misc bug fixes.

Alpha Testing List

Would you like to be one of the awesome alpha testers that help make Cannonade great? Send an email to: [email protected] and I will reply with instructions on how to get onto the Trac server, Testflight list and tester forums.

For the past month or two I have been lightly seeding to Cannonade to testers. I have gotten the strong impression that the “fun” of my game was unfortunately getting lost in the low framerate. There is a certain reaction in the human brain that I am trying to evoke by making the blocks explode and collapse in physically realistic ways. However, when the framerate is too low the perception of motion is lost and so is my core game mechanic. I first spent a lot of time optimizing the execution of the Bullet physics engine and found a significant speed increase by tweaking compiler settings. I found that the execution of the physics simulation on iOS devices was very strongly locked to CPU performance. Now the time had come to start attacking the performance of the graphics engine. I was hopeful that I would be able to find even more significant speedups in this area because the graphics engine was custom written by myself and I could also employ device specific optimizations to take advantage of specific strengths or avoid specific weaknesses. Many of the techniques I tried out were nothing that hasn’t already been done before but I thought it would be worthwhile to document my experiences executing them in my specific situation. These are the results of a week and a half of aggressive performance benchmarking, exploration and experimentation. It goes without saying that my results are very data set specific and so they could perform better, worse or the same when applied to a different iOS app.

(more…)

In evaluating the core fun mechanic of Cannonade, one thing I realized was that a large part of the fun comes from just watching the blocks fall down and fly apart. However, it isn’t enough to have the simulation run and produce natural looking results if the framerate is not high enough to give your brain a good sense of the motion. After seeding Cannonade 0.5.6 and playing a few games with the significantly more complex test castles, it was evident to me that some of the fun was being lost in the low framerate. So I decided to take some time to work on performance now as opposed to further down the road where it usually happens. From the very beginning I knew that the physics performance was going to be a major issue, maybe even the primary bottleneck in Cannonade. I decided to take 2 days to concentrate on nothing but the performance of the bullet physics engine itself. There are many things I could do to lower the amount of work that bullet has to do but ultimately there is always going to be a substantial amount of work that it needs to crunch and so it should be well worth the time to get it to run faster. This is an account of my adventures in this area and my knowledge of the subject at this point.

(more…)