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.

Week 1 Work Log

1. 29/2/12: 2 hours forming team outside of class
2. 29/2/12: 2 hour tutorial/workshop attendance
3. 1/3/12: 1 hour setting up google doc and sharing game idea
4. 3/3/12: 2 hour skype meeting about game ideas
5. 4/3/12: 3.5 hour skype meeting about game ideas
6. 5/3/12: 2 hour library meeting about game ideas
7. 6/3/12: 2.5 hour city meeting about game idea
8. 6/3/12: 1 hour power point slide write up
9. 6/3/12: 0.5 blog and email tutor

Reflection:

Initially I came into the unit with Lall Goh, but of course we need a total of 5 people in the team so before the first tut we found Yu-Chen who is an animator, and basically brainstormed games while waiting for the tut to start.

The tut itself was interesting for me because, aside from the introductory formalities, once we started talking about games and what common concepts are needed in everyone's game (fun, engaging, replay value, etc), I started to learn a lot more; and since I come from a programming background, it was pretty interesting how much more everyone else knew than I on games.

Meetings meetings meetings. We had some good ideas. I came up with one where your character's strength in a multi player co-op battle game was directly affected by the player's test scores (maths, science, english)  prior to the battle. One of the main ideas we came up with was a 2D co-op game  where each character was controlled by an individual on individual devices. Out main problem with this idea I discovered in out library meeting was the ability to maneuver correctly on an iPhone or any other touch screen phone. This was a huge issue if we wanted to go ios (which we all did for different reasons; mine was because I wanted to release an app game and be successful). So today I had lunch with Lall and we decided to do what we originally thought of months prior to semester; a mini game game untilising the sensor technology of the smart phones.

So we had the idea; but Lall wanted a theme. So I suggested a egg toy machine which pops out a random egg with a character and the character stars in 3 to 5 short mini games that you play consecutively. Then Lall came up with making it so that each character represented a machanic (or specific sensor such as tilting, touching, shaking, etc) so that when choosing to just play all random the player would know prior to playing which sensor tech would be used next.

We're still weeding out the kinks and exactly what type of mini games we want etc. For instance Yu-Chen suggested one where you are given a shopping list and then you see the shop and all it's items and quickly have to pop the items on the list into the basket and check out before the time; trick is that you only got to see the list right at the start so it's a bit of a memory game.

So for the next part we are going to have to find two more people for our team; and with this idea it will need to be 1 more programmer; and an animator (hopefully 3d proficient in flash).

But for my part I need to test viability of mini game ideas so I need to do some tests (tuts) on the engine we're most likely to use, unity3D; plus I need to port over a game created in unity3D onto IOS, Android, and Windows 7 phones and see what issues need to be addressed so that I can provide the relevant documentation during production for the final product to potentially be on all three platforms at the end.