Design

.gitignore

@@ -28,3 +28,44 @@ sysinfo.txt
 # Builds
 *.apk
 *.unitypackage
+
+# Built application files
+*.apk
+*.ap_
+
+# Files for the ART/Dalvik VM
+*.dex
+
+# Java class files
+*.class
+
+# Generated files
+bin/
+gen/
+out/
+
+# Gradle files
+.gradle/
+build/
+
+# Local configuration file (sdk path, etc)
+local.properties
+
+# Proguard folder generated by Eclipse
+proguard/
+
+# Log Files
+*.log
+
+# Android Studio Navigation editor temp files
+.navigation/
+
+# Android Studio captures folder
+captures/
+
+# Intellij
+*.iml
+.idea/workspace.xml
+
+# Keystore files
+*.jks

Documentation/Design.md

@@ -0,0 +1,39 @@
+#Design
+
+##Statement of Purpose:
+
+VR-One is a mobile VR application <br>
+<i>which</i> helps students learn faster <br>
+<i>by</i> letting them create their own mind-palace in VR.
+
+##Persona (as reference tools!)
+
+Bob, 21 - Third year University Student
+
+"Russian 101 has got to be my GPA booster."
+
+Bob is a Computer Engineering student who is registered in first year Russian course as an arts elective. He is quite enthusiastic about learning this new language and wants to get a decent grade in the course.
+
+VR EXPERIENCE LEVEL: NONE
+
+
+##General Pointers
+
+1. Ergnomics for VR: Sitting viewing experience not standing.
+2. Be mindful of viewing angles during object placement.
+3. Be mindful of personal bubble space during object placement.
+3. Be mindful of stereo vanishing point for optimization.
+4. Avoid skinny font with a light weight for text in VR.
+5. Stick to medium and bold weight fonts.
+6. It is helpful if your text is fairly large.
+7. Be mindful of distance and scaling for text in VR.
+8. For best text viewing experience a good distance for text to sit at would be 1 unity unit, which is about 1 meter. (may vary from person to person)
+9. Due to pixel density issues it is critical to test text-viewing-experience on the deivce (it is slightly easy to read it on computer screen ).
+10. TESTING ON DEVICE for movements is also very important as it may cause dizzyness during VR-experience.
+11. Scaling your first object in VR is EXTREMELY IMPORTANT!
+
+
+##Ideas for Future Enhancements
+
+1. Teachers/Professors use VR-One to create interactive course material.
+2. Possible replacement for castles: Google Indoors or similiar resources.

Documentation/Standards.md

@@ -0,0 +1,6 @@
+Module-2 standards
+
+1. literal text strings in "res > values > strings.xml"
+2. dimension info in "res > values > dimens.xml"
+3. Android emulator "[insert common phone here]"
+4. Dimension units dp (unless something else is necessary)

Documentation/Team_Meetings/Meeting-minutes/February_18_2017.md

@@ -0,0 +1,13 @@
+Saturday, February 18, 2017
+1:00pm
+
+1. Module-1 report work assignment. (Google Drive)
+2. Module-1 video-recording.
+	a. Emre will work on video editing.
+3. Module-2 Aviral's idea discussion
+	a. Everyone agreed to work on the idea, VR-One, if it would fullfill module-2 requirements.
+4. Discussed suggestions for improving team-management for Module-2. Aviral, Emre, Adam and David agreed on the following suggestions:
+	a. No one person will do task-assignment. Tasks would be created in team-meetings mostly in the form of function specifications and posted in 'Github Projects' section. Anyone can work on them.
+	b. The person writing the function is responsible for it. They must put their name in the comments and must write unit tests for it before pushing the function branch into the master branch.
+	c. Any changes to data-structures/code in the master branch that doesn't belong to the person must be made after discussing with the whole team in the next team meeting. 
+5. @Marinah - as you had to leave early please read the meeting minutes and share your thoughts.

Documentation/Team_Meetings/Meeting-minutes/February_21_2017.md

@@ -0,0 +1,59 @@
+1. Module-1 retrospective
+
+	A. Focus on individual components -> seamless integration.
+		a. good example: map_rendering
+				- didn't care about UI
+				- didn't care about code-style/data structs
+				- tested with their own images
+				- seamlessly included to the code
+					- UI and data-structs integrated
+
+		b. whereas: Distance, time, calories and past trips
+				x did care about UI
+				x did care about data-structs
+				x tested with UI
+				x didn't work in the end 
+				x critical time spent on these functionalities
+
+	So it is recommended we follow the following:
+
+	a. Create functions with their specifications in team meetings.
+	b. Suggest major change to anything (code-style, data-structs, function-specitions, etc) in team-meetings
+	c. Limit each commit to similar type of changes
+	a. Work on controller + model not view. 
+	b. Follow coding standards in Github repo. (can only be changed in group meetings)
+	c. Github branches: when working on a new function(s), follow these steps:
+		a. Create a new branch
+		b. Comments the functionalilty
+		c. Write unit tests
+		d. Code
+		e. Pull request to merge branch into master
+		f. Pull requests will be reviewed with everyone in or before the meetings
+		g. Pull requests will be accepted in the meetings after careful review by peers
+		h. Delete the branches
+
+	BENEFITS:
+		1. Everyone on same page
+		2. Minimize time spent on debugging, integrating and maximize development time
+
+2. Sticking with mind-palace idea?
+	Yes
+3. Target Market?
+	Students and professors
+4. Idea name: VR-One
+5. Commit - 1
+6. Can phone processor handle VR environment?
+	Yes
+7. Role of DE2?
+	Bluetooth Controller
+8. VR experience?
+	Little experience but most stuff is handled by unity
+9. Further ideas:
+	Do castle + GameObject selection on android instead of VR
+	VR-One used for Language Course development
+10. exercises will be pushed to github but in seperate branches called:
+	exercise1
+	exercise2
+	exercise3
+	exercise4
+