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!