Where be we

Just a general update today, as I was reminded that it’s been a while since our last post.

So, where are we at.

Well after the rip roaring success (HA) of Viral, we have since released a “lite” version of that game which has been doing ok, around the average we could expect.

We also released Bloove, which in three days eclipsed all our other downloads combined, the current tally of which stands at 879. I’d be happy about this but we released it for free under the “ad supported” pricing model, so our revenue from that is so diminutive that it challenges Alex’s height for smallness.

I’m obviously not serious. Included in Bloove is adverts for Viral and Moojooce, and the fact that 879 people have taken the time to download something that we created is amazing. We are getting as much feedback as we can then we may consider doing a much more in depth sequel, which we’d probably retail for either 59p or £1.20

Back to more current affairs and we are just tying up the loose ends on Moojooce. We’re going to submit it to the app store tomorrow evening, but this time we’re dictating the release date. This is tricky, as apple’s vetting process seems to be performed by the least drunk chimp they can find on the day, and as such it is impossible to accurately predict when the app will reach the store. For example, Viral went through in seven days, whilst Viral Lite, which was released after its mother game and was the exact same game but stopped play after 12 in-game hours, took THIRTEEN DAYS.

So we’re going to gamble, and set Moojooce’s release day for a week on Friday (11/03/11) this way we can set about promoting it with an actual release date, and hopefully garner some hype around the product.

I’m genuinely more proud of Moojooce than anything else we’ve done so far. The art in the game looks extremely characterized, professional and individual, and was obviously created by an extremely handsome man among men. It is addictive to play, whilst being simple enough to be played by all ages.

Hot on the heels of Moojooce will be Moojooce lite, obviously free, and Moojooce arcade, which will be a paid for game, and take the core mechanics of the original game, but differentiate enough to provide a good deal of value for money for the player. Honest.

Next up after that is a secret game, which you can’t know about. So instead I’m going to mention some keywords that might give us a higher viewing from people accidentally stumbling on our awesome blog, and a picture of my cat. Skyrim GDC Sonic Mario Nintendo xbox PS3 Justinbieber.

The joys of iAds

Our lite version of Viral is out and downloadable on the App store, finally. It took 14 days to approve, we've no idea why but nevermind because all is now well.

Or we thought so anyway, the keen edge of the learning curve struck me again as I realised that none of our ads were displaying. The reason for this was of course that I hadn't added support for them in our Unity project. Naively I thought that Apple would handle all the displaying of ads and effectively just overlay them onto our game, this is not the case.

I quickly went online and tried to see how to code them into a Unity project. I couldn't really find any clear explanations but I did find a link to a company's site which sold plugins for Unity, one of those plugins was for iAd support. I weighed up the cost of buying the plugin vs my time in learning how to do it. The plugin won hands down so we bought it, installed it and now our iAds are working perfectly. I highly recommend it, the company is Prime31.

We've submitted the new version of Viral Lite and are as ever, waiting on Apple :)

In the meantime, check out the current version of Viral Lite on the app store ->
http://itunes.apple.com/gb/app/viral-lite/id418329387?mt=8

In other news, we've submitted our next game to Apple. Its called Bloove and there will be more details coming soon on here when it gets approved!

Noisy Badger Not Noisy Enough

After releasing Viral a few weeks ago now, poor sales have forced a new approach to how we make, release, and promote our games.

The excitement of having created and actually put out there a game of our own was quickly eroded by what we saw as much less than adequate sales. I’m not going to go into specific numbers exactly, but day one sales were only 25% of what were projected. Drop off in sales per day was, ironically enough, exactly as I had projected in our business plan, so at least I was right on that, but without that initial starting volume, Viral as a product was making nowhere near enough money.

So the Noisy Badger hive mind (Alex and I) held crisis talks. It was more than evident that we had done not nearly enough promotion for the project, so that was our starting point. I arranged an online targeted search, keyword relevant marketing campaign, which simply means that if anyone googled relevant search terms that I had chosen, an advert for Viral would show up alongside the search results. From this we achieved a click through rate of around 5%, which is a fantastic result as the best a campaign can usually achieve is 2%. However, it affected our sales in no way whatsoever.

Our second component of the marketing campaign was to give out press releases to as many sites as we could, which then got reposted on other blogs all over the world, which gave us some expansive coverage but only within the core gaming community.

Thirdly, we created a “lite” version of the game. Results from the success of this facet of the campaign are yet to be seen however as after a thirteen day wait, apple still have not processed the app. I’ve emailed to ask what’s going on, but am yet to receive a reply.

Finally, I sent a number of free codes with a nice letter to a number of review sites, however with such a large volume of games being submitted for review the chances of ours getting picked for review are slim.

Not to be disheartened, We began work on two more games immediately, one of which is complete and has been submitted, the second we are in the process of wrapping up currently.

The first game, Bloove, is a simple puzzle game, the core mechanic of which centres around tilting the iOS device to move rectangular blocks around a board in order to slide them into randomly spawning catches.

However, we realised early in development that this title was not strong enough to justify charging even the minimum we could on the app store (59p) and were going to forget the project, when we realised we could still benefit from it by finishing it and releasing it for free, with ad support. My personal thinking on any sort of ad support in games is pretty simple, if I paid for it I don’t want to see ads, but if I get something for free in return for seeing an advertisers’ logo or whatever I’m happy.

Assuming my thinking is similar to most peoples, I was ok with the structure of release, as was Alex. We also put in two of our own adverts at the start of the game as splash screens, which show an advert for Viral, and our upcoming release, MooJooce!

Here’s the ads-

So we await the results of this latest endeavour. Suppose I should talk a little about MooJooce!

MooJooce (it does have an exclamation mark at the end of the title but I’m sick of typing and the word following the exclamation mark autocorrecting! To! Have! A! Capital! Letter! At! The! Beginning) Is a puzzle game in which the player is charged with correctly putting the right colour lids onto bottles of milk as they come off a production line. The challenge lies in the fact that they have to match together three of the same lidded bottles each time to progress, by lining up the bottles correctly in front of three conveyor belts which randomly generate different coloured lids.

AAAAND breathe. Ok it honestly makes sense in game, and its a hell of a lot simpler than I’ve made it sound there, buy it, you’ll see :D. Really should clean up that description before I start sending out press releases.

That’s all for this post people, think the next one I’ll do will be on the dramatic shift between job roles that happens post release, from Games Designer to Marketing Executive.

Cheers,

Olly

Viral is released!

Our first app, Viral, has been released and is for sale on the app store now!

Have a look -> http://itunes.apple.com/us/app/viral/id416581114?mt=8

So what have we been upto since we released?

Well, we've begun work on a new game, it's a 3D block based puzzler which makes extensive use of the Unity physics system. With the lessons we've learned from our last game, the production process on this one is proving to be much smoother and faster. We hope to be ready for submission by Friday next week at the very latest.

As well as our new project, I've spent some time creating a lite version of Viral, this will be a free app which places restrictions on the user, the main one being limiting their playtime to 12 game-hours. They will also be unable to save/load or access their highscores and there will be iAds included.

We hope this free app will boost the sales of the full version of Viral and also provide us with some much needed publicity.

More information coming up on our new game so keep checking back!

If you are a games reviewer and would be interested in reviewing Viral, please contact us at either oliver.harris@noisybadger.com or alex.bowes@noisybadger.com. Cheers.

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.
    

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:

http://www.facebook.com/pages/Michael-Calverts-Tracks/352863993971?v=app_2405167945&ref=ts

And here:

http://www.facebook.com/l.php?u=http%3A%2F%2Fwww.reverbnation.com%2Fmain%2Fglobal_search%3Fq%3Djames%2Balexander%26commit%3DGO%23!%2Fmichaelcalvert&h=9b6e7r_hRFK4re1ejzrWoyF4GKw

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.

Olly.