Viral - Post Development Analysis

Its 4.44pm on Monday the 24^th of January, and Noisy Badger is bang on target for submitting its first game at 6pm. Excitement doesn’t cover it.

With Alex finalising some last minute tweaks I’m going to take a chance to go over some of the more obvious development peaks and troughs I encountered on the design side of things, in a similar way to Alex’s last post.

POLY COUNT. I have no idea what I was thinking on my first build of the earth in this game, but I ended up spending possibly two weeks building a detailed, 3d map of the earth, following the outline of the countries as accurately as possible. I then bevelled the edges of each of the countries to provide a nice little “groove” where all the borders met, further upping the poly count. It ended up containing about 80,000 polygons, the on-screen limit for an iPhone being 10,000.

So to break it down financially, as a self-employed/freelancer type, a general rule of thumb when you’re starting out is to charge around £25 an hour for your services. If I apply that figure to the ten working days I spent on this world map, working eight hours a day, I basically cost Noisy Badger £2000 through my own idiocy. And that figure doesn’t take into account the other work that I could have been getting done in that time, or a multitude of other factors that I really don’t want to think of. That’s the first time I’ve worked out that figure, and I just told Alex. He shot me a look that said “I’m not angry, I’m just disappointed.”

It’s not realistically that much of a financial disaster obviously, but it goes to show how easy it is to mess up. We knew this being our first release that there would be plenty of errors as we tried as fast as we could to establish good communication between ourselves, learning new tools, and getting our development pipelines in order. I’d still say that we’re not bang on in any of these areas, and I don’t think that anyone ever could be. It’s a constantly changing industry and as such our flexibility to adapt to anything new that comes our way is the greatest asset we have, not necessarily an intricate knowledge of every new piece of software that comes our way.

Edit – The game has now been uploaded to the app store and is awaiting apple’s quality assurance stuff. I’m currently wearing out my blackberry from constantly checking to see if it’s been ok’d J

Lessons Learned

Well, we're pretty much wrapping up the first game now, fixing the last of the bugs and wading through Apple's release guidelines. I've experienced a lot of silly timewasting bugs/issues over the last few weeks which I could've easily avoided with a bit of prior knowledge; so with this in mind I've decided to talk about some stuff which might help out anyone who may be in a similar situation.

This discussion is specifically aimed at people developing for iOS with Unity.

The first item I want to bring up is textures, the only textures required in our game were GUI textures so with that in mind we created them exactly to size and imported them as GUI in Unity. The problem with this was that even though they were switched to 16 bit, they were taking up a massive amount of memory on the iPhone. This was made even worse by the fact that we designed the GUI for the 4th gen devices, so the full screen textures were 960x640, and we had a lot of full screen textures.
The solution to this problem was to simply reuse a couple of the full screen textures for backgrounds and then convert the overlying textures into powers of two so they could benefit from PVRTC compression. We were able to reduce our total texture size from around 50mb to 12mb, a much more acceptable number.

The second major issue we had was with meshes, luckily we managed to catch this quite early on in the development process so it turned out to not be such a major problem. The problem we had was that we had no idea what the constraints of the iPhone hardware was in terms of polygon processing, this information is actually available in the Unity help files but for some reason I hadn't been able to find it. To cut a long story short, Olly went a bit wild on the poly count and we ended up with around 70-80k polys on screen at any one time. This turned out to be about 70k more than was recommended so with some hasty remodelling we have a very safe poly count of around 3-4k on screen at any one time, this falls well within the recommended 10k. Once again this is a perfect example of where some prior research would have been really beneficial, as it is also clearly written in the Unity help!

Another issue we had to contend with was the resolution difference between the 4th gen devices and the older devices. The resolution of the new devices is 960x640 and as I mentioned earlier, we designed all our textures with this in mind. Fairly obviously this meant that I had to design the GUI elements to dynamically change based on the resolution, well I say fairly obviously, it clearly wasn't to me when I started. I decided initially to have two functions, one called DisplayHighResUI() and the other DisplayLowResUI(), I worked on this for a while before I realised that instead of declaring ExampleElement = 100; in the high res UI and ExampleElement = 50; in the low res UI; I could just work out the position based on the resolution. So in the previous example, ExampleElement = 100; could actually be ExampleElement = Screen.width * (100/960), or more simply just Screen.width * 0.1042.
This should have been obvious to me but it just shows how a lack of forethought can cause you to rush and then spend time repairing problems.

There were other issues we had involving game balance, particularly the time the game took to complete and the speed which the user had to react to events. These were quite specific problems though so I won't go into them here.

From my experience with developing our first game, I've compiled a top ten tips list for developing a game for iOS with unity:

1. Plan - try and think of every problem you're going to encounter, you won't get them all but it will certainly help.
2. Watch the size and use of your textures - try and get as many compressed to PVRTC as you can.
3. Don't use too many polys in your models - 10k max on screen at any one time.
4. Compress your sounds - I compressed our backing track from 1.4mb to 800kb with no noticeable loss of quality.
5. Be object oriented - don't have enormous long classes, split them into smaller self contained classes.
6. Be careful with OnGUI() - this function can get called multiple times per frame, so put as few calculations in here as possible. One bad example of this is updating a scrolling GUI element in here, it'll move faster and get called more often than necessary.
7. Don't put everything in one class - I had a good example of this, I had a game class where the game logic was updated in Update() and the GUI was drawn in OnGUI(). This wasn't a good idea because the script file was huge, the update function also became extremely confusing as it was updating elements for both the game and the GUI. I solved this by creating a new class for the GUI and moved all the UI functions over to it leaving the game logic class much tidier.
8. Pick a language at the start - I decided to go with javascript as most of the help examples I could find online were in java. Coming from a C++ background this was a bad choice and I wished halfway through that I'd gone with C#. My advice is go with what you know best.
9. Watch javascript's dynamic casting - if you choose to use javascript, watch out for this one. iOS doesn't support it, so all your variables have to be statically typed: i.e. var x = 10; will work normally but on iOS you are required to put var x : int = 10; This nearly caught me out when passing variables in functions, the function definition must also include a type: function PassStuff( valueToPass ); won't work, you need: function PassStuff( valueToPass : type );
10. Use the unity help - it's an invaluable tool and is extremely useful so don't neglect it.
    

What are we using?

With the company's purchase of a Mac yesterday, I thought it might be of interest to some people to briefly outline the technology we're using.

On the coding side I'm using a PC built around the AMD Athlon64 X2 5600 (~2.8GHz) processor, 4GB DDR2 RAM and an nVidia GeForce 8800GTS graphics card.

I built it mid-2007 and its definitely starting to show it's age now. Having said that, it still performs well on code compilation and doesn't slow me down in any development work I'm doing. Unfortunately it does mean that playing the latest releases at a decent framerate is difficult.

Oliver doesn't suffer from framerate performance with new games because he took the phrase 'future-proof' and ran with it when building his PC last year. He built it (well he bought the parts and I built it, because he is technologically inferior to me) around an Intel I5 quad core (~2.4GHz) processor, 4GB DDR2 RAM and an nVidia Geforce GTX 295 graphics card. He uses this mighty machine for various design tasks, from 3D modelling to image manipulation.

Our newest addition to the family is a PowerMac, this had to be bought as Apple's iPhone SDK can only be run on an Apple. Well, there are ways to emulate a Mac on a PC but it requires an Intel processor, which I don't have, and a lot of messing around which I quite frankly couldn't be bothered with. The end result would also run a lot slower than on actual Apple hardware so the decision was made to bite the bullet and buy one.

The machine is a PowerMac G5 with a 2GHz dual core processor, 2GB RAM (considering upping to 4) and an ATI Radeon 9600 graphics card. It's quite an old machine, but we considered the merits of buying a brand new one and we simply don't need the extra speed. The iPhone/iPad hardware is still inferior to the Mac we bought, so we won't have a problem with the iPhone simulator running slowly.

You now have an insight into the hardware that we're working with, in future posts I'll discuss the many software packages we use. I'll also keep you updated with any programming related news while Oliver keeps you up to date on the design side.

Hello World :D

Ok so with Noisy Badger, mine and my business partner Alex's new games development studio being well into the setup period, I figured it was about time to start putting together some form of web presence. Obviously we'll have a full on website in the near future but in the meantime I'm going to keep anyone who may be interested in us informed via this blog.

So, what is the Noisy Badger? We started out while still at uni, doing freelance work that wasn't necessarily games, but allowed Alex and I to use our relevant skills and get a taste for the business side of things. We both did computer games relevant degrees, me on the design side of things, he on the coding, and we decided that putting together our own studio would really make sense.

Our studio is going to initially make games for the iPod touch, iPhone and iPad, and so since graduating we've been hard at work developing games design documents, business plans, and we've even got a functioning engine ready to go. We're now looking towards sourcing some start up capital, which is proving to be a bit of a nightmare. In our business a large part of any investment we'll be asking for will go on our salaries, as we have pretty much everything we need to start work, except for a means to live while we develop our first game. We've only actually set ourselves the minimum wage for this, but its still unappealing to investors.

The princes trust would have been ideal in this situation, but I got an email from them saying that as we are graduates, we have to wait at least 6 months from the date of our graduation before they can help us. You read that right, our degrees are actually hindering us. Idiots.

Anyway, rant over. As you can tell, this blog is going to be pretty casual, i'm not going to fill it with hyperbole on how awesome we are (we are pretty awesome though) but just try to provide an insight into Noisy Badger as a studio. I intend to update weekly, and please get in touch with your questions, comments, insults, whatever.

Follow me on twitter- http://twitter.com/#!/themightyodog

And follow alex too- http://twitter.com/#!/Amlach

Righty then, I'm off to write up a competitor comparison analysis. The FUN. It never ends.