We’re currently working out the art style for our next iOS game and so I thought this would be a good chance to try out ambient occlusion as a way to bring some interesting lighting into the levels. Since I had never worked with AO before, my first step was to do a test render on a scene in Maya as a proof of concept and as a way to get a better understanding of how AO works. I ran across this tutorial on Youtube which does a good job of explaining AO and shows how to tune the options to get a nice render in Maya. Note that I didn’t place any lights in either of the test renders, all of the lighting is created entirely with ambient occlusion.

Here’s what my test scene looks like rendered in Maya (click to see a larger image):

The next step was to try reproduce those results in Unity. Thanks to the Beast Lightmapping tools which include settings for ambient occlusion, the process was pretty simple and generated lighting that is pretty close to the Maya render. Here’s the same scene with AO lighting information baked out in Unity (click for a larger image):

One difference that you may have noticed between the 2 scenes is that I removed the foreground wall from the Unity scene because it was causing the background to be darker than the background in the Maya render – this probably has something to do with how AO is calculated on interior spaces in Unity, something I’ll need to investigate further.

This blog post is part of iDevBlogADay, a collection of indie developers writing about their development experiences.

How to Enter For Your Chance To Win A Free Unity Book:

Packt Publishing is giving away copies of their best-selling Unity books to 6 lucky winners! All you need to do is head on over to Packt Publishing and read the descriptions for both the Unity 3.x Game Development Essentials book and the Unity iOS Game Essentials book (you can also download a sample chapter). Then come back here and drop a line via the comments below to let us know what interests you the most about these books. It’s that simple!

Contest Deadline: The contest will close on February 15th 2012 PT. Winners will be contacted by email, so be sure to use your real email address when you comment!

<!–<!–<!–

The developer in question is Anton Sinelnikov.  His website link from the app store takes you here (some of his links take you directly to his gmail address).  This website gets you to his Facebook page and his Google+ page.  The question is, is this a real person or a facade for some bigger developer sweat shop?  I didn’t download any of his games, so I’m imagining none of them were of any quality or even resembled the app they pretended to be.  However the facade in the app store gave the appearance of high quality.  That is, the icon and the one single app image looked legit and would lead the casual buyer to fall for buying it (if they didn’t bother to check all the horrible reviews or 1 star ratings).  UPDATE: Since writing this entry I’ve seen several youtube posts of the game play.  Seems pretty basic and rudimentary.

I am truly amazed that there could have been enough purchases of this game to drive it up to the number 1 spot on the pay list.  I question whether this person or organization had also figured out how to game the system.  Did this many people really fall for an app that cost $1 when the real version is freemium (or maybe we just don’t understand Apple’s ranking algorithm)?  How many thousands of other deceptable apps have not been discovered because they’ve never gotten ranked?  How many consumers have been taken advantage of thinking they were buying one thing and got something else.

There’s also the whole Tiny Tower and Zynga (Dream Heights) + Skyboard (Pixel Story) controversy.  The difference here isn’t that those companies are trying to deceive the consumer however.  They’re just out and out copying a successful product by a much smaller company than them.  NimbleBit should rightfully be concerned (and probably a little bit flattered) that someone has copied their idea.  Luckily they got recognized by Apple and have probably already made millions, but that doesn’t make it right that someone can come along and copy so easily.

How does a developer stoop this low?  I think with many Indies that ethics plays a very important part in our development process.  We know what it takes to develop something and we are respectful (and sometimes in awe) of what others have done.  I pride myself that all my apps have been original.  I don’t download a lot of games for that very reason.  So if I do copy something it’s totally unintentional.  But so far I’m pretty sure I’m the original trampoline game in the app store and if anyone ever copies me I would want to complain to Apple as well (although would they listen to someone who hasn’t been quite as successful?).  Certainly this developer knew he was being deceiving.  Certainly he knew at some point he would be discovered.  I always feel bad when I get a review where the consumer didn’t think they got their money’s worth (even on free apps — go figure).  How does this guy feel about all his 1 star reviews?  I doubt very bad.  I imagine his business ethics carry over to his personal life.  And this makes this guy a snake oil salesman.  Not a developer.  We don’t want him in our community tainting the consumers taste for our products.  While I don’t care for Zynga either, at least they build something reputable and in some people’s opinion… fun.

It was fantastic to see an indie triumph in the app store this week and have Apple recognize the violation.  Let’s all stay vocal and clean-up the app store so that we and the consumer can enjoy a safe and fun place to play!

Oh… and GO <insert your favorite super bowl team here>!!!

None of the solutions I found online worked. I tried placing some adhesive tape on parts of the microSIM in order to prevent an alleged shortcut (I can’t find the link that advised this), I also upgraded the iOS version to 5.0.1 9A406 instead of 5.0.1 9A405. The errors persisted.

The last solution was to go to the store. There is no Apple Store in Romania, so I had to take it down to Orange, the provider from where I had purchased it. Then the bad news struck: they would have to change the device and give me another one. That wouldn’t have been a bad news normally, but since they didn’t have it in their replacement stock, I had to leave my beautiful looking iPhone with them, get a temporary dumbphone instead for a few days and wait until a new iPhone shipment arrived. Apparently there were quite a lot of similar problems with the 4S that there was a waiting list,so leaving my device with them and waiting for the replacement shipment was the only way to go. And this might take up to 15 days.

I never realized how dependent I was of my iPhone, how addicted to its mobile internet browsing, my favorite games, the gestures, full screen keyboard or its UI, until I was forced, for the past week, to use a Sony Ericsson W302 instead. Phone calls are lousy, due to its meager speakers I can barely understand what the other person is saying; typing text messages on a physical numbers-only keyboard seemed like a punishment from hell. Internet connection doesn’t work (and I don’t have the will to make it work, as WAP-compatible websites are fewer and fewer).

Being forced to use a dumbphone made me appreciate just how much a smartphone has to offer. The always-reachable internet, the always-near entertainment, its ease of use and familiar interface – those are things you can’t just detox from. Not after almost 4 years of continuous iPhone interaction.

Is it a good thing? Is it bad? I only know that I am impatiently waiting for my i4S to come back from service. It can’t come soon enough.

For my own apps, I am a one-man shop, which means that my available time during the week to work on just my own stuff is quite limited. That doesn’t help when my ideal project includes all the best indie practices: good planning, good design, great art, and a great product! In my mind, it all works! In reality though… not so much. I just want to code.

Over the last couple months I’ve considered several ideas:

• Create something entirely new
• Update an old app
• Rewrite an old app
• Something in between

Create Something New

I don’t know about you, but my ability to generate new app ideas that are both compelling and achievable (as an independent developer) needs some work. Sure, there are plenty of ideas floating around in my head… but I don’t want to waste my time on something that I think is interesting, but in reality is going to have little appeal. Nevertheless, I think the best way to come up with new ideas is not to say “Let’s think of a new idea.” Truly, I think inspired ideas occur serendipitously, when you least expect them. My idea list (yes, I do have one!) has grown over time just that way…

Why not pick something off that list, you say? Well, keep reading…

Update an Old App

The apps I have on the App Store today (that are my own) are the same apps I first produced. Meaning, I’ve not created something new (for myself) in a while. Why is that? There are several reasons, not the least of which is that I took on some clients to do their apps and I have a full time job. It comes back to that available time issue. To varying degrees, my original apps have been updated. But by and large, not so much.

I have taken the time to go back to those old apps’ projects. It’s kind of a hoot to look at code I wrote when I first started iOS development! It’s amazing what I didn’t know. Or more to the point, I am always pleased to be able to say, “Oh, I would never do it this way now…”

So, updating an old app remains an option. There are two that haven’t been touched in quite a while that are candidates.

In hindsight, I’ve already done the update route with one of my apps last year. My Flashcards! app got a substantial UI update last year, and I have seen an increase in sales of that title. So the update route can be successful in an incremental way.

Rewrite an Old App

Rewriting an old app is different than updating an old app. The latter, to my mind, is more of a “tweak, build, test, and submit” kind of thing. Rewriting an old app, however, suggests more of a “create a new project, and re-use some of the old project’s assets and ideas.”

I have an app identified for this treatment as well, but it will have to be a secondary focus.

The Plan: Something In Between

Remember that list of ideas I mentioned? One of the ideas on that list is “the winner”, and I can leverage an old app for some of the mechanics. So in some ways, it’s an app rewrite. But it will actually be a new app, which I am excited about. And in conjunction with the new app, I will update the older app to cross promote the new app. I am excited about this plan, and I have already started writing a specification for what I want in the app, etc. I am considering all kinds of new things, and then I will whittle down the requirements to something achievable for a version 1.0 release. I am resisting the urge to “just code”.

In my head, I can see the path to achieving this plan clear as day. I just need to execute now.

There was a bit of a setback on progress as my daughter, my wife, and myself all got the nasty stomach virus that’s been sweeping across the country lately. While it was only a 24-hour illness, recovery took quite a bit longer. However, unlike before when I would have a break in development and have trouble getting started again, I was able to jump right back into it once I was able. How was I able to accomplish this seemingly impossible task?! Why, through planning, of course!

Having A Plan

It’s important to note that both Sheepstacker and Word Monkey were made without any planning or design documents. I began work on their prototypes, saw that they were good, and just continued on until we said, “Now this is a game!” Essentially, the entirety of the game designs had to be kept in my brain. And as you may know, the brain can sometimes conveniently forget things (especially my brain).

For this new game (which I’m calling TTG3 until its official unveiling), I realized that this method of scattershot design just simply wasn’t going to work. The game is somewhat of an RPG, and it’s made up of many independent gameplay systems and stats that all need to work together in a logical way. Additionally, we’ve decided that we’re going to hire contractors for the artwork instead of using pre-made art, and working with contractors means you really need to have a clear plan. Otherwise, you’re wasting the contractor’s time and your money.

So I started by creating a bunch of tickets in my issue tracker. I use Lighthouse due to the fact that it’s incredibly streamlined, allowing me to focus on the tasks and not on management. Each of these tickets is something like, “Create the design for the battle system” or “Create the design for player progression”. In other words, each ticket is focused on a single chunk of the game’s complete design.

At first, I began assembling a massive “game design bible” that was to include every minute detail of the game, down to the very stats of each character in the game. I quickly found that I was spending more time trying to organize the document than actually trying to write it. Instead, I decided to create a single document for each of the tickets I had created earlier. This way, each document remained focused on a single gameplay system. I also decided to keep the design documents in Google Docs so I can access and make changes to them from anywhere. Additionally, I can link to the actual documents in the tickets to easily reference them.

So far, this has worked wonderfully. It has not only kept me focused on a single task at a time, but it’s also helped me to plan out every feature of the game ahead of time. It’s important to note that these documents won’t always be strictly adhered to (as game development requires fluidity and adaptability); they’re simply guides for when I inevitably get to a point in production where I don’t know what to work on next.

Executing the Plan

Naturally, the next phase of development is to actually execute the plan I’ve laid out. Since we already know the requirements for the in-game art, we’ll be able to start the search for artists as early as next week.

We’ll be handling UI art a bit differently. Since the game is an RPG and is thus very menu- and UI-based, we’re going to prototype all of the UI for the entire game with temp art, work out the kinks, and then finalize our design before sending it off to someone to beautify it.

The overall plan for the next phase of development is to have all gameplay systems implemented and all UI prototyped in roughly a month. We’ve got a lot of work ahead of us, but with a good solid plan in place, I think we’ll definitely be able to do it!

Okay.

The name of my next game is Guys! Stop Pressing Buttons!

Is it sexist?

Sound off in the comments.

It’s been a long time since my last iDevBlogADay contribution. I’ve been (and still am) very busy, but wanted to share with you this code. I’m working on an endless platformer game (www.sewerwars.com) and i didn’t find any tutorial or source code to help me start with the development so I’m sharing with the Cocos2D community part of my code.

I did find a tutorial from www.uchidacoonga.com (some of my code uses snippets from this tutorial) which helped me understand how to move Box2D objects.

With this demo you will be able to:

- Create endless platforms
- Build platforms with different sizes
- Position platforms in random positions
- Assign three CCSprite to the Box2D platform (see figure 1)

The code is optimized for iPhone retina, but with some minor modifications you can make it work under iPhone & iPad screens.

If you find any bugs or can optimize the code please let me know!

Click here to download the source code.

A tactic can only be successful when it is properly deployed.  Which means that the general (you) must understand his troops (app) as well as his target (paying players).  A Greek phalanx, naval raking fire, and panzer bliztkrieg are all fine examples of successful tactics that have been employed.  Note also that in these examples, each tactic is impossible to deploy by the other example tactic.  In other words, just because Capcom could make money hand over fist with the Smurfs, does not mean that your game can leverage the same “troop” assets to achieve your goal.

Don’t be so quick to jump on the freemium bandwagon just because others have had success with it.  A smart general would never even consider using a tactic that his troops (app) could not properly execute.  Sure, you could use your archers to melee attack mounted cavalry, but that’s just stupid.

Really think it over, should you be giving your game away?  If you do give it away, are you hobbling it by making it an incomplete experience?  No one (or rarely) does someone want to play a game where they feel like they need to spend more money to really enjoy the experience.  If you think your game is worth something, charge for it.  If you make a good game, people will buy it.

Owner’s of Apple devices have shown that they are willing to pay for quality.  It’s your job to give it to them, not give it away to them.  That is unless you really know your troops & target, and it’s the best way to achieve your goal.  Not just because those guys did it.

Looks like 2012 is going to be a big iOS year for me. Here’s why:

A spiffy new job

I’m very proud to announce that I recently started a new position with Transcontinental Interactive as an iOS Developer. This is a huge landmark for me, as it has been a goal of mine to be a mobile developer at an agency for quite some time. If you read my blog entry “Aren’t You Glad You Learned iOS?” several months ago, you know that iOS pioneered my career change over the last 2.5 years and this is another landmark in that accomplishment. I’m really excited to improve/develop apps for some big name brands from Canada/North America this year. The experience will be fantastic.

Speaking of which, my past iOS experience/blog content has been almost exclusively related to game development. Other than some prototyping, I haven’t actually developed anything with UIKit, despite being well familiar. I look forward to gaining a more in depth knowledge about UIKit App development and hopefully sharing some tips.

An iOS marketing goal

Since I first got involved in the iOS App Store, it has been my goal to develop an strong understanding of the marketplace.
In the past year, I’ve done a decent job of being as transparent as possible about my personal experiences, sales and goals, but I can’t speak much for the market as a whole. This year I want to continue working at this goal but expand in a way that allows me to help share a greater wealth of information about the market as a whole. I’ll talk more about this at a later date.

A RPG game(system) in the pipes

While I’m not confident that I will be releasing a new full game by the end of the year, I will be working away at building a strong/flexible RPG foundation for another iOS game in the future. I’ve thought a lot about other genres, but they just aren’t my thing. Creating Pixel Fighters not only challenged me as a developer, it challenged me as an RPG lover. We, as RPG enthusiasts, have a real fixation on our systems, their intricacies and the strategies/statistics that make our characters the strongest they can be. One area that I think I failed with Pixel Fighters was creating a system deep enough to generate that kind of energy from its fan base, including myself. I also have a lot of personal gripes about the system’s flexibility. So the focus this year will be on getting a good system and prototyping ideas. A strong enough system should be able to play to many RPG game ideas. While I don’t expect to give away everything I’m doing, I expect to be sharing more details on the core of Pixel Fighters, its weaknesses and the direction I’m going next.

More iOS blogging to come

So with that, I’ll keep this entry short. Expect more blogging this year related to the topics above; that’s my direction this year