Much love to Indy Hall

The fact of the matter is if it weren’t for Indy Hall, Jake and I wouldn’t have met, been inspired to collaborate on a project, or better yet, start a company together.

If it weren’t for Indy Hall I just may be stuck in a 9-5 gasping for air during lunch hour and holding my breath for the end of the day.

Thanks to Indy Hall, I can breathe easy knowing Jake and I are in pursuit of something special.

Do yourself a favor and read this article. Jason Fagone is one hell of a writer and I think this article really touches on some great aspects of life at the Hall.

Article is on the other side of this link.

  • Twitter
  • Facebook
  • Digg
  • Reddit

Newfound Love: Digital Painting

I’ve been busy over the past couple weeks with contracting and I’m FINALLY heads down, working on concept art for our relaunch of Brainarang (new title TBD). In the process of exploring the many different directions I could take the art for the new game, I happened upon some extremely talented digital artists who’ve really inspired me to evolve as an artist.

First and foremost is Rich Werner who, if you knew just one thing he’s done, it’s Plants vs. Zombies. No big deal. Just kidding it’s a big deal. His blog is an amazing source of inspiration for me and if I ever realize the amount of talent that man wields in just his pinky finger, I’ll do just fine in this industry. In the process of trying to reverse engineer some of the techniques I see him employ in his paintings, I found myself hitting a few walls.

Enter Matt Kohr. Matt is a freelance concept artist/illustrator/digital painter/educator extraordinaire. He’s put together a foundational series of instructional videos for digital drawing and painting in photoshop that is nothing short of incredible. If you have ANY interest whatsoever in learning these crafts, head on over to ctrl+Paint and have fun. I know I am.

So, all that said, here’s the first sample of the concept art for the new game. He’s an Old School English Big Game Hunter.

English Big Game Hunter

Here's my first go at digital painting.

  • Twitter
  • Facebook
  • Digg
  • Reddit

Battle of the iOS Physics Engines

Box2D vs. PhysX. In many ways, this is a ridiculous matchup. An open-source 2D physics engine vs. Nvidia’s proprietary 3D physics engine. Why even compare them? Because, if you’re shopping for an iOS game engine, these two are your likely choices. Box2D comes with cocos2d and Corona. PhysX comes with Unity and Unreal. And, even if you’re making a 2D game, Unity has enough advantages to make it a tempting choice, even though its a 3D engine.

We chose Unity for our current 2D project, and you can read bout how we tricked it into doing 2D here. But we are making a physics-heavy game, and now are realizing that the game’s performance is physics-bottlenecked. After optimizing as much as we could in Unity, the game is chugging along at a pretty inconsistent 30 fps on an iPhone 4. We had to look into alternatives, and so I decided to benchmark the two engines. So, pick who you’re rooting for and let’s get these fuckers in the ring.

Um, Methodology, I Guess

The main goal of the this was to see which engine could handle the most rigidbodies without the frame rate dipping below 30fps. Each test consisted of increasing numbers of 1 by 3 meter rectangles, identical in mass, falling with lots of collisions. In both tests, all blocks were one batched draw call so that impact on performance by rendering would be minimal. The fps was averaged over each 10 second test. This was done on a first gen iPad.

Here is a summary of the respective settings.

Unity/PhysX cocos2d/Box2D
Version Unity v3.4.0f5 Box2D v2.1.2
Solver Iterations 7 7 velocity, 7 position
Fixed Timestep 0.02 s 0.02 s
Max Timestep 0.333 s 0.333 s
Interpolation None None
Continuous Physics No No
Code Optimization Fast, but no exceptions (Unity) -Os (fastest, smallest) (Xcode)
Compile for thumb No No
Friction 0.3 0.3

 

Results

Box2D smoked PhysX. It could handle roughly twice as many rigidbodies at the same frame rate. Let me say that this is not meant to be a criticism of PhysX. I don’t know how much processing power you’re throwing away making a 3d engine do 2d physics, but apparently it’s significant. I’m sure PhysX is highly optimized, just not for 2d.

Optimizing

Compiler optimization was very important. PhysX was wildly outperforming Box2d before I realized I was running in debug and changed the optimization level in the Box2d Xcode project from -O0 to -Os. PhysX did not see a performance increase from making this change on Xcode, since Unity does its own static compiling.

I was hoping that tinkering with solver counts and timesteps would milk a good amount of performance out of the engines, but the changes were small. Strangley, PhysX’s performance was affected more by reducing the solver count, while Box2D’s responded more to increasing the timestep.

I have found that being pretty aggressive with reducing the max allowed timestep can be very helpful. Especially if you have infrequent spikes of physics-heavy processing.

 

Unhappy Conclusion

This was not the result I was hoping for. Developing in Unity has been quick. Putting together this test took 3 times as long in cocos2d as it did in Unity. Porting three months of work to cocos2d, and losing all the the cross-platform goodness in the meantime makes my kidneys hurt. Maybe it’s time for some whiteboarding…

  • Twitter
  • Facebook
  • Digg
  • Reddit

2D in Unity, or Hobbling a Giant

Our last game, Brainarang, was built using cocos2d, which is an awesome open-source 2D game engine for iOS. As happy as we were with it, we couldn’t resist the siren song of Unity. Unity is AMAZING. If you don’t know about it and are interested in game development, stop reading this and go bend your knee in fealty right now.

But for all its godlike virtue, Unity is still a 3D game engine (yes, I just compared Unity to a giant, a beautiful woman, a king and a deity in, like, 15 seconds. Love is a powerful thing.), so you have to do a little monkeying to do 2D. Below is a compilation of what I’ve learned for handling this, not only from Unity and my own experience, but from the use of third-party tools and from the awesome community of developers sharing what they’ve learned (see Props below).

Orthographic vs Perspective Camera

Orthographic is the easy choice for 2D games. With the orthographic camera, objects further away from the camera don’t reduce in size as they do in perspective. It essentially flattens the world, which makes sense for a 2D game. This makes positioning super simple. You can use z position for simple z-ordering, and any object with same x and y position will always be the same place on the screen. Also, because objects will always be the same size, pixel-perfect textures are easier to deal with (see Textures, below).

Perspective vs Orthographic

One reason you may want to use perspective instead is that you can get parallax scrolling without writing code, since objects in the distance will scroll more slowly than those in the foreground. If you choose to do this, Sprite Manager 2 has a pixel-perfect option that will automatically resize textures, although this runtime resizing can make manipulating objects in your scene confusing.

Also, there is a depth sorting issue when using perspective that can lead to objects appearing closer than objects in front of them. If you have this issue, checkout this video (halfway into Part 1) from Owlchemy Labs, who explain and have a solution for the problem.

I prefer using orthographic and write my own parallax code, but there are arguments for each method. Here is a forum thread that goes a little deeper on the issue.

Textures

Unless your game scales sprites or does zooming, you will probably want pixel-perfect textures, meaning textures that are rendered on screen at their native size. In 3D games, textures are resized constantly as they move closer or diminish in the distance. Unity, by default, imports textures with some optimizations for this. You should disable these for crisper textures. In the inspector, choose Filtering: Point, select Texture Type: Advanced and disable Generate Mip Maps.

Texture Settings

In order to size your meshes so they display textures pixel-perfect, you need to figure out the ratio of pixels to world units. This is based on orthographic size of your camera and the resolution of the screen. The size of the camera will be half the height, in world units, of the screen. So, if you have a camera size of 10, the world unit height of your screen will be 20. If your game pixel resolution is 480×320, each world unit will be equal to 320/20 = 16 pixels. You might be tempted to change the ortho size so that there is a one-to-one ratio. This might be ok if you aren’t using physics, but not if you are. The physics engine is tuned so that objects will behave most realistically when each world unit is equal to a meter in game.

Once you have determined this ratio, it can be tedious to resize all your meshes. Don’t soil your pretty little pants about it, Owlchemy Labs has a script to resize automatically and Sprite Manager 2 has a pixel-perfect option that will do this as well.

Remember to size the mesh itself, don’t change the scale in the transform component, otherwise you won’t be able to take most advantage of draw call batching. See Meshes and Batching Draw Calls below for details.

Another thing to consider is compression. You can select from three compression levels for each texture. For iOS, the tightest compression is PVRTC. These are very small memory-wise, but can be pretty crappy-looking for 2D games, especially with gradients and alpha edges.You have to weigh quality against performance here.

Meshes

You generally only need one type of mesh primitive in 2D games: a quad. Unity ships with a plane primitive but it has way too many triangles. You only need two. You can either create your own quad in a 3D modeling program or in code. Or Sprite Manager 2 creates them automatically.

Plane vs. Quad

Draw Call Batching

One of the most important things you can do for performance is to batch your draw calls as much as possible. There are two main ways to do this in Unity. The best and easiest way is static batching, but it has some limitations: it’s only available in Unity Pro, it can only be used on game objects that will not move, scale or rotate, and only objects that share the same material will be batched.Check the static flag at the top of the inspector of any game object to enable this.

The second is dynamic batching. This is done automatically for any objects that share the same material. It allows objects to move and rotate, but NOT scale. All objects to be batched must have identical scales. This is not well documented and took me a while to realize. It is why it is so important to resize meshes themselves instead of scaling with the transform. If you are using Sprite Manager 2, setting the sprite size is safe for batching.

Because of the need to share materials to achieve batching, and because there is only one texture per material, using sprite sheets becomes very important. Also, be aware that many manipulations of an object’s material in code will actually make a local copy of the material and destroy batching for that object. You can manipulate the shared material, but this will change the material for all objects.

Unity docs on batching

Use Statistics to Show Batched Draw Calls

Sprite Sheets

Use them! Packing multiple images onto one texture atlas helps performance in several ways. It cuts down on memory use and app size, and more importantly, it allows different sprites to share a material and thus a draw call. You can definitely roll your own solution for this, or (brace yourself) you can just use Sprite Manager 2.

A Sprite Sheet

Lighting and Shaders

Lighting is not needed for 2D games and it is expensive, especially for mobile games. Don’t put light sources in your scene. All of the shaders that ship with Unity use lighting and will cause unneeded processing. Owlchemy Labs has a pack of simple, unlit shaders available on their site for free. They’re the only ones you’ll need.

Physics

It’s super easy to set up physics for 2D. Just set the constraints on each of your rigidbodies to disallow z movement and x and y rotation. Then just leave your colliders with some depth, and you’re done! You just made the next Angry Birds.

Rigidbody Constraints

Tools

Sprite Manager 2

We use Sprite Manager 2, and it has been ridiculously helpful. It helps or solves many of the issues I’ve talked about here, and that is really just an awesome by-product of its main purpose, which is to be a very nice sprite frame animation tool. Currently its $150 on the Unity Asset Store. Its more basic ancestor, Sprite Manager, is free. My only criticism of it is that it sometimes doesn’t lay out atlases optimally, but I’m guessing that’s a difficult problem.

iTween

iTween is free animation tool for Unity with lots of coded-up examples for sale for a buck a pop.

Rage Spline

Rage Spline is a crazy looking unity tool that allows in-editor vector-style drawing of objects, including creation of meshes and colliders.

Props

If it seems like I’ve mentioned Sprite Manager 2 and Owlchemy Labs a lot, it’s because you’re paying attention. I’ve learned a lot and gotten a lot of utility from both. I definitely recommend checking them out, including Owlchemy Labs amazing game Snuggle Truck.

I hope this helps someone out there. Make it good and make it flat.

  • Twitter
  • Facebook
  • Digg
  • Reddit

Here’s to you, Dan Paladin.

Jake and I are in the thick of it right now.

He’s busy implementing all the systems the game needs to run so we can begin play testing and I… I’m busy making pretty pictures.

That said, some of these pretty pictures need to move. Not so easy. I decided to take a moment out of my tutorial reading the other day to find some inspiration and possibly some direction in my effort to learn Flash.

Enter Dan Paladin.

Castle Crashers (probably Paladin’s most famous work) was an early source of inspiration for me to make games, even though I wasn’t quite aware of it at the time. I just remember vaguely thinking that as much hard work as it must have taken to make, it at least seemed somehow possible as opposed to say, making the latest Call of Duty. Now The Behemoth and studios like them (not that there are, i just meant… shut up) maintain a sort of heroic status in the eyes of indie game developers across the world.

Anyway, I just wanted to take a moment to share that animation is hard. Like really hard. For our placeholder animations in the game I just drew a character in photoshop, opened them in illustrator, broke them into symbols, brought em into flash, and hacked together an animation. Good enough for play testing but not at all good enough for a finished product. After watching this video, I see now what is actually happening behind the scenes of Paladin’s masterful work. He’s actually drawing the symbols right in flash and when they need tailoring, he redraws them. Duh! That’s how he avoids this debacle:

 

Failed Lines on Rilla Animation

So I’m off now to learn the ways of the animator and hopefully one day some aspiring dope will write an article about my work and title it: Here’s to you, Parker Whitney.

  • Twitter
  • Facebook
  • Digg
  • Reddit