Week 14 Work Log

1. 5/6/12: 8 hours perfecting games and adding
2. 6/6/12: 8 hours presentation preparation
3. 7/6/12: 3 hours presentation preparation
4. 8/6/12: 5 hours presentation
5. 8/6/12: 3 hours post presentation criticism work

Reflection:

So this week we pulled out all the guns. For 2 days we rounded up all the code and tackled the presentation. Nguyen and I tested and tested and tested, tweeking the game so that it works. There were some bugs that we fixed. But in the end, I'm glad we got so much done.

The presentation could have been better. Don't get me wrong, I think Lall did a great job, but I feel it would have gone better if we had chosen to go with 2 speakers (I was practicing up until the last min, but Nguyen said that Lazz specified only one speaker, so I stepped off the podium). I don't think it was so much that one speaker was a bad idea, but more that I could feel that Lall felt more at ease knowing I was there. 

Anyways, the whole time I was watching the red head chick writing stuff while Lall was speaking and I was getting a dreaded pit of the stomach feeling. Well as soon as Lall finish she put her head up and went to town on us! hahaha. We got absolutely burned. She said our game was essentially a tech demo and that for the amount of time app games have been out, the industry is way past a tech demo. She said that we had no glue holding out game together, whether it be a theme or a story line, there was nothing really defining one game from the other. She said she felt the themes were perverse and childish (especially criticizing the bully and windy dress ones). She said the windy dress would prevent the game from reaching the app store. 

THEN as if this onslaught of criticisms was a signal for laz and mike to bring out the big guns, Laz jumps in saying that each game is too short to be appealing, that people like the longer mini games because they're an addictive pursuit of perfection which we do not have, and (poor yu-chen though he tried to ease it) full criticism of the quality of our assets. Then Mike followed up saying he thought we were going to have many levels of the same game.

I am glad that the red head as well has the rest had were nice enough to address all of us and not just Lall standing up there by himself. And more importantly, I am extremely happy that we got such criticisms, and if I could for just 1 moment criticize the criticizers (specifically Laz and Mike whom I know are going to review this post but I'm going to say this anyway); where were these criticism earlier during the year during the countless desk crits and class presentations? Instead of just "you guys seem to be on track doing well" we NEEDED to know as harsh as it is that each game is too short, there's no replay value or appeal (and a collection house feature won't cut it), there's no unifying game theme or concept (and just the gachapon concept isn't good enough). That being said I get it, by a certain stage it was too late to tell us these things and we just have to work with what we're going for else we'd never finish in time for the end of year presentation.

Ok so back to the present; we get out of the class, sit around the table and basically all agree that the whole game needs a rework. We need a story line, we need players to have a goal, less games more quality (so upgrading micro games to mini games with multiple levels of perfection), unifying better graphics, appealing games but without crossing moral lines. A full rework is going to be huge, and is going to require every moment of the holidays to catch up and be ready for INB380. I'm excited; I'm pumped. I think everyone feels a little burned, and I know we elected Lall as project manager for the presentation, but really he and I are project manager (we kinda complement eachother), because... as much as Lall knows game, has great ideas, is super enthusiastic... he's not the most organized, doesn't exactly know how to organize people, and generally the two of us together work as a great team, but apart are a little lacking (each of us). 

So I told the team, I've created a google doc called "ideas and review" and expect everyone by Sunday night to have an app review (as suggested by Laz) up and possibly some ideas for the rework of Tiki Toki. I didn't get time for a review, but here's my idea (also below it I got my partner Stephanie to review and give criticisms). 

Morgan’s Ideas & Reviews:

So you're a character who's fallen in love, but the girl is like royalty (most popular girl in school) and so you have to become the best man possible in order to be hers (sounds a little like Bakuman, but anyways), so you have a master (possibly your father) who you ask advice on the matter. He reveals a special machine that has been handed down from master to student which will train you in all areas to become a MAN! (with an explanation mark). It's a gachapon machine, and inside each ball are toys that represent training tasks that the master has put in there. (the training tasks are mini games with multiple levels that start easy and progressively get harder). To begin with there will randomly only pop out 1 of two toys, but as you get high achievements in these training tasks the master will add more training tasks to the machine. Each time a game is introduced (including the first time the machine is revealed) master will explain how to play it and more importantly, how it will help you become a MAN right for the girl. How far you get each time you play will determine your overall level in that "skill".

• Players have a goal, to become a MAN (or a WOMAN.. possibly can choose gender).
• Players are addicted to the game by perfecting their 'skills'.
• Games hone skills relevant to becoming a MAN/WOMAN (e.g. "being able to remember all the special things she said you need to build your memory" so you play the shopping game over and over, getting progressively harder)
• As you get good at "skills" more minigames will be added, and as well as the master providing instructions on the new game her added, there will be a bit of story line included
• Storys are told by the camera zooming in on a manga like board and reading through (saves on animation effort, and makes it easy to change dialogue into different languages) - any noises characters make will be sound noises like "ahh" and "ooooohh"

Issues:

• Need to make sure crude sexual references are avoided
• I think we should be aiming for the younger market (15 to 25) and also the asian market (south east asia, korea, china, japan) because going for a market as broad as "everyone" doesn't help (trust me, I major in marketing)
• The above story might not be perfect (as in you may have a completely different story idea and I really want to hear it) but the important thing is that it ticks the boxes: a) players have a goal, b) they work towards perfecting the mini games we give them
• We need ideas of 'skill' enhancing minigames, no matter how random the skill may seem (as long as it's fun and challenging to play); but we need to make sure the graphics and characters appearing in the minigames link to the main story line

Thoughts:
Stephane Lee’s Thoughts:

• The high school boy/girl love theme has been done to death on only appeals to otaku
• Make the theme like antient japan or china so the gatchapon machine is really old anf made out of wood.
• There’s a suggestion for a different plot line. There was a boy who accidently unleashes all the mischevious ghosts. You’re a little boy in a village who has a master and you want to train to fend off these ghosts from your village. Before you level up (and get another game) you must first defeat a boss ghost using all the skills you have mastered. You’re defending your village through the ages, so each time you level up it jumps a little forward in time till it gets to modern age (and it’s subtle so you don’t notice that the world is slightly changing).

 

I think I really like Stephanie's idea of an antique gachapon machine (it's almost like it has mystical powers). I also like the idea of a mini boss with plot update each time you reach a certain level in your mini games (on defeat you get a new mini game). I think the team will come up with a better idea for the story line. I didn't have my heart set on boy meets girl (because of gender bias to target market), but I did like the concept of hero, doing tasks to become better for a goal.

 

I don't think anyone in the tiki toki team are disappointed with concept of a rework; we're all hard working, believe in each other and the game, and will do anything to make it the best. I know, at least for myself, that we have learnt a lot about our game, and how to make it. We've built a lot of skills, and now through the mistakes and trails, know how to make this game perfect. It's going to be a lot of work over the next month (we basically have to make the same progress we made in a semester, in one month) but I think we can do it. I'll probably keep blogging here, not for marks but just because it really does help me feel like we're getting somewhere, and mentally keep track of where that is.

Tasks Coming up:

• Reviews of current game apps (the more the better, we'll steal shamelessly mini games we need for our game)
• Perfection of game idea (coming up with a better story, a specific and perfect art form, an addictive game concept, and even sound and music decisions)
• Criticisms - call me crazy, but even though it's the holidays, I'd really like to run our game idea past Laz, Mike, and even the red head; it's not that we need their approval, I just need to know we've got it right this time 
• Project Plan (once the game idea is solid we need to divide up the tasks, put them in order, and just start knuckling down and doing it. I think we really worked great together on the days leading up to the presentation, and I'd like to set aside a day a week to do the same)
• Work Work Work - simple, just to each task and get it done

 It's been a fun semester, but I have a feeling that the fun is only beginning! 

 

Thanks

 

Morgan Kennedy 

Week 13 Work Log

1. 23/5/12: 6 hours Shake
2. 24/5/12: 6 hours Mic

Reflection: 
Finally have a little time to myself to just knuckle down and get shit done. I work really hard perfecting the code for both shake and mic. It wasn't so hard, except I really feel when it comes to the final version (next semester) we need to come up with a better way to animate. I did some research on sprite sheets and how to implement them. It's quite complicated, but I think it would be a better way to go.

Week 12 Work Log

1. 16/5/12: 2 hours pre tut meeting and development of presentation
2. 16/5/12: 2 hours presentation tut
3. 16/5/12: 3 hours hooking up windy dress assets to code

Reflection:

So far it has been a made week of assignments due, so while I wanted to do more work on this project I simply couldn't. Wednesday I have always set aside for INB379 work for the whole day and I managed to get most of windy dress working. I think the scariest thing this week is that both Lall and Nguyen were sick for the tut. I spoke to both before the tut and yeah, they were talking in a throaty voice you just can't fake. But I did most of the presentation, and we got a good review, which is nothing if we can't pull off the presentation properly come week 14. I expect that I will be working a lot more on this project after next wednesday because my final assignment (other than this one) is due on the wednesday.

Week 11 Work Log

1. 16/5/12: 2 hours pre tut meeting and development of crit
2. 16/5/12: 2 hours crit tut
3. 16/5/12: 3 hours hooking up shake attributes to code

Reflection:


Thank you so much Nguyen for helping me with Unity. He was a real helper for me this week because he knew Unity a lot more than me so he showed me how to hook up assets with code using the target attribute. Shake works, but the coins, and the code for the coins need to be implemented. A lot of assignments due next week so not much time to work on this.

Week 10 Work Log

1. 9/5/12: 2 hours pre tut work on shake code
2. 9/5/12: 2 hours tut presentation
3. 9/5/12: 3 hours work on shake code
4. 14/5/12: 2 hours implementation of current time attribute over update

Reflection:


Shake code was having issues due to the update attribute, but through much trial and error I managed to get it working using current time (or rather time since scene load) to play off. Haven't yet hooked up the animation effects.

Week 9 Work Log

1. 2/5/12: 2 hours after tut meeting
2. 2/5/12: 3 hours bully unity set up

Reflections:
Mostly catching up with all subjects this week but managed to just get into the end of our desk crit after landing in from Japan. Laz said we're good and up to date. Did a bit of the assets implementation for Lunch Time Bully. Thanks Yu-Chen for the images.

Week 8 Work Log

1. 28/4/12: 4 hours manga art research
2. 30/4/12: 3 hours windy dress unity set up

Reflections:

We went to a manga store, massive, and I managed to grab some for Yu Chen's inspiration. Also they had a "try manga out" stall where you can try and draw and be mangaka yourself! The internet was up and running on the 30th, so I managed to get some of the assets Yu Chen created and implement them into the scene for windy dress.

Week 7b Work Log

1. 23/4/12: 2 hours gachapon research
2. 25/4/12: 4 hours trailing Japanese mini games 

Reflection:


As of the 20th Kaylie (my daughter) and I have flown to Fukuoka Japan to meet up with Stephanie (my honey) and Ashley (my youngest daughter) and celebrate Ashley's first birthday on the 27th. Stephanie has only just moved to Japan, so there won't be internet here until the 29th! So as you can see by the images above I have been gathering creative assets for the project by taking pictures of the gachapon machines for main menu inspiration, and playing a heap of Japanese mini games at yodabashi camera, and arcades for inspiration.

Week 7a Work Log

1. 13/4/12: 5 hours mic test work
2. 14/4/12: 5 hours mic test finalise
3. 14/4/12: 1 hour Unity update that fixed the IOS 5.1 splash screen bug FINALLY
   

Reflection:
During the holidays I had a heap of assignments and exam prep to do, but I managed to fit in a mic test. So now if you blow into the mic the spaceship will automatically shoot. Main issue with it is that you have to dedicate a recording time (min 1 second), and then listen to the recording for how loud the person was blowing. This is an issue because it means that there's a lagg between when you make the noise and when it reacts. Might be able to rectify if I can take frequencies of the first recording during the second recording, of better still, if I can start listening prior to it finishing recording.


Biggest success was that unity finally broaght out its new release that fixed the ios splash screen bug. Not I can build 5 times faster, and debug in real time. This makes programming 10 times easier by far!

Week 6 Work Log

1. 4/4/12: 3 hours pre-tut working on getting the shake demo ready
2. 4/4/12: 1 hour Attending tut and presented our progress to the class
3. 4/4/12: 3 hours after tut working on getting a better working copy of the shake
4. 4/4/12: 1 hour making sure GIT works with everyone, especially nguyen
   

Reflection:

This week mainly was all about doing a heap of work at the start, because holidays were coming up and when they say "holidays" they really mean "work your ass out on assignments and exams that come up just after holidays". 

Anyways, I had to work hard to get the shake demo up and running by the time we were on for the class presentation. Which I did, though I felt a little bad because everyone else seemed to be on top of their work and ready. 

We did our presentation, and when we asked "and questions or criticisms" no one said anything, but then of course Laz jumped in to give us some criticisms. Ok, so in terms of Laz's crit, I'm not too sure if it's because he has high hopes for us, or because he just wanted to make an example of us, or because he really did feel about what he said to us... but he gave us a real whelping (verbally) about our progress, and I think all of us felt a little taken back. 

Basically Laz said that a) we've been showing the same progress, showing new little demo's about new mechanics, but when it came down to it the hard ones (mic and camera) are still not solid; b) we don't seem to be anywhere near completing our first game, and if we want to have handful of them ready by the end of semester we really should have at least one done by now; c) he's seen nothing but sketches and sketches week after week with no solid concrete hold on the game's final art style and assets. That being said, all very harshly I must add, Lall and I did spot Laz smiling when the slide with the transvestite in a windy dress came up. It's pretty clear to us that he really does like our idea, he just wants us to be getting on with it and making it right. 

Also, everything he said is true. I feel, for me, that this stupid unity glitch is really making me take twice as long to do anything. I feel that Yu-chen has a LOT of work to do, and in terms of what she's producing, she really needs some solid images pupping out. That being said Lall is in charge of the assets for the game and does not respond fast enough for Yu-chen; it should be, here Lall, look at these cat paws, Lall looks at it and circles which one he likes, "we'll go with this one" he says and hands it to Michael to vector, Michael draws it up in illustrator, saves it, then scales it for the iPhone, handing the asset to Nguyen (who's working on cat swipe), who then adds it to our assets library. Right now none of this has happened yet. Our assets library essentially has NOTHING in it. 

After the tut (which we dogged out early to work on our project) we all went to z block to work on our parts. Nguyen and I managed to almost finish two games (lunch money and shopping cart), we just need the assets.

Week 5 Work Log

1. 28/3/12: 2 hours pre-tut preparation for crit with power point slides
2. 28/3/12: 2 hours Attending tut and presented our progress to the teachers
3. 28/3/12: 1.5 hours After tut meeting where we organized tasks for each member to do
4. 30/3/12: 1.5 hours setting up a GIT SVN called BitBucket
5. 3/4/12: 4.5 hours Making the Shake Game Demo

Reflection:

We had out first crit in class. I think we did well because our comment from Laz was "well you guys are really on top of things" with Mike responding "yeah". That made Lall's day I'm pretty sure. I think we have done ok up until now, and I know Mike was really interested in the added mini game concept. Lall was eager to put on in for each mechanic, but I still have my doubts as to whether or not we will have time. We've agreed to add it into the plan, but in the event that time is slipping out we may have to cut it out of the initial build and put it into the exclude pile of features. In my mind, the key to having a good mini game is to come up with one that will be so addictive by itself that people will enter the app just to play it. In fact I recommend that all our mini games be designed with this in mind. As of now I don't think we have a mini game idea to this quality which is why I'm a skeptic as to whether or not this will be a added feature in the final project. That being said we are planning on chewing through this project during the Winter break, so I'm sure everyone will put some effort into coming up with a mini game that fills our criteria.


My tasks set for this week are:

• Set up SVN using my tropping.com hosting
• Create the coding basis (Shake) for the game "lunch money"

I took a bit of time working out how to get the SVN working on BitBucket; the good thing though is that it's free as long as its only 5 or less people using it, which it is. I'll be using Source Tree on my mac was the GUI while I think everyone else will be using tortoise. I've sent them all instructions on how to connect. I just hope they don't have any troubles, especially Nguyen.

Making the shake demo was a little difficult because I couldn't see if it was working or not (mainly because unity still after a month has not release an update fixing the splash screen ios 5.1 issue that has so many people complaining, including me). Anyways, I got an ok working prototype, but I need to work on it more tomorrow.

Week 4 Work Log

1. 21/3/12: 2 hours pre-tut presentation preparation with power point slides
2. 21/3/12: 2 hours Attending tut and presented our progress to the class
3. 21/3/12: 3 hours After tut meeting where we organized tasks for each member to do
4. 22/3/12: 1.5 hours Creating the basis of the game's database using a JSON object
5. 22/3/12: 0.5 hour Blogging
6. 23/3/12: 2 hours Database research, choosing LitJSON
7. 24/3/12: 2 hours Creating JSON database
8. 25/3/12: 2 hours Implementing JSON database
9. 26/3/12: 1 hour Database Testing

Reflection:

I think we did pretty good as a team for the presentation during class. We had a few questions from the class, but the criticism from Michael and Laz was pretty much "good". That being said Michael did come out of class afterwards and said that yes we were ahead and that's good, but he was worried that we'd finish the game before next semester and that we wouldn't have enough to do next semester to meet the learning criteria... or something along those lines anyways.


Afterwards we went and had our after tut group meeting, and although we did assign tasks at the end of it for each of us to complete over the course of the week; we mainly spent our time brainstorming how we can fill the void, or satisfy the requirements Michael had given us. But breaking done all the things we had to do it seemed that no matter how you looked at it we had a lot of work cut out for us without adding anything in. Lall and I really wanted to hammer a good marketing plan for next year, which included extra features like adding a language option, or having a free and paid version of the app, all of which needs to be thought of now and implemented as we go. 


But we did come up with two more features to the game to add depth, addictiveness, and replay value to it:

1. Unlock mini-games (only 4 all up) which can only be unlocked through sheer chance, or playing a lot. Essentially a mini game is different to the collection of micro games in that it's the one game played over and over again with levels, each becoming increasingly more difficult to complete. For instance Warrio Smooth Moves had a mini game where you had to balance falling objects on top of each other for a set period of time. We plan to have 1 mini game set up and ready to go for the end of semester.
2. The second idea was inspired by a game called locoroco, where as you played you unlocked items and characters which would then be available in a house found on the main screen. You could then drag and drop the furniture you found into the house anywhere you liked, and the characters would walk around the house interacting with the furniture, each other, and even the touch of the player. A lot of players are collectors, and this could really help give another purpose to the game. As well as that, we were thinking of adding a store where you can do in app purchases of tiki toki money which you can then spend on special items for the house, and in the future, special items for the characters to wear and use. The only problem with the house idea is that it's very graphically intensive, and therefore we will need to both reuse assets found in the micro and mini games, as well as keep the whole operation very simple for initial release. We plan to have the basic version prototype ready for the end of semester.

Quickly going back to the tutorial though. We all agree that other than ourselves, the only other interesting game there seemed to be the mad scientist death match game. Their idea has been really well thought out and they all seem really enthusiastic about it. I think their only draw back is that
their mechanics for some of their characters may not be doable in the UDK engine. They said they considered the crisis engine, but chose not to go with it. To do the things they want to do is possible in crisis but not in UDK.

I started working on the database, and at the start I didn't know exactly how to do about it. Our options were:

• Online SQL database
• PlayerPrefs plist

But we couldn't use the SQL database because it relies on users having internet access which is not what our game is about. So essentially we need to use the player prefs; but the problem I had with the player prefs was that it acted like a single dimensional dictionary. This was fine for what it was usually used for like turning vibrate on and off, choosing the overall volume of the game, etc. But if we wanted to say list all the micro games available, each with attributes of their own like name, locked/unlocked, etc; or if we wanted to list all the items available for purchase for the house with their own attributes like price, name, image file directory, purchased, etc. Simply put, having all that information one line will become ridiculously messy, but I did come across a solution: JSON. 

So a JSON object is basically a dictionary that can contain more dictionaries or arrays within it and as many levels as needed. The plan was to save the JSON object as a string into one field of the player prefs. At the start of the game the program will extract the string from the player prefs and convert it into a JSON object which is then saved into a global variable to be used at any time. Each time this JSON object is altered the program will automatically convert it into a string again and save it back into the player prefs; this way the most up to date version of the database will always be available. 


The JSON files needed for unity are called LitJSON. It took a while to implement it because it's not very well documented, but I did a lot of testing to make sure it works. Which it does. Woot!

Week 3 Work Log

1. 14/3/12: 2 hours pre-tut presentation preparation with power point slides
2. 14/3/12: 2 hours attended tut to re-present our idea with more detail into the theme, art concept style, and demo sensor technology; plus show some of our mini game ideas, all in an effort to get new team members
3. 14/3/12: 4 hours After tut meeting where we integrated our two new members (Michael and Nguyen) found in tut, into our team; and worked hard on Part A, and Part B.
4. 15/3/12: 0.5 hour Requesting UDID’s of current devices from team
5. 16/3/12: 1 hour Blogging
6. 16/3/12: 2 hours implementing a  new task/issue system
7. 17/3/12: 3 hours doing Unity Tutorials
8. 18/3/12: 2 hours doing Unity Tutorials
9. 18/3/12: 4 hours developing gyroscope demo
10. 18/2/12: 1 hour setting up website domain and company emails
11. 19/3/12: 6 hours developing gyroscope demo 
12. 20/3/12: 1 hours developing gyroscope demo
13. 21/3/12: 1 hour Blogging

Reflection:


The above video is a quick demonstration of my efforts last week. I basically wanted to prove to myself and the class that it was easy to attach the sensor technology mechanisms to these apps and that it could all be done in unity. I am quite proud of my progress.


The presentation went well, and I think the highlight were that laughs of approval I got when describing the bully game, and the windy dress game. Laz's comment (of course being the most important) was simply that it was a good game but we need to make sure that there's enough micro-games in there to make it worth people's while, especially for devices that can't some of the sensor technology (e.g. iPhone 3GS can't use the gyroscope). 

Of course the main reason for presenting a second time was in fact to get more members, and it worked. Michael and Nguyen approached us as we were going to Laz to request to present again in the next lecture. We took them on board. Nguyen knows C# and is a programmer; which means he can help out heaps with programming for unity. Michael has almost the same skills as Lall, but he does know a bit of animation and art development, and is willing to learn sound; so he could proved to be quite useful, though I think he will have to fill a lot of the animation/art void that we will have (i.e.: I think we will have to push him further and further into an area he may not be comfortable with).


After the tut we went to a secret place to sit around a massive monitor and pulled up the Part A and B Document. We spent the following 4 hours essentially filling out this document. Most of the time was spent weeding out issues with our development plan; including and excluding features; and generally getting pretty excited and happy about our idea. I'm please with the positivity of the group. I did notice though that ever since Nguyen and Michael joined the group Yu-Chen has become a little more shy than usual became less involved in the conversation. It wasn't such a bad thing because she did do work in the background; but from my experience when working in team, it is iterative that everyone participate in giving ideas and producing some part of the project initially, so that everyone feels like this program is THEIR baby. When this happens everyone works together towards the same goal. 


I feel that Nguyen, Lall, and Myself are all pretty clear as to the part we play and the ownership with have on this app; but I'm a little worried about Yu-Chen because she needs to own that head animator position over herself and Michael, and I'm even more worried about Michael because has a very support type role that falls almost exactly between Lall's and Yu-Chen's. Michael will be helping Lall with game ideas, the doc, and even with sound; and then he's meant to help Yu-Chen with developing some art, and possibly helping with 2D and 3D animation in Flash, and then implementing it in unity. As random as Michael's job sounds, he actually has the most to learn, and a lot of responsibility to help lower the risk of team failure.


In terms of my role in all of this; I feel I've almost taken a project manager role. I'm trying to implement a heap of organisational tools so that at any one time everyone know exactly which task they should be doing next. I've also taken a sort of head programmer role, but really Nguyen and I will both be working together on each project and getting things done efficiently and well.

This week I aim to make another test mechanic app. This time I want to test the following mechanics:

• Gyroscope
• Swipe
• Pinch

Which will be harder than usual because I do need a iPhone 4 to test the gyro, but I do believe my flatmate has one.

I spent quite a bit of time reworking the task system to include 2 things:

1. A main task sheet shared in google docs that shows each milestone, which shows each section within the milestone, which each have a series of issues (mini tasks) that need to be completed, who the issue is assigned to, and how complete it is. Essentially this spreadsheet will help the team see how much they have done towards completing the next milestone, and what exactly is still outstanding.
2. We created a shared dropbox folder for everyone, and I created an issues folder within it. Each issue in the spreadsheet above will have a unique issue number which is linked to a word doc within this dropbox folder. Using a template, the issue will have a title, detailed description (instructions) for the task, and progress updates from each contributing member. This helps a) document our actions in the project, and b) lets members assigned the issue easy see what needs to be done and what has been done after another member had previously worked on it. This helps reduce risk if say a member becomes ill, gets swamped down with other assignments, or needs collaborative help with said issue.

I implemented this system because it's a successful system used at my work; especially when we are working towards a deadline.

This weekend I did a heap of unity tutorials since Lall gave us them on a hard disk last Wednesday. I also bought the domain for the team:

www.tikitokitoymachine.com

I've set it up so that any demos we need people to test during production will be uploaded to the link on the site. People with the relevant devices (i.e.: those that have their UDID's on the provisioning profile) can click the link and have the newest version of the app download to their phone for trail, testing, and criticism. Lall has set up the facebook, twitter, and youtube accounts for marketing purposes. We will gather a list of family, friends, and strangers with ios and android devices to test our app at key points during production.

I also made an email address for each member of the team and a company email:

email@tikitokitoymachine.com

I managed to finish my gyroscope demo. It's still got a couple of glitches, but I'll spend some more time fixing them over the next few weeks. It's essentially the mechanic needed for our "find the moon" mini game idea. At the moment you can hold the phone up and look around a 3D world. It currently glitches up when you go past 90 degrees in any direction. I had difficulty programming this because I had to borrow devices with an inbuilt gyroscope (mine is an iPhone 3GS).


I feel I made a lot of progress this week. I aim to have the mechanics, and hopefully (dependant on assets) the whole menu system set up and running. I think we will really kick into gear when this happens because it will be like we created a platform for us to put our games in. Now all we have to do is fill it with games! Both Lall and I are really excited about this project and are looking further than the subject towards marketing and sales. For instance we both agree that since the second and third largest purchasers of apps in the world are China and South Korea respectively, that we will make sure that the translation feature is to implemented into the app from the get go. We will do the translations into Chinese and Korean two weeks before the official release. I plan to do up the website during the mid year break.

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.