Indie Dev Insight: MagnetiCat

There are many things I like about being an indie (hobbyist) developer. The community is so incredibly supportive; there is lots of material at your finger tips; great forums and on the whole a lot of like minded people.

I can't put my finger on when I first came across MagnetiCat but we have certainly built up a rapport over the months. This was even more cemented by their first incredibly addictive launch game called Tiny Crosswords which is a prime example of how to do a simple concept well. While of course I would strongly recommend you download immediately please spare some time to have a read of their thorough and incredibly in depth account.

What got you into writing games?
It is one of those 2 or 3 things I always wanted to do. I grew up playing on NES and GameBoy, but before that I "inherited" a Commodore 16 from my cousin and played and experimented with it until it died and I was not able to find repair parts.

When my family could buy a PC, I discovered adventure games, and I think those - the first two Monkey Island games, in particular - are the games that made me think: I would really like to be able to create something like that, one day. Ron Gilbert has been my hero since when I was a kid.

But I was a curious kid and was distracted by many other interests. I was serious about being an astronomer, then I decided to be a punk, then I wanted to be a cinema director, then I wanted to be a painter. And so on.

What's good and bad about what you do?
So far, I love almost everything about making games - from the idea phase to the end of development it is something very demanding, but also extremely rewarding. Like all creative jobs, you are building something that will live on its own, in the hands and minds of the player. Being a person with diverse interests, game development is also something that lets me put everything I love in it. I wish I could do it more.

It is very different from what I normally do, working as a freelancer for others. Even if you have a chance to work with nice people, there the job becomes routine and just a grind for making more money and paying the next rent. You are not building anything for yourself, and in the end your clients rightfully think only about their own interests, not yours. You have no benefits and you are not building a solid future for yourself. While I would never change it for a 9 to 5 job – I need to be as free as possible - it is a stressful life.

How many people are involved in writing games at MagnetiCat. What roles do they take on?
We are two people. I work mostly as game designer, programmer, and on sounds; Rossella does game design and graphic design. But in general, we try to switch roles whenever possible. We work close to each other, so there is a constant exchange. It is something that comes from life as a freelancing team: each of us must be extremely self reliant, if necessary. If there is a problem with the graphics, the person working on them just fixes the issues; the same thing happens for most other things during the development of whatever we are working on.

What would you do differently now given what you know from projects completed and experience from the gaming and app market?
Tiny Crosswords is a small game (but there are similarly small games that are very popular in the Word category), developed and released under unusual circumstances. It is not enough to have a meaningful experience of the market, and many of the things we learnt we knew before releasing the game by following the stories of other developers.

Thinking about it, the only thing I would do differently is to avoid wasting as much time as I did on Twitter. In hindsight it was pretty obvious, but you must not count on Twitter for promotion, unless you know that people are following you out of genuine interest for what you are creating. In our case, Twitter followers were mostly other game developers coming from mutual follow exchange or using automated tools. They could not be interested in what we were doing, since we had no game in the store yet. Some of these followers I know outside of Twitter and I have helped in some web-related projects, but not a single one commented on the game or even congratulated us for our first release. Only a couple of people did.

Of course, if your game is particularly amazing, people will retweet it no matter what. So building something awesome – or better, building something that at least looks or sounds awesome - is still one of the first rules of marketing in the App Store.

Tiny Crosswords is not something that most would consider cool enough for their Twitter followers, I suppose. I would, but I made it, after all. It is a simple app, it's cute, it's elegant, and it is really loved by the few players that play it.

What tools do you use. By this I mean software development kits/engines (Cocos2d, Corona, Unity3D etc), audio packages, art packages.
Photoshop and Illustrator are what we use for the art of our games. Rossella uses most of the CS suite in her freelancing jobs. Tiny Crosswords is a very simple game, and it was designed in Illustrator. We then rasterize the images in Photoshop and use Texture Packer to create the spritesheets. We use Blender as well, but not within games or prototypes, yet.

We work with Cocos2D, Corona SDK, and recently with Haxe. We have been playing with Unity3D as well recently.

What made you choose these tools over others?
Adobe products are just the standard for professional graphic design. Not perfect, by any means - switching from one product to the other in the Adobe suite is often source of nightmares - but they are products that deserve the reputation they have. The new subscription system makes the CS suite relatively affordable, as well, if you can deduct monthly expenses.

The programming side of things is much more complicated. I think I tried a bit of everything over the years. When I started coding on iOS, I first learnt Objective-C and then moved to Cocos2D. I really like Cocos2D, and while I did not release any game made with it, I used it for most of our prototypes, including the early version of Tiny Crosswords.

Then I started looking into multi-platform frameworks; I picked up CoronaSDK for 2D games, and the version of Tiny Crossword in the store is made with it. I did not pick CoronaSDK for ease of development: with all the resources you have, I think it is difficult to beat the friendliness of Cocos2D and even better, Kobold2D (now KoboldTouch). Lack of proper debug and profiling for Corona SDK apps (same issue I have with Unity Basic) is also unnerving. But the good, awesome thing about Corona SDK is that it works on multiple devices and platforms very well. It is very reliable, and there are not that many commercially supported frameworks focusing exclusively on 2D. The build size is very small, and performance is great.

And yes, I have been toying with Unity for a while, even though I started studying it more in the past 3 months. It is a great engine, but for simple 2D games, it is overkill. Unity Basic lacks proper debugging tools and build optimization, features that are necessary to develop more complex games – and 3D games tend to be more complex than 2D ones.

While Corona and Unity are targeted to different needs, they actually have very similar advantages and shortcomings. Both are closed source; both come with only their community as a free form of support. Combination of closed source and paid support is something that I will never like. Both offer a more expensive license that unlocks the full potential of the framework – prices are not crazy, but completely out of the pockets of most indie game developers.

A language and framework I am really enjoying recently is Haxe with NME. It is plagued by sparse documentation, but working with it just feels right. Performance is terrific, since apps are translated into native code, and you can target most modern platforms with it. FlashDevelop fully supports it, so if you are on Windows or you have Parallels on a Mac you can have one of the best IDEs in existence for your game development. I am interested in releasing smaller web games, and Haxe is perfect for that, even though it is regularly used to build huge apps.

I had considered also Unity's Flash target, but it is expensive and generates very heavy code as it basically includes all the code for the Unity engine in addition to your game code: it makes no sense to develop Flash games with Unity unless you need to develop 3D titles.

What marketing tactics do you employ? Forums, twitter, paid PR etc
We did not do any marketing for Tiny Crosswords, as version 1.0.0 was a soft release. Anyhow, we plan on sending out press releases, a trailer, and send out e-mails to review websites for version 1.1.0.

The best marketing strategy, right now, is obviously to start advertising your game many months before its release, but only if the game is particularly unique, big, or memorable: otherwise people will forget about it.

The best long term marketing strategy is to keep on building good games and create followers among your players. Do not target only a platform, especially if your games do not require extensive optimization to run on different devices. You won't become rich, but you could be making a decent salary doing something you love.

What effect do you think free to play has had upon your game design?
From the beginning, before IAPs were introduces in iOS, I had many ideas that I knew would have worked well with a free to play setup, while being perfectly enjoyable to non paying users. I could never make them, because I just did not have the time and money to work on the development.

This said, I have a big moral problem in building apps that make money by encouraging a compulsive behavior in gamers; it is something I would be unable to do. I like some free to play titles, though – NimbleBit's games, for example, are fun to play even if you do not pay a cent. Same for Imangi's Temple Run. Purchase of in-app items like in RocketCat Games' Mage Gauntlet is great as well. But I suppose that all these developers might be making even more money if they wanted to and tried to build a more vicious cycle within their games that forced players to buy, sooner or later.

What resources do you swear by for learning new techniques, getting more from the packages you mentioned above, news etc. e.g Books (specific titles would be appreciated), forums / websites, social media
If you want to learn something, I think the best way is to find some learning material that has some sort of internal organization. Random tutorials are cool to solve specific problems, but if you want to be self reliant, you need to have a bit of order in your mind. Not too much, just a little bit.

For Objective-C, I would recommend:

• Stephen G. Kochan – Programming in Objective C: the best introduction to the language and all you need to understand Cocos2D books. It's being constantly updated, so grab the latest edition if possible.
• Steffen Itterheim – Learn Cocos 2D: Steffen makes you build many small games instead of a big one, which is something I prefer while learning.
• Raywenderlich.com, which offers also some introductory stuff for Unity3D.

For Corona SDK, the documentation (even though a bit messy), examples, and experimenting were all I needed. But even if you are familiar with other programming languages, I recommend you skim through http://www.lua.org/pil/ to learn the basics of the language. Lua is fun, but it has some quirks compared to other languages you have been exposed to.

But once you have studied a little bit, the only thing that works is to make games on your own. Small prototypes, built from scratch, just for you and your friends. Remake classic games like Space Invaders, if you are short on ideas or if your ideas are too ambitious. Just learn to make things, like an artisan. And after a few experiments, even though you think you are not good enough yet, try to complete a small game and release it. Leave that awesome adventure game for later.

There has been a lot in the press recently that app development is going through a gold rush and that the bubble will burst soon. Do you see it like this?
Absolutely. I think the gold rush stopped in 2011. After that, huge successes from unknown developers are more and more rare. We have seen many in 2012 and in 2013 from Indie developers – Temple Run, Hundreds, the Blockheads, just to name a few – and while it is amazing these great games were built by tiny teams or solo developers, these are guys and gals that have been releasing solid titles from the beginning of the iOS app store. They have built a reputation for themselves over the years, even risking a lot in the process – Imangi's Max Adventure nearly killed them, and Temple Run was not successful, at first – and thus they have loyal gamers, followers, and they are well known and respected by Apple and the press in general.

These are things you cannot build with a single game – it can happen, but it is like winning a lottery where you can control just one or two of the numbers.

This said, I believe there are many niches were you can still be successful. Some swear by the educational game app market, for example, but then again I think it is unacceptable to force yourself to develop something you are not interested into; unless you approach game development only as a businessman, of course.

Do you think app games will eventually kill off AAA titles as we know them?
No, I think the opposite is already happening. Most of the names you see on top grossing lists are either the usual big companies that existed before the App Store – EA, Warner, Activision, Disney, and so on – or ex-indie developers that have made enough money to support their games with decent marketing campaigns.

Many developers accept to sell their games through game publishers. This is dangerous ground and you risk on losing your freedom and sanity going in that direction. I would not do it. Sponsorships like it happens for Flash games are fine, as long as you keep full IR on your work.

What does 2013 have in store for MagnetiCat?
We will release Tiny Crosswords in the Amazon store soon.

It is difficult to make precise plans when you do not have funds or cache money. We will work on more prototypes, and thus collect more ideas, so that when we have some moment of respite from our freelancing work, we can jump on one of these ideas and develop it.

I would like to focus on releasing some games on the web, and release those I think would fit touch devices also on iOS. I would love to do a Ludum Dare or two, but I doubt I will have the time to.

Any additional advice you would give for up and coming indie developers?
Just start doing stuff. Do not obsess over platforms, programming languages, softwares you are using to make your games. Programming skills transfer without problems from one language to the other. Pick the tools that let you complete the game in the shortest amount of time; do not fill your mind with useless keywords and syntax, autocompletion is there to help you in most IDEs, and chances are that any specific library you learn today will change completely in a couple of years. Pick the tools you can afford: there is plenty of free stuff you can use to build great games.

Build small things for yourself; when you feel you have something good in your hands, it is time to look for a bigger room to display it. Polish that thing, then unleash it to the wild and let it be played. Treasure feedback. Do not be an asshole to your fellow developers and gamers.

Once again, build small things that you love making and playing. If you can afford this luxury, do not obsess over money. The best things we make are those we make out passion, because they are the purest.

If money is a problem for you as it is for us, try to optimize your time. I feel your pain, I understand it is difficult to do, sometimes almost impossible. But you can do it. Say goodbye to that TV show. Play less games. Maybe take a shorter bath. Forget about Twitter. Forget about Facebook.

Risk a little. You won't be around forever, and the best thing to start doing something you love is doing it today.

Tiny Crosswords is available to download on App Store for free. Also keep up to date with MagnetiCat's progress on their website.

Indie Dev Insight: RocketCat Games

To quote RocketCat Games their design philosophy is to have huge amounts of replay value; create deep and varied gameplay; while having unlockable Upgrades and Hats. This philosophy has served them well with Punch Quest being very well received by the industry but important lessons learnt on the way.

This is the second in the series of discussions with indie developers of all shapes and sizes who share their experiences and thoughts on the indie scene.

What got you into writing games?
I just felt like doing it one day. I was a big fan of free independent games for a long time. They made the process of making a game seem attainable. The App Store meant there was no barrier to entry to trying to make a commercial game, so I got a couple of friends to try it with me.

What's good and bad about what you do?
The best thing is probably the huge amount of freedom in being able to make a living off making games. The worst thing is maybe that it's a very solitary sort of thing. I still have never seen any of the people working with me.

How many people are involved in writing games at RocketCat Games. What roles do they take on?
3 people. I design the games, make the levels and tweak everything, and handle the business stuff. Jeremy Orlando does the programming. Brandon Rhodes does the art.

What would you do differently now given what you know from projects completed and experience from the gaming and app market?
It's really hard to say what I'd do differently. We learned a lot about how free game pricing works, so if I had to do Punch Quest over I'd tweak that for the release of the game. Otherwise I don't think I'd change too much.

What tools do you use. By this I mean software development kits/engines (Cocos2d, Corona, Unity3D etc), audio packages, art packages.
We make all of our own stuff, except for some audio packages. Mostly from cheap/free sound sites. I'd like to check out Unity.

What marketing tactics do you employ? Forums, twitter, paid PR etc
I post to a couple forums and run a twitter account. I have a press list of people that like my games, so when a new one comes out I make sure the list gets codes for review. That list is always expanding. Also, with Punch Quest we started to get into cross-promotion with other developers again, which is really important.

What effect do you think free to play has had upon your game design?
It definitely affects the design. Or at least it did eventually. When Punch Quest was first released, free to play didn't affect the design much. We had higher end money sinks, but didn't make the game grindier than it was intended to be. As a result, the game didn't make much money at all. After awhile, we gave in and raised the price of in-game upgrades/equipment by 5 times the amount. This made profits surge. We'd like to see if there's a way to do free to play without it messing with the design.

There has been a lot in the press recently that app development is going through a gold rush and that the bubble will burst soon. Do you see it like this?
Gold rush ended in 2009, didn't it? I have noticed that it's been getting steadily harder to break in and make a name for yourself. Still seems possible, though, like with the recent success of 10000000. It just seems to get more difficult.

Do you think app games will eventually kill off AAA titles as we know them?
They don't seem to be. They're very different markets. Especially since app games seem to be solidifying into certain preferred genres. Big AAA companies seem to mostly be avoiding the App Store, still, after all these years. I wonder if it's because they see the App Store as a casual-dominated market, where with a couple notable exceptions it's probably a mistake to do a big AAA title. So I don't see why app games would kill off AAA titles, because there's very clear divider between the two audiences.

What does 2013 have in store for RocketCat Games?
We're doing a free hack and slash game, with random dungeons. It will be similar to Mage Gauntlet. You'll pay to buy new character classes to play as. In that way, we're hoping we can keep the game design untouched by it being free. We'd also like to try making some no-IAP $5 games.

Any additional advice you would give for up and coming indie developers?
Here's some pricing thoughts. $3's still a nice price point if you can make a game fairly quickly, are a very small team, or a solo developer. Making a free-to-play game is unlikely to make you money as your first game, but it may be worth it just to get the exposure and a bunch of possible fans that you can show your next game to. $2 seems like a waste, most would just be willing to pay $3. I hate the 99 cent price point, seems like even more of a gamble than making a game free. May as well just charge $0, for the significant extra downloads.

Go and see what all the fuss is about and download Punch Quest for free.

Indie Dev Insight: Christer Kaitila

When I first started writing this blog as a reflective tool to chart my progress through 10,000 hours, I got in touch with those more experienced than myself to see what insight they could give me on my journey.

Over the last year I have become obsessed by reading as much as I can about other devs experiences and advice, to the point that I thought I would reach out again to some for their wisdom to help me and you alike.

This is the first in a series of indie dev insight that in some way the individuals involved have had an impact on my journey to date.

First up is Christer Kaitila, a name that you may not be familiar with but one that I first came across when reading an article on gamasutra and subsequently signing up for his initiative of 12 games in 12 months. In fact as I write this I have just completed my first month effort which I commented on here. I put the following questions to Christer and found his responses to be very enlightening so I hope you find this of some use. I certainly have.

What got you into writing games?
The movie TRON. My dad. Pacman, Dragon's Lair, Gauntlet and 1942. My TRS80 coco. The warez BBS scene of the eighties. The demoscene that continues to be at the forefront of gamedev tech. The knowledge that the act of PLAY is what people do when their lower needs in Maslow's hierarchy are fulfilled. You only PLAY games when you aren't starving or being shot at. Therefore, play is a state of pure bliss, of innocence, of prosperity.

What's good and bad about what you do?
What's good? The inspiration. Waking up excited. The creativity. Coming up with new ideas and stories. The learning. Honing my skills on an infinite stream of new tools. The challenge: easy things are boring. Gamedev is not easy. That's what is fun about it! The sheer triumphant pride when you hit the finish line on a game.

What's bad? Seeing my own limitations. The lack of time to take some ideas to fruition. Monetization woes. Starving artists still have better jobs than rich folks with boring jobs, but sometimes we imagine what it would be link to sit around and collect paychecks for something mundane. Must be relaxing.

What would you do differently now given what you know from projects completed and experience from the gaming and app market?
Aim lower. Make simpler things. Collaborate more often. Release sooner. Market better.

What tools do you use. By this I mean software development kits/engines (Cocos2d, Corona, Unity3D etc), audio packages, art packages.
Javascript, html5, c++, openGL, AS3, Stage3d. Notepad++, FlashDevelop, Chrome, 3dsmax, Photoshop, Acid, FileZilla, CoolEditPro.

What made you choose these tools over others?
Ease of use. The best tool, to me, has the least number of features. I don't want a swiss army knife, I want a single blade of infinite sharpness.

What marketing tactics do you employ? Forums, twitter, paid PR etc
In order of success found: Twitter, Google+, My blog, Forums aplenty.

What effect do you think free to play has had upon your game design?
I'm 100% certain that $0 is the future average price for all games in all genres and all platforms. FTP means hit players hard with your BEST content in the first five seconds. Reduce barriers to entry. LOWER FRICTION.

What resources do you swear by for learning new techniques, getting more from the packages you mentioned above, news etc. e.g Books (specific titles would be appreciated), forums / websites, social media.
I never learn using books and videos are way too slow for my taste. Wish I could watch tutorial videos at 2x speed. I *love* tutorial blog posts. The best way to learn to make games is to rip apart and hack an existing open source game. Tinker with the internals of something that already functions. Learn from the masters. Stand on the shoulders of giants.

There has been a lot in the press recently that app development is going through a gold rush and that the bubble will burst soon. Do you see it like this?
The bubble has already burst. It did halfway through 2012. The gold rush is long over. Everyone calls the new economy of apps: the appstore lottery. This means that 99.9% of all apps make no profit and 0.1% are a HIT. There's more money in Windows/Mac/Linux games now on places like Steam. Apps, while popular, are a terrible way to make a living: the sales stats are everywhere if you google long enough. The average fulltime indie app dev makes less than the average McDonald's employee. Planning to make a HIT on the app store is as likely as a musician planning to become a rock star or a kid planning to play basketball in the NBA. The vast majority will never get there, despite hard work and natural talent. If you're just getting into app dev now, you missed the bandwagon. There are certainly lots of opportunities out there and there will always be a new exception to these rules, some dev who gets a big hit. Success in apps is still possible, but only for the luck (or very well funded) few.

Do you think app games will eventually kill off AAA titles as we know them?
No, I predict that these two things will merge into one. AAA will be the new norm for apps. I predict a massive quantity of free-to-play games with multimillion dollar user acquisition budgets for you to compete with if you're still on the app store. In the near future, installs will COST you money (this is how almost every game in the top 100 does it already: they don't sell games, they BUY users at a buck a head and hope to find a few "whales" to support their efforts via IAP).

What does 2013 have in store for you?
12 games in 12 months via the happy phenomenon that is www.onegameamonth.com

Additionally, all the joy that comes with releasing more commercial games (strategy/puzzle/tactics mostly), being a loving dad for my 2 year old, writing another book, a bunch of new articles, and spending lots of time outside or making music. I'm transitioning from being a starving game developer to being a wealthy gamedev TEACHER. For me, there's more money to be made teaching newbie gamedevs how to make games via articles, books, tutorials, courses and the like than there is actually selling games. I think I'll focus on producing many small freeware games as a means to attract more and more people interested in learning how.

Any additional advice you would give for up and coming indie developers?
If you yearn to make a clone of your favourite game, first add up the number of people who made it x the number of fulltime years of labour they put into it. If you want to make an AAA console game or MMO, remember that they have 300-600 years of human effort inside. Longer than your lifetime. Therefore, be wise and aim smaller: something you can make in a single month. Release early and often, iterate a lot, and see which games "stick" or resonate with others. Make a dozen games next year, get lots of people to play them, and then iterate and improve the ONE game from the dozen that people liked the most. Polish it, add more to it, and then sell it.

My #1 piece of advice for game developers of the future: make games for the fun of creation. Like art, your success shouldn't be measured in dollars but something more meaningful, like the number of people who got some joy and happiness from your hard work, or number of lives improved in some small way, or quality of new things you learned, or satisfaction your obtained from making something you're proud of.

YOU CAN DO IT!

I would strongly encourage that you check out Christer's books of The Game Jam Survival Guide and Adobe Flash 11 Stage3D (Molehill) Game Programming Beginner’s Guide.

You can also find Christer on twitter, google+ and his insightful blog.

Game #1: Astavoid

Back in December I uncovered an article by Christer Kaitilia about his challenge of writing and producing 12 games in 12 months in 2012.

I found the article to be very motivational and a great idea. I watched with interest as his idea evolved into a challenge to indie devs to follow suit in 2013 and from which http://onegameamonth.com/ was born.

From previous blog entries you will have seen my angst at not producing any new games since the launch of Astavoid in April 2012 for iOS and Android. I thought this was a perfect way to refine my design skills by making something that could be produced from start to finish in a month to keep my ambition in check. The way I thought I could bolster my utility belt of expertise and knowledge was to design games in a way that each one although different added new features and concepts.

This also coincided with my porting of Astavoid from Corona SDK to Unity which I had written a diary on of part one and part two. I can now finalise part three given that I have delivered on the project.

What I liked about this whole approach is that I started off too big and was getting demotivated by the challenges I was facing. So I started off with a cross platform port of Astavoid and in the end resulted in just a port to be played in a web browser. But thats the point right, redesign but ensure you finish a game?!? No point spend no time and not finishing it.

So my January game is Astavoid ported from Corona SDK and Lua to Unity and C#. This has meant I have learnt the challenges around physics, atlases, refactored all the code, increased frames per second from 30 to 60 as well as have a template for February's game.

Why not check out Astavoid now as its free to play via a web browser here and as a means of comparison you can still download the original Corona / Lua version on iOS and Android.

I also encourage you to sign up for one game a month as I have found now in my second year of game development that this really focuses the mind.

Unity, Futile & C# - Part 2

If you read the first part of this series you will know I am transitioning from Corona SDK to Unity. More specifically Unity and the 2D rendering framework, Futile. The purpose of this blog post is to further diarise the process as well as providing some level of documentation to Futile which is still in its infancy.

Day 8
This was very much a day of highs and lows. To match to the iOS version of Astavoid I wanted to replicate the screen transitions. However, within Futile at the moment there are no transitional effects between FContainers so they snap rather unattractively. Thankfully, and purely by chance, my screen transitions were straightforward and just gave the effect with text animations. As this has already been expressed in previous entries, this was achieved with the excellent GoKit by prime[31]. Definitely have a play around with this and to help you its featured heavily within the Banana Demo project.

With this in the bag I thought I would experiment with getting GameCenter integrated into the game as the one on the Appstore features OpenFeint which is now deprecated. I started off thinking this was going to be a straightforward exercise but got a little confused with how the GameCenterPlatform class worked with Unity, scripting and Futile.

This is where my day started to go a little downhill and this was typical of not knowing enough about how Unity worked. My first mistake having implemented the code was wondering why ads weren't appearing within the Game window of the Unity editor.

What I hadn't done was to enable GameCenter under iTunes Connect for a unique app. Only with this will ads works. To enable follow these steps:

• Log on to iTunes Connect
• Click on Manage Applications
• Ensure you have an app which is in an edit state such as waiting upload or an equivalent to modify GameCenter state.
• Click on Manage Game Center
• Click "Enable for Single Game."
• Click Disabled.

The Disabled button toggles between Disabled and Enabled. To disable your app for Game Center testing, click Enabled. Once you disable, you will no longer see your app in the Game Center sandbox. You are only permitted to disable up until a version of your app goes live with Game Center. Enabling Game Center for testing unlocks the Game Center interface to allow you to set up your leaderboards and achievements.

Once I had set this up I created one Leaderboard and one achievement to ensure there was content.

Alas, still no test advert coming through. It was at this point I thought that maybe they didn't come through within the editor and I need to test on my device. This was my second mistake of the day.

For some reason I didn't realise it was packaged into an Xcode project. Having come from Corona SDK this step didn't happen it just got compiled and you dragged the compiled .app file onto the iTunes to add to your device. This was when I realised I hadn't setup the bundle identifier properly either.

The next mistake I made was trying to compile the xcode project to the Xcode simulator. The reason I was trying this was that I wanted to ensure the project worked before trying to put it to my device. I was getting some fundamentals errors on compilation, over 200 in fact, which I felt just couldn't be right. After some twitter conversations and scouring the internet I found you can only compile to the device.

So after some wasted hours I now had my app on my device, but still no adverts. It was time to call it a day.

Day 9
A new day brought a clearer head and renewed vigor. When I first started out with game development I wanted to write my own code and therefore learn and understand the most. But having done it now for a year and having to balance my time with a full time job and two young children, I've concluded that using third party plugins is ok. Yes there is a cost to them sometimes but I weigh that up to cost I put on my spare time. Yes I may never make it back on my games in the near future but for the sake of $20 there is no point me struggling for a week trying to get something to work.

This clarity was reached to some degree during my investigations on Day 8 when I repeatedly came across postings and recommendations for prime[31]'s GameCenter and Ad plugins. Having already experienced the ease with which their GoKit was implemented I decided to take the plunge and bought the GameCenter and AdWhirl plugins.

The plugins are excellent and can be setup with a few very easy steps.

For AdWhirl first setup an account and get your Publisher ID as this is what the prime[31] plugin requires. In regards to ad providers I chose a distribution of iAd (70%) and AdMob (30%).

Assuming you have followed Matt's banana project to a point you would imported a futile package, dragged to the Unity hierarchy and assigned a script to your Futile game object. With this assumed open your script and declare a private variable such as private string publisherId = "your id goes here"; . Then within Start method, and this apparently is the important bit, make AdWhirlBinding.init( publisherId ); your first call.

Having implemented this I built for my device and tested and BINGO! adverts start coming through.

Again, buoyed on by this working I turned my attention to GameCenter. I had assumed I had setup everything up in the iTunes Connect steps explained above so I set about implementing it.

Like all implementation's of GameCenter you must first check that GameCenter is available and then you authenticate. For the purposes for testing I am resetting the achievements each time to ensure the banners etc come in. The code, again in my Start method is:

// Do gamecenter stuff ... Is GC available?
if(GameCenterBinding.isGameCenterAvailable())
{
	// Yep looks like it is so authenticate the player;
	GameCenterBinding.resetAchievements();
	GameCenterBinding.authenticateLocalPlayer();
	GameCenterBinding.retrieveAchievementMetadata();
	GameCenterBinding.showCompletionBannerForAchievements();
}

Before testing on your device ensure you log out of GameCenter as when testing on your new game and you log in it will go into Sandbox mode while in development.

Success!!

Day 10
A very successful day on day 9 so to continue on with this I thought I would hook up the achievements when a certain distance was achieved. All I do is create a method within the Update method of my game scene to check whether a certain diatance has been achieved:

void checkAchievement(int _score)
{
	if(Main.instance.BestScore == 0)
	{
                // First play
		Main.instance.BestScore = _score;
		GameCenterBinding.reportAchievement( "AA001", 100.0f );
	}
	if(_score >= 5000 && _b5000 == false)
	{
                // Distance achieved
		GameCenterBinding.reportAchievement( "AA002", 100.0f );
		_b5000 = true;
	}
	if(_score >= 10000 && _b10000 == false)
	{
		GameCenterBinding.reportAchievement( "AA003", 100.0f );
		_b10000 = true;
	}
	if(_score >= 15000 && _b15000 == false)
	{
		GameCenterBinding.reportAchievement( "AA004", 100.0f );
		_b15000 = true;
	}
}

If a score has been reached then via the GameCenterBinding i.e. our prime[31] plugin, it sends a message to iTunes connect to see if an achievement has been completed. This is the case because we provide the id of the achievement and the percentage complete. As I specified GameCenterBinding.showCompletionBannerForAchievements(); in my initialisation method the player will get instant satisfaction as the achievement banner will be shown. This all happens on a separate thread so no effect on the game's performance.

The next challenge was to take on the music and sound effects within my game. I slightly misunderstood how this worked and didn't take advantage of Futile's sound manager, FSoundManager. So what I chose to do with this was to adapt the Banana project implementation and create a separate sound player class:

public class SoundPlayer
{
	static public void PlayBlipSound()
	{
		FSoundManager.PlaySound("Blup", 0.95f);
	}

	static public void PlayMusicSound()
	{
		FSoundManager.PlayMusic("music", 0.3f);
	}
}

This implements the in-game music and the button sound effect. The gotcha I had here for a little bit was I didn't notice the difference between the methods of PlaySound and PlayMusic. All I now need to do is within my Start method of my main class is to call SoundPlayer.PlayMusicSound(); and viola music a go-go. Similarly, in my SignalRelease (eventhandler) methods for my buttons I call SoundPlayer.PlayBlipSound(); to have a sound effect when my buttons are touched.

Day 11
Jumping around a little bit I refined the resolution logic:

FutileParams fparams = new FutileParams(true, true, false, false);
fparams.AddResolutionLevel(480.0f, 1.0f, 1.0f, "");
fparams.AddResolutionLevel(960.0f, 2.0f, 2.0f, "-hd");
fparams.AddResolutionLevel(1024.0f, 2.0f, 2.0f, "-hd");
fparams.AddResolutionLevel(1280.0f,	2.0f,	2.0f,	"-hd"); //Nexus 7

and worked on my Rocket retina graphics. Again, going back to old faithful in Texturepacker and recreating atlases with the appropriate suffixes.

I also worked on touch logic whereby a user clicking on the screen would allow the rocket to change "depths" giving the illusion of going in and out of the asteroids and in turn running the sprite animation of the rocket.

Day 12
I am unconvinced about whether the accelerometer is the right way forward for this rewrite. However, I want to make sure I don't over engineer this game as that was the original control system and move on to pastures new and new learnings. What I did decide to do is implement a Dpad and evade button just to see how it works.

I wanted to keep the style minimalist and non-intrusive as possible. How I implemented was to create shapes. One of the complete Dpad and then a further 4 for each direction which is then created as a separate FButton and placed over the top of the complete image. The evade button will be used to run the rocket sprite animation and change the alpha of the asteroids so the player knows which asteroids to avoid. Also a little rearranging on the screen to ensure it doesn't become too crowded. Tested on various resolutions to ensure all sits correctly.

Day 13
Back to graphics and animation today and that is to create a rocket flame / exhaust. I had a slight headache over how to implement this. In the current version using Corona this is a particle system using a third party plugin called Particle Candy which was very easy to use. However, the new Unity particle system Shuriken was something that my novice experience was struggling with and not one I could see how it could be directly implemented using Futile.

Instead I chose to animate via Flash and export the frames from Flash into my atlases and create an object to play and scale the exhaust appropriately. The effect I am pleased with but feel I will need to tackle the particle system sooner rather than later.

Day 14
Big subjects were tackled today, collision detection and multi-touch. Let's start with the latter.

Multi-touch is important for my game as I want to move and evade at the same time and the normal signal release (eventhandler) won't even queue messages as its first come first served.

I'll confess I made a major oversight with implementing this and wasted a lot of time. An important point is to ensure you also inherit your class from FMultiTouchableInterface and then to update your Stage Handlers to include and remove multitouchtargets.

Code:

override public void HandleAddedToStage()
{
	Futile.instance.SignalUpdate += HandleUpdate;
	Futile.touchManager.AddMultiTouchTarget(this);
	base.HandleAddedToStage();	
}

override public void HandleRemovedFromStage()
{
	Futile.instance.SignalUpdate -= HandleUpdate;
	Futile.touchManager.RemoveMultiTouchTarget(this);
	base.HandleRemovedFromStage();	
}

with the final thing being is to implement what should happen when multiple touches occur with the public void HandleMultiTouch(FTouch[] touches) method. This should now allow your game to detect and react to multiple touches.

The next thing to tackle was collision detection. I managed to setup a collision detection of sorts by again having a method within the Update method checking whether one FSprite's position overlapped with another FSprite's i.e. rocket and asteroids, While it worked I found it wasn't responsive enough.

Day 15
Having thought about this some more I was coming to a realisation that maybe I needed to dig a little further into the Physics system. While there isn't one setup specifically within Futile the community has written FPhysics which allowed more realistic collisions to happen between objects. This in itself through up some interesting points of research. The main problem still was that neither Futile nor FPhysics implement fully a method to programmatically initialise rigidbody and in turn a collider in order to take advantage of collision detection inbuilt to the Unity Physic system. Where it should be possible to create something like the following:

void OnCollisionEnter(Collision collision) {
    foreach (ContactPoint contact in collision.contacts) {
        Debug.DrawRay(contact.point, contact.normal, Color.white);
    }
    if (collision.relativeVelocity.magnitude > 2)
        audio.Play();
    
}

this will not fire in either of the two earlier instances. On discussion with Matt what it has highlighted is that it is very possible but in my novice state my understanding of Unity's components means that I am going round in circles.

So that brings me on to what to expect from part 3 of this series. The focus will be on bridging the gap between Futile and 2D in Unity to tackle the particle system (Shuriken) and the physic system to implement an equivalent experience to my Corona SDK game.

It should be noted for those that use Corona that this seems like a huge amount of work when Corona wraps this all up for you and that is indeed true and one of its big advantages. However, I have seen enough of the potential of Unity and getting familiar with its setup to know the short term pain will be more than worth it.

Until next time, Happy New Year!

Spriter: helping your 2D animation woes

I'm no artist, in fact barely a coder but one thing I struggle with is decent 2D art / animation. I can't remember why or the date but I have used Flash on and off for doing my art and animation for over 10 years but have struggled to find a decent alternative. I think what I like about Flash is the nuances of the tool for drawing that I am yet to find else where.

Its for these reasons that I started an investigation into something that could replace or complement my current toolset.

If you look at my current game on the market, Astavoid, I have a distinct style. This more than anything is minimalist given the time I have to focus on the art. I was told, and I forget the source, that its important as an Indie to do your own art as you aren't reliant on someone else to do your work, minimises cost and therefore a master of your own destiny. With that of course comes budget. I for some reason, again forgetting why think its age, have a copy of Flash CS3 which is by no means a feature rich product by today's standards. However, it is something I am reasonably comfortable with.

My route of investigation took me to Spriter. Spriter if you don't know is an animation tool for 2D games. Larger, more smoothly animated characters, all running for your favourite engine and platform. It had a very successful kickstarter in April 2012, of which at the time of writing the product sits in Alpha.

It is for the purpose of this blog to see whether Spriter can compliment an art package to provide quicker animation techniques over maybe that of tweening in Flash.

So lets begin, to start this off I will create a little gun man type thing which is a concept I have been working on. To help you visualise my minds eye we jump ahead a little to the final image.

Having read the web pages of Spriter it looked like my animation needed to have component parts. This is because Spriter accelerates the animation process by transforms or skeleton rigging to provide pivots and movement where required.

My first step was to breakout my character into various body parts. As you see from the image above I have a character with a gun. What I will look to animate is the character shooting with a slight bit of kickback / recoil.

For that reason I split my character out into sections:

• Head
• RightHand
• RightArm
• Gun
• Body
• Feet
• LeftArm

These are organised as such and this order to give the relevant layer depth to give the illusion of the character holding the gun etc.

With this now in situ I save out the layers one by one as PNGs hiding all but the layer I'm saving to have distinct images.

Next is to fire up Spriter, if you haven't done so already download here and then once installed create a project and then import all the images we have just saved out. We then in turn position the images on the worker area to reconstruct our character. All going well it turns out like the one below.

The next thing to do is create keyframes along a timeframe, identical to how implemented in Flash, to denote when something should happen. This is the point whereby you start your experimentation. For mine I will add a keyframe around frame 80 (assuming a 60fps game) to move the gun to an aiming position. To do this we simply click the object "gun" in either the "objects in frame" window, or on the working area and a transform box will appear

To make it do something you can either move it (replicating a tween within Flash where it will animate to), scale or pivot. For the purposes of what I am doing I will pivot on the bottom left corner so the top right is pointing up. It's as easy as that!

The process now becomes trial and error rather than complicated keyframe drawing only to find there is an error.

Once you have completed your keyframes are ready to export out ready to put into a spritesheet / atlas. Here is something you must watch out for. In the current version of Spriter, at time of writing the alpha version, only the keyframes will get exported and not every frame. This of course for an animation is next to useless.

However, not all is lost. Dependent on the length of your animation this workaround could be pretty tedious but what you need to do is add a keyframe to each frame of your animation. Then when go to File -> Export to PNG all frames will be exported for you. Now you are ready to put your keyframe animated images into atlases / spritesheets with a tool like Texturepacker for use within your game.

And there you have it an animation in next to no time. So what are my feelings of Spriter. To be honest huge potential as the process of pivot and move was very easy with the key being to split out my character to component parts and the rest is a doddle. I will certainly be intrigued to see how the beta and full release of the product turn out.

From Corona & Lua to Unity & C# - Part 1

For those of you who have followed my blog for a while you will see that title and think: "Changed his mind again!!", and you'll be right. I was taking my last blog a little further and experimenting with Cocos2D and Kobold2D. Both proved excellent and Steffen Itterheim's book Learning Cocos2D gave me a good grounding in both.

I think the thing that I started to get disheartened by was as soon as I finished the book Steffen announced he would be transitioning from Kobold2D to KoboldTouch. While that is no great shakes in that I hadn't really started I thought to myself given that I was looking to transition did I want to go with something that was closer to my core, .Net. The rationale behind this is that although I have released apps in Lua and Objective-C they took longer than I wanted as I got used to the syntax and idiosyncrasies of each.

Like a lot of people I am a follower of Matt Rix (@mattrix of Trainyard fame) who had spoken of a 2D code centric rendering framework he had been working on called Futile for Unity. I was intrigued by this as I had wanted to dabble with Unity for some time but had been put off by the plethora of buttons and options as well as a third axis I hadn't even contemplated :).

To start off with I watched the videos on Matt's website http://struct.ca/futile which gave me a decent insight into what it was capable of. I'll be honest I had to watch them each about three times to break through my mental block of Unity but what was becoming clear is that Unity only forms about 20% of this approach. MonoDevelop would become my friend and that was the point, code centric. So I thought I would take the plunge. First off I followed the steps on Matt's Github page:

How to open the project

• Grab the project from github and put it somewhere - For the lazy, here's a zip of the whole repo
• Make sure you have Unity installed
• Go into BananaDemoProject/Assets/Scenes and open FutileDemoScene.unity

How to make sure you're running it at the right resolution

• Go to File -> Build Settings -> Click "PC and Mac Standalone" -> Click "Switch Platform" (if it's already greyed out, you're good)
• On the Build Settings page, choose Player Settings
• Under Resolution and Presentation, set the size to 960x640 (or 480x320, or 1024x768)
• Go to the "Game" tab
• In the top left dropdown, choose your resolution (instead of "Free aspect")
• In the top right, make sure "Maximize on Play" is enabled.

Having followed these steps and watched the video while playing around with the code I personally started feeling quite comfortable with the concepts. In particular the third video of just over an hour really helped cement my understanding

For the purposes of clarity I am using Unity 3.5 (not 4.0) and took advantage of Unity's April 2012 give away on iOS basic. The latter is obviously required for publication and distribution but the free one to PC and Mac can still be designed to and just change the player settings to 480 x 320 for example.

Like most things when you start with something new I need a focus to adapt to my own requirements. This is the only way I find I can learn is to play around with things and try and try again. What I thought I would do is document my day to day transition from Corona and Lua to Unity and C# which the latter seems a popular option. For me the code for Astavoid was actually very similar to Matt's BananaDemoProject so unless I make paricular reference to code I would strongly recommend having a nose around there.

What should also be noted is I'm a hobbyist Indie (not sure that even exists!!) but means I can only afford at best 4 hours a day in the week and perhaps a little more at weekends. So my definition of a day is actually quite short so your progress could be even quicker.

I thought writing a new game would probably be too challenging so instead I focused on porting Astavoid from Corona SDK and Lua to Futile/Unity and C#.

For those of you who haven't had the pleasure of playing my first game its a very straightforward space evasion game that is available free on the App store. Why not download it for reference, its free after all :).

Day 1
First and foremost I didn't want the same hassle I had when I first wrote Astavoid concerning fonts. On the iOS and Android devices handle paths differently so I followed the lead of Matt's video tutorial and purchased Glyphdesigner. Really not sure why I didn't do this the first time but is an excellent tool to ensure compatibility of fonts across devices. Furthermore, I could include this font image within my textures / atlases. The font mapping file (.txt) also needs to be included within your resource folder in Unity.

The next tool to your arsenal is the excellent Texturepacker this proved to be a lifesaver when I first wrote the game with Corona and is equally as effective for Unity. The only difference being that it outputs a text file rather than a Lua file but the transition is seamless. I couldn't recommend the product enough and, again, if you watch the video's on Matt's page this is what he is using.

So with my font and background graphic within my texture I was now in a position to create my first scene. Nothing too strenuous as really I was dealing with 5 text objects and a background image. Needless to say this was very straightforward. I created my Main.cs (C# script) which I dragged onto my Futile object. Then I open MonoDevelop and put the appropriate logic into the Start method of the Main class. Ensuring of course to add the labels and sprites as children of the scene (AddChild(object) so that they show up. Missed this one a few times :)

The result was a fair reflection of the original title page, other than the fact it didn't do anything at this stage:

Day 2
Buoyed on by my first day's achievements, and when I say day I only mean about 2 hours, I set about bringing the asteroids into my texture and look to provide some movement.

I started to organise my code a little and create an FContainer (or scene) to split up the various screens I was going to need. So I created a TitlePage and a GamePage.

Within my Start method on the Main class I did a call to the title page which in turn did a call to my game page. To conclude the navigation my game page, via the pause button, would return me to the title page. This simple transition meant two classes representing the scene, and my Main class with its singleton instance controlling which one to display. At this point I was calling the scene methods directly and not by button touch.

With this now working well I revisited Texturepacker and dug out my asteroid artwork and added it to my texture. I then re-published and added my new texture to the Unity project.

There is no specific physics engine built into Futile specifically aimed at 2D at the time of writing. Unity of course contains the powerful NVIDIA® PhysX engine but the whole purpose of using Futile was to make my life easier. So on day 2 of my adventure I focused specifically on animation

Thankfully Matt has considered animation / tweening and incorporated Prime31's GoKit library into Futile which makes animating the Futile objects very easy. All I had to do is create a base class for my asteroid object and derive from this for my different asteroid types to give the perception of depth. I then used the GoKit library to tween these asteroid objects relative to their size and depth and then cull when off screen.

Day 3
The aim of day 3 was to hook up the title buttons via touch. Again this is straightforward enough through Futile's touch manager. By reviewing the code of the Banana demo project it is straight forward to see how the touch events via a signal release and then the relevant method to call. From these methods I was then calling my instance to call the scenes on the stack. This makes traversing the scenes easy.

An additional update was to apply the distance counter to the update method of my scene. My game by this point is running at a very smooth 60fps which exceeds the 30fps I was running at with Corona. Not a limitation of Corona I should say but mine in writing efficient objects and caching correctly. I remember probably spending about 2 months on this subject alone optimising my lua code and get it done in a day with Futile / Unity! I use a modulus to only update the counter every other second (or update) to keep the distance score a little more realistic.

Day 4
With the principles of the scene setup I turned my focus to the rocket sprite. Its worth noting at this point that I am using existing assets that may need to be modified dependent on what control mechanism I go for.

With this in mind I created another texture atlas in texturepacker for my rocket and therefore not over bloating my other atlas. This is in part because I made the decision to add in my space background to the original atlas as it would be used on multiple scenes.

I also revisited my asteroid code and inherited more from my base class to streamline my code and adhere to the DRY approach of Don't Repeat Yourself. With this refactoring done I created a fourth size of asteroid to run in the background as a form of parallax asteroid belt.

Day 5
This was a big update day! The first was tackling how to handle storing of data within Unity. I learnt that this was done with key value pairs that could have certain types attributed to them such as strings, floats, etc. I looked at using the PlayerPrefs class to store information for my best score but thought this needed to be extended a little to create my local leaderboard. I found something that I could base my class on here and adapted appropriately. Having returned all scores to my list they are sorted and then limited for my purposes

As well as adding in my best score logic and leaderboard I ensured that all buttons triggered events. This meant converting the FLabel to an FButton and in my case adding a transparent image behind the text for the hit state.

Day 6
To mimic the Astavoid app that is already in existence I applied the GoKit tween logic to my Flabels and FButtons for the transitions between pages / scenes. The transition effect is done within the constructor of the scenes FContainer class while I wrote a specific TransitionOut() method to handle the text and image objects movements back to the start. This works really well with smooth movement and some nice effects such as easing in and bouncing.

Day 7
Android was definitely an area that took a lot of development time up with the original release of Astavoid. The fragmented screen resolutions took some thinking and some adjustment in the code. While iOS isn't there yet its certainly heading in that direction which is why I was relieved to see that Matt had given it some consideration within Futile.

To tackle this I revisited by trusty tools of Texturepacker and Glyphdesigner and increase the size to be scaled appropriately for retina screens. I looked into Matt's Banana project to get a feel for the text sizes he used for this project and played around with my ratios as I had three different text sizes to his one. From this I setup the AutoSD feature of Texturepacker which works to the principle of largest size and then scales down the different ratios as are relevant.

Obviously we would work to the Retina x2 (or even x4) normally but I haven't had a chance to go back to the drawing board on the graphics so just want to work out the logic for the resolution switching.Highly recommend if you are starting out you work to the largest resolution. There are lots of guides out there but this one is pretty useful.

The result being that I have simple parameters set as part of the Futile init that determines the width that is relevant to that resolution, the scale factor and the suffix of the atlas file to pull in. For debugging purposes the scale ratio and the file being used is echoed to the Unity console so you can make sure you are scaling correctly.

A pretty productive first week I think you agree. I have learnt loads in this time and while have lots to learn I feel confident of getting this simple game ported.

Thing to note is that Futile is in its infancy at the moment so documentation is pretty light. However I found Matt Rix (@Mattrix) and Whitaker Trebella (@wtrebella) of Polymer fame, to be incredibly helpful with my annoying question. I can also help with the basics and can be found at MyGamingProject @gameproject10k where I will be happy to help. Part 2 can be found here covering Collision Detection, Multi-touch and sound will be tackled. Another busy week :)