{"id":341,"date":"2017-04-03T15:14:39","date_gmt":"2017-04-03T15:14:39","guid":{"rendered":"https:\/\/projects-old.etc.cmu.edu\/blueprint\/?p=341"},"modified":"2017-04-03T15:50:26","modified_gmt":"2017-04-03T15:50:26","slug":"week-10-iterating-for-playtest-day","status":"publish","type":"post","link":"https:\/\/projects-old.etc.cmu.edu\/blueprint\/index.php\/2017\/04\/03\/week-10-iterating-for-playtest-day\/","title":{"rendered":"WEEK 10 – ITERATING FOR PLAYTEST DAY"},"content":{"rendered":"
\u00a0\u00a0 \u00a0We got some feedback from the halves presentation. The most important thing was, although we made tons of iterations on every details, we didn’t changed the table at all through the whole semester.
\nSo why we need to use the table? That is a problem to our faculties. Three reasons on keeping the table are:<\/div>\n
\u00a0 \u00a0 1. As it is in the Sims, there is a defined space for players to build their house, which is a preset size of an empty space. We will need to keep the lot while build the other functions on it.<\/div>\n
\u00a0 \u00a0 2. The lot is a flat area where players can construct houses, a table would be a good choice to hold this flat space.<\/div>\n
\u00a0 \u00a0 3. We definitely thought about put the lot on the ground, however, as we tried and playtested, it was too hard to reach that low and see objects clearly enough from the distance.<\/div>\n
Other than halves, we were iterating and fixing bugs for our big ETC playtest day on this Saturday!<\/div>\n
Feedback from playtest day: generally, people loved it. However, as we were observing, no one wanted to clip through the table to reach the other side. This means we may need to either change the size of the table or shrink the lot itself. Besides, when people activated modes, it was hard for them to figure out how to turn it off. To make this more intuitive, we may need to tweak the UX flow in this part a little bit. One interesting finding was that at the beginning, when players finished building their room, instead of opening the drawer, they would ask “what are in the drawer?” and “where are the furniture?”. We will think about solutions on this part next week.<\/div>\n
Programming wise:<\/div>\n
\u00a0 \u00a0 1. We tweaked the UX flow a little bit. We found it was very confusing for players to turn on\/off modes. So right now, the program will turn off all modes when players reach the drawer handler or objects in the drawers.<\/div>\n
\u00a0 \u00a0 2. It was a very serious problem when players want to interact with wall objects, the wall will move along with the objects. Thus, we added a new mode called “room scale” mode. Wall manipulation will only be active when players are in that mode.<\/div>\n
\u00a0\"\"\u00a0\u00a0\"\"<\/div>\n
\u00a0 \u00a0 3. Now players can change carpet color! Along with that feature, we changed the way of changing designs of objects. Before, we used physical objects to indicate different designs of objects. Now there will only be a color palette showing you all the possible designs of an object.<\/div>\n
\u00a0\"\"\u00a0\u00a0\"\"<\/div>\n
\u00a0 \u00a0 4. As promised last week, we implemented interactions for the in-room mode. We found it was impossible for players to physically pick up objects in the in-room mode, instead, using a ray-cast is both common in VR in-room scale and intuitive to select.<\/div>\n
\u00a0\"\"<\/div>\n
Art wise, we integrated all the objects we have for bathroom, bedroom and kitchen. We playtested with 3 ETC students. The result was astonishing, the buildings are actually look like a house now!<\/div>\n
\u00a0\"\"\u00a0 \u00a0\"\"<\/div>\n
\"\"\u00a0 \u00a0\"\"<\/div>\n
\u00a0Here is the demo video of our full experience!<\/div>\n
\n