We’re an indie games studio chasing our collective dream to make a living doing awesome stuff, like creating very fun – and slightly quirky – games and apps for Android, iPhone and your web browser.
We’re currently in the process of developing our first game title, and are learning a lot about how creating games and apps works in the process.
This site is our way of sharing this experience with you. Of course, we’ll also keep you posted about our first game title which we plan to launch in the half of 2011.
If you have any queries, just want to chew the fat a little, or experience problems with our site please contact us at threebirdsone@gmail.com.
We recently had some issues with the efficiency of our game on the iPhone. This was something of a surprise, as our previous test (we actually develop primarily on Windows, thank you Unity) was running at full speed, and there weren’t significant changes between the old fast version, and the new slow version. At first we thought it might have been a problem with putting to many skinned characters in the scene at once, but profiling revealed something else entirely: the slowdown was caused by code that moved some of our characters around (for arguments sake lets call them… zombies). This was very unexpected, we were just using Unity’s built in CharacterController component and had assumed that would do the trick. What could be so expensive about moving a character and making sure it doesn’t intersect with the game world.
Woops.
Turns out that character controllers are not as simple as they seem on the packet (like a few other things I could mention, like follow cameras that don’t suck? Yeah). There’s a lot of stuff going on to make sure your characters behave in the completely unrealistic manner expected in many games. This is what the Unity CharacterController does—provide an out-of-the-box implementation for controlling the motion of characters, mainly targeted at first and third person games. And here’s the part which is not immediately apparent. It doesn’t really play with physics very well. Lets face it, most characters in first person games seem to function completely outside the realm of physics even in their basic motion—they accelerate hard enough to give themselves whiplash, move faster than an Olympic sprinter ALL THE TIME, and stop dead as soon as you let go of the ‘w’ key without even a little wobble. I never really thought about it up until this point.
So the Unity CharacterController does all of this work on it’s own, it functions separately from the physics engine so that it has complete control over the players experience, but it also chews a disproportionate number of cpu cycles going it’s own way. This is perhaps not so noticeable on a PC, or if there are only a couple of these in the scene, but throw a bunch of them onto a mobile and watch your frames drop! We also had a couple of lesser problems as well, for example there are certain quite specific, but still relatively common instances were using colliders with the built in character controller can result in the physics engine tagging the collider as static and optimising it to not move, and then going through the slow process of moving it every time the character moves.
The solution, in our case, was to create a custom character controller which suited our particular needs. Namely it needed to be fast on a mobile and it needed to move characters around the world without letting them go through things. We ended up creating a version which used the physics engine, because it’s already taking care of the seconds requirement for all of the other objects anyway. However, we then had to deal with some of the issues related with using physics based character controllers (or kinematic character controllers). Suffice it to say that our requirements were simple enough that these could be overcome without much hassle and we can now drop a LOT of these guys into the scene without any noticeable slowdown.
Hip-hip-hooray,
Frankie
I’ve recently been doing a bunch of editor scripting for Unity and I’m mightily impressed by the whole process. Editor integration is really tight with Unity. I was pleasantly surprised the other day when I updated a mesh with blender and switched back to Unity to find that it had re-imported it on the fly and patched it INTO MY RUNNING GAME! While this probably isn’t technically advanced to do, I was still rather taken with Unity at that moment. But there was still more awesomeness to come.
Unity allows you to write editor scripts which enhance the existing functionality of the editor, like displaying a custom inspector within the editor for a class I’ve built, or overlaying additional controls and information in the scene view while the game is running in the editor. What really impressed me was the first time I updated one of my C# files containing some editor code to display an overlay on the scene view, and switched back to my running game to find Unity plugging my updated editor script in place of the old one without having to restart the game! Plugging an updated mesh into a running application is one thing, but being able to edit code while the application is running and have my new code compiled and linked seamlessly into running code is something that I’ve never seen before outside of high level scripting languages. Yet it comes with the full power and speed of the CLI behind it.
This reduction of the classic edit-compile-run-debug cycle to just edit-debug is pretty cool and definitely a time saver in getting editor scripts running as you want them – which is generally a primary step in getting some OTHER painful game implementation feature up and running.
As a small caveat, I have noticed that it doesn’t always work. Occasionally you’ll get a null reference exception or some other error, likely because some piece of game data doesn’t quite match a change you made in the script. But in that case you just fall back on the full edit-compile-run-debug cycle and you’re no worse off than when you started.
Cheers, Frank
Some awesome games are being made in Unity for the iPhone these days, one of which is Highborn by Jet Set Games, Inc. (http://jetsetgames.net/). Highborn is like no other turn-based strategy game we’ve played before – the dialogue is actually good – although the back and forth gets a bit much at times. Basically, you play a team of camped up WOW-type characters which you move around on an overhead 2D landscape map. While the majority of the game is in 2D, the battles are animated in 3D. Overall the design is pretty simple, but the game doesn’t take itself too seriously and looks like it was as much fun to make as it is to play. It’s seriously addictive. Oh, and Highborn was shortlisted for three awards at Unite 2010 (Unity’s annual conference) for best mobile game, best gameplay and the Grand Prix award.
I’ve mentioned before that I love Unity right? Well, lately I’ve been trying to create a way to make texture atlases from within Unity so that they plug right into the asset system. I’ve been putting this off for a while, but this week I finally decided to roll up my sleeves and dive into some Unity editor scripting. Initially I was quite impressed, it’s fantastic that you can basically write the same scripts you would write for your game, but for the editor. Unity will compile them and a few seconds later, Hey Presto! There’s a new menu item you can click on to run your editor script. Magic. Then I started to run into problems.
In some ways the Unity documentation is quite good, although it’s far from complete and you’re often left guessing a few things about the functions you’re calling. But, I found the documentation for editor scripting was seriously lacking, or even non-existent in a few cases. There were also no real examples of how things should work together, so you end up fumbling around in the dark trying to work out what sequence you need to call these functions, or why that one is giving you a null reference error.
Which brings me to another gripe, some of the errors Unity logs are great, but for every one which is great there seems to be two which offer almost no explanation, just that something blew up inside Unity somewhere.
In the end these are just teething problems as I get used to the way in which Unity operates. Next time I dive into editor scripting the path will be a little clearer, and a even little clearer the time after that. But, this time? Not so much. It’s frustrating to say the least. I must have created about four different working versions of this texture atlas generation tool which got all the information out correctly, but just not quite in the required format, or which didn’t quite work as I expected, requiring me to hazard a few guesses to what’s not working, sleep on it to come up with a new way of doing it, and trying again.
Unity is still an amazing piece of software, I just can’t wait until I understand it’s ins, it’s outs, and it’s quirks.
Peace, Frank
So Unity 3.2 was released this month and comes with a bunch of sugar-coated goodness! It’s got a bunch of optimisations, including shader optimisations. It also comes with a whole lot of fixes which is great, although I have to admit that I didn’t even know most of those bugs existed. It’s fantastic to see Unity Android coming along too. We’ll be making extensive use of that in the future, so it’s great to see it maturing before our very eyes. Basically this looks to be a really solid all round update, with enough improvements to keep up excitement and a feel of momentum, and enough bug fixes to reassure everyone that Unity isn’t about to become a tower of Swiss cheese.
Mmmmm, cheese.
But alas, probably my most desired feature is STILL missing: complete support for the Boo language across all targets. Boo is currently unsupported on mobile targets for reasons I’ve never been able to work out (since Javascript works on everything, and it’s a pretty nasty language in terms of dynamic typing, which seems to have something to do with Boo not being supported). I come from a systems language background, so I’m perfectly comfortable programming in C#, but I’d jump ship to Boo in a heartbeat if it was supported on all targets.
I could go on about how awesome Boo is for someone who grew up on systems programming languages, but I won’t for fear of boring your pants off.
Check out this exciting Lifehacker post about mobile app development. The stats are quite interesting, showing extremely strong growth in app and game development across mobile platforms. Apple’s 182% growth is nothing to smirk at, but it’s nowhere near the top. Android is beginning to take its place alongside the iPhone. I think this is awesome – and not simply because I personally love the Android platform (what can I say, I’m a developer), but also because competition can really spark innovation. I don’t believe we’ll see an ‘iPhone killer’ any time soon and having a number of healthy competitors out there will only drive further innovation in games development.
Basically, I love how fast smart phones are developing and it’s pretty exciting to be creating games for them. Awesome, in fact.
Bye for now, Frank
We love comics here at ThreeBirdsOne, so when Ultimate Spiderman Total Mayhem became available on our iPhones and iPods we embraced our nerdiness and bought it. It’s awesome. The opening sequence tells the back story using graphic art – which is really well done – without taking too long. The voice acting is actually pretty good. It’s hammed up in homage to its superhero comic-book roots.
To play the game you use your left thumb on an on-screen joystick in the corner to direct your character and your right thumb to punch, jump and throw web around a 3D city environment. It has a nice ‘n easily learning curve with an intuitive interface. You can access special attacks, skill upgrades and super spidey-sense manoeuvres at any time. These help you get out of tight corners in boss fights pretty easily. The fact that the game pulls this all off well on a smart-phone screen is impressive.
We’re really interested in what others think about this game and how it plays – especially in relation to the on-screen joystick and the 3D environment – so please let us know your thoughts if you’ve had a go playing Ultimate Spiderman Total Mayhem.
Welcome! I’m Frank, the lead developer for ThreeBirdsOne.
Starting out in this biz has been a little bit crazy, a lot of work and loads of fun. I’m going to be close-lipped about our first title because I’m not the marketing guru, but I’m sure it’ll be as fun to play is it is to make!
In terms of technology, we’ll be developing for mobiles – iPhone and Android specifically. I have recently fallen madly in love with Unity 3D as it allows us to focus on game design, art, code and story without agonising about the tech we’ll be running on. It’s awesome.
Stay tuned for further entries about all things development, our experiences as industry newbies and updates about our titles, events and business adventures. Oh, and please excuse the naked state of our website. It’s undergoing some heavy cosmetic surgery so if the formatting is ever off, or things aren’t available, please forgive us and know that we’re working to sort it out ASAP.
