Paper Streetball - iOS 2D physics hoop throwing game

Hi Unity3D peeps!

Just wanted to showcase a game we made with Unity iOS, it just released today on the app store.

We're throwing a giveaway party right now at our Facebook and Twitter pages, so join in on the fun! You can win if you follow us on Twitter and tweet "@VAVAinteractive I want Paper Streetball!", or if you like our Facebook page and comment on one of the Paper Streetball wall posts.

But what I really want to talk about here is what happened behind the curtains.

• Farseer Physics 3.1
• Sprite Manager 2
• Openfeint plugin

The Farseer 3.1 version did have a bug when the ball just didn't bounce every now and then and we had to use Farseer 3.1 because I coudn't compile 3.2 using Unity's Mono. Conclusion: Using Box2D next time.

Sprite Manager 2 was a lot of help with sprite atlases, but proved to be a giant pain in the ass for this game's scenario (maybe if I had sprite animations it would have been more helpful) Mixing depth of various sprite sheets just doesn't work (or isn't very well explained in the docs). Constant rebuilding of sprite sheets just blew my brains out. Conclusion: Using my own solution for sprite atlases when I don't need sprite animations.

Openfeint worked Just took a while to build every time, but I guess I can't complain about that..

 

Eheheh everybody is using Apple's garage band loop lastly...

 

Curious on your choice of physics engine. I believe farseer is based on box2dlite. In my tests, a c# port of box2d was slower than using unities built in physx system constrained to 2 dimensions.

 

Why even bother with sprite atlases though? you couldn't slow that game down if you tried

As for physx, I am curious what exactly was broken, could you elaborate on that? I don't know why it wasn't used as it is fantastic on ios and in 2D if you constrain.

Finally, congratulations on the game!

 

Yes You can use constraints , then you got the same results for 2D physics .

 

Thanks, we really wanted to try a 2D physics engine for once and Farseer was a bad choice. I think a box2d C# port would to far better. Not that anything's broken with Physx, we just though it would be better with a pure 2D engine.

Sure is. That was a mistake not using Physx. But when you're starting a new game you have all these wonderful ideas about a physically correct net and springs on that hoop. As time went on we dropped those one by one to the point where Physx was a better solution.

Also we have to disable the trash flying by on 3G, it does slow the game. We're doing an update this week.

Well kinda, but you have a tougher time doing your own custom shapes. In Physx we would have to model a mesh or manually set vertices and indices, but in Farseer we just wrote a couple of lines in code. Also Farseer has bunch of features like cutting shapes (Fruit Ninja style).

 

Probably, the slowdowns are due to the shaders used on the graphics and/or fillrate, You can't be doing more than 10 drawcalls and you can do 20 on an old legacy device without hitting issues at 60fps (my old game does this with plenty of full-screen nonsense).

I think its very strange that you hit a slowdown issue from draw calls. Because when that happens, it indicates a high CPU load, not a high GPU load. As draw calls are handled on the CPU.

Therefore it is something dodgy you are doing in code most likely thats falsely leading you to believe the slowdown is fixed by atlasing. It is speeding up your cpu operations a bit but being that close to the wall is severely limiting your ambitions for future titles. If you can, I would advise you to profile it properly to judge where it is if you have not already. Just trying to to be helpful as I strongly disagree with you that draw calls is an issue for this title's framerate.

You may be trying something else like textures that are really big for the display size without mipmapping or some other issue. But drawcall frame rate issues are generally down to CPU being overloaded.

 

I have to agree with hippocoder, I've put together a few little physics projects recently. 2d physics alpha planes (see topic in this thread). In performance tests I was able to maintain 60fps on 3GS with 2x antialiasing and 60 FPS on retina devices (no AA). That's with 30+ objects bouncing, bumping, etc. Also includes moving platforms, and the fairly costly routine that looks for similar coloured blocks that are close and (almost) stationary relative to each other.

But in the end you got your results which is all that matters, good for you

 

No no, I think you misunderstood. The physics of the trash flying by and bouncing is the likely culprit for the slowdows, because frame rate drops only and only when there's trash on the screen. And that's on 3G (not 3GS) devices with Farseer. Draw calls are well under 10.

That's Unity Physx or a 2D physics library? Also retina devices should be faster than 3GS, right?

 

Unity Physics with constraints.

4G is slower than 3GS with AA on* because there are so many more pixels on the retina screen (but you don't need the AA so it works out faster).

* Obviously an oversimplification, for me I could get an average processing time of 16.8-16.9 ms per frame on 3GS with 2xAA, on 4G touch it was blown out to 25ms with 2xAA on.

 

Seems like 2D or 3D physics, Unity's built in is the way to go. Everything else is just too slow.