Week 2 Work Log

1. 7/3/12: 2 hours pre-tut presentation preparation with power point slides
2. 7/3/12: 3 hours attended tut and saw everyone’s ideas as well as showcasing our own
3. 7/3/12: 1 hour After tut meeting where we organized tasks for each member to do in preparation for the week 4 presentation
4. 7/3/12: 1.5 hour Filling out our mini games ideas shared doc with details
5. 7/3/12: 0.5 hour Blogging
6. 8/3/12: 0.5 hour Bought (for free), downloaded and installed Unity3D
7. 8/3/12: 2 hours Researched review management for apps 
8. 8/3/12: 1 hour Created a new share doc for features and input 1 entry 
9. 8/3/12: 0.5 hour Inputting a new Windy Dress mini-game idea 
10. 9/3/12: 1 hour Sending off invite emails to potential team mates 
11. 10/3/12: 4 hours Youtube Unity Tutorials
12. 11/3/12: 2 hours Youtube Unity Tutorials Continued
13. 11/3/12: 4 hours Unity / Xcode set up issues
14. 12/3/12: 2 hours Set up issue solution searching and found
15. 13/3/12: 3.5 hours Making first app game
16. 13/3/12: 1 hour Preparing presentation slides
17. 13/3/12: 1 hour Blog update

Refection:

We honestly had only just changed our idea the day before, so we needed to make a presentation about it. So we came 2 hours before the tut and got working on the slides and what we wanted to say.

Our team is really good because we’re really strong in all three areas; programming (me), animation (Yu-Chen), and game design (Lall). So with that in mind I didn’t want to wait for the other two members to show up before we did any work; so I said, “look, we’re pretty solid on our idea so let’s get going and the next two will come along later”. Lall agreed because we talked with Michael and he basically said that he liked out idea; so Lall is more than happy to take it as a green light. So we sat down and mapped out tasks we need to each complete by this week with the aim of preparing a presentation for week 4. 

We are all to come up with mini games, and have created a shared mini games doc in google docs. I came up with the following game idea:

Say “Cheese” - A photographer (or character with a camera) on screen says “say cheese”, you have to say “cheese” loudly for the level to be complete. When it recognizes you said it the photographer’s camera flashes and the screen turns white; level is complete. As a possible added feature, if the device has a front camera, it will take a picture which displays like a Polaroid image resting on a table after the blinding white flash. To make it harder or switch it up it could say “say monkeys” or “say Boo” or something different each time so you need to listen for the cue.

Other than that I’m mainly in charge of proving technical viability; i.e. can it be done. So the first thing I need to do is test how hard it is to port a program to iPhone and android. And then I need to test each sensor technology mechanic.

But for the presentation I will be showcasing a working preview of the menu/screen system using a simulator through xCode. It will require some general setting up even before Yu-Chen provides the front end graphics.

Another idea I came up with is as follows:
Windy Dress - A girl in a dress is on the left of the screen, and a nerdy guy stands to behind her to the right. So when the player blows loudly into the mic a wind starts blowing up her dress like Marilyn Monroe and when it gets high enough the nerd will get so excited that his nose explodes in a fountain of blood. Level complete. Note: you must blow loudly and consistently enough otherwise the dress falls back down.

 

 

I spent a lot of time reading through an IOS developer's blog who once worked for Ubisoft but resigned to develop indie apps. In the blogs he basically gave away a heap of excellent tips about how to become successful in the app market and maintained that the most important part happens even before the app is downloaded. Pretty obvious stuff:

• Gate 1: The user likes and understands the icon
• Gate 2: The user understands the name
• Gate 3: The description is short and enticing
• Gate 4: The screenshots are understandable and beautiful
• Gate 5: The reviews are good

The interesting one is the reviews one because he's developed a method that asks the user "do you like this app?" and if they do then he sends them to a screen which prompts them to review his app with a link to the app review area in the app store; and if they don't then he sends them to a screen which has a link to an email send off so he can get critical feedback on any problems with the app. In doing so he makes sure that all the disgruntled users voice their upsets to him rather than on the reviews, and that all the happy users voice their pleasure on the review area. He jumped his review rate from 5 per day to 185 per day with a score of 4.5 stars of which only 1 review gave a 1 star rating. http://www.alexcurylo.com/blog/

I've created a shared doc called "features" which basically allows us to think about non-mini game features the app must have; I have added the following to the list:

1. Reviews optimization (as mentioned above)
2. Five Gates of download-ability (as mentioned above)
3. Multilingual (needed for release in non-english speaking app stores)
4. External Settings (found in the settings of the device)
5. User activity analytics (tracking the users activity; recording on phone database; and sending results to our online database when connected)

A lot of these things can be added later; but especially point 3 and 5 need to be thought about prior to development so they can be systematically implemented as we go. e.g: making sure all the text comes from a database can mean changing the language later on is as simple as altering 1 int variable (1 = english, 2 = japanese, 3 = chinese, etc).

Looking through the new skills slides I picked out the relevant candidates for our animator/programmer shortage and sent them each an email. In my email I didn't want to sound needy or play the sympathy card, instead I stated plainly what we are and do and explained that we expect a high level of enthusiasm and hard work from them; and if they're interested, then email me back. This way I weed out anyone just in it for a ride, and get like minded people. 

A copy of the email can be found here: https://docs.google.com/document/d/1P1pp8mkVFTsTUhyNXWmnRi8GeO45e-CdVT1GBUJN50g/edit

We only received 3 responses to the emails, and I think with this week's presentations people have been holding out to see what else is there. But of the three, all said they weren't sure if they were right for the job, 1 out right said he couldn't do it, 1 said he'd like to do it if his team fell through (best candidate too), and the last one didn't have the skill set to do it. So now we're relying on our presentation to get us through.

So over the week end I was doing unity tutorials, and while quite interesting I found that there really wasn't any nice playlists of tutorials on unity app game development. That being said I did do a tutorial which essentially gave all the code and assets for a game called schpooter: http://infiniteammo.ca/schpooter/ which was made to play on the computer. "w" and "s" were up and down respectively, with spacebar to shoot. As part of my viability testing (and one of my tasks for the week) I needed to see for myself that if I make a game in unity it can port over to my phone, and can it use the inbuilt senor technology of the device to operate.

Now here came the part that made me want to shoot myself in the foot, bash my head into a wall, and watch a whole season of "community" just to cheer myself up; unity hit an error when it got to the splash screen on my iPhone. And for a whole day I couldn't figure it out, I was following every step in the tutorials to the T so what was going on. So later my co-worker explained that with the upgrade of to ios 5.1 you needed to upgrade your xCode for it to use the debugging feature. But it still had issues, so in the end I found the solution. The programs needed the following versions to work together cohesively:

• ios 5.1
• unity 5.0
• xcode 4.3.0

When I finally got it all working schpooter came up on my screen. I quickly reprogrammed the up and down actions to respond to  the accelerometer, and the shoot to respond to touch. I was a little ambitious to think I could get the shoot to also respond to a loud shout into the microphone, but I tried anyways.