Tuesday, 25 January 2011

Viral - Post Development Analysis

Its 4.44pm on Monday the 24th 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

Thursday, 20 January 2011

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.

Friday, 7 January 2011

So close to release!

It’s been about two months in the making, but Noisy Badger’s first game is on the precipice of release! As I type, Alex is in the process of porting everything onto the mac, from where we will be able to test on actual hardware and iron out any technical niggles. We (I) finally had to pay out for the apple developers license and the unity iOS license yesterday, which amounted to around £400 in total for the year, which, as far as absolute must-have business start-up expenses isn’t so bad.

So I suppose now is the time to give out a little information on the game itself. It’s called “Viral” and it is a kind of strategy/management game. At the beginning of each game the player spends points to develop a virus, and then chooses a major symptom. They are then taken to a 3D world, with the earth’s countries split up into about thirty different regions. They are able to view each region individually, where they will be shown the regions’ ability to fight an infectious virus via a collection of different criteria, including civil unrest, healthcare efficiency, and many others.

The player must then decide which region they have the best chance of launching their virus, with the intention being that they can spread their virus from the first country to the rest of the world, before the regions can respond to the threat and cure it. The player acquires points as they eliminate a certain number of the population (the number hasn’t been finalised yet, it’s a balancing issue) which they can then spend to upgrade their virus to meet different region’s ability to fight back. The game is won when the player has eliminated the world’s human population, or lost when the virus is eliminated globally.

Developing the game has been a lot of fun, but in coming to the end of the development cycle (almost) I think it’s a great time to put some commentary on the ups and downs of its development.

We decided straight from the off that we needed a good idea on which to cut our teeth. We wanted to make a fun, addictive, game, but we knew that being as it was our first time working together on a project such as this there would be plenty of problems when it came down to development pipelines and such.

Financially as well, we needed to get a game out of the door as soon as possible to start generating an income for ourselves. What all this was tantamount to was us choosing to throw ourselves into development with as much enthusiasm as possible, with me designing on the fly as Alex coded everything as I gave it to him. The problem that kept arising with this method of working, however, was that without me having a window of time to purely design before handing over to Alex, silly problems would arise that would cost us extra time.

For example, one of the regions attributes, when affected by the virus, was very obviously meant to provide a negative impact on the region and strengthen the virus’ influence. However whether through poor, rushed communication on my part, or just a straight mix up on Alex’s part, this particular attribute actually had the opposite effect. It wasn’t until long into development that we noticed the error, and while not disastrous it was something that could easily have been avoided.

Coming to the end of this cycle has been amazingly refreshing purely for the fact that this week has entailed very little work on “Viral” for me. Alex has been to focusing on porting it over, which has allowed me to flesh out in the smallest detail the mechanics for the next game. The war room at Noisy Badger HQ is covered in printouts of spread-sheets, going in depth on exactly which entities do what in the game, so when Alex needs to know something, it’s there awaiting him. This allows me to focus on art and asset creation, which will, in turn hopefully offer up a really good looking, visually engaging game.

This has been a good learning experience for me. Whilst what Alex does is as alien to me as what my cat must dream about, I’ve learnt to hone my designs around such coding rules as “object orientated programming”, which make the entire process smoother for us both.

For the game music, I got in touch with a very talented and helpful guy I lived next door to in my first year of uni, Mike Calvert. He very generously let Noisy Badger use a loop from his track “Humidity” as the background soundtrack for the game. Not only that, he was extremely helpful and willing to change any aspect of the track to suit our needs. I really look forward to working with him on future projects, and his portfolio (is it called a portfolio when its music?) can be found here:


And here:


I think that’s about it for this post, hope our readers had a good Christmas and New Year, and here’s to a fantastic 2011.