As we finish up with our last week of development, we reflect on our progress and challenges throughout the semester.
The Good
Something that began well, and continued to thrive throughout was the comradery and respect among the team. We all were able to respect other’s ideas about the project and disagreements were resolved peacefully.
While our process was not very consistent (see below), we were still able to make reasonable progress throughout the semester thanks to our flexibility as a team.
We were also able to do a lot of playtesting throughout the semester, which was a good way to compensate for not having a dedicated interaction/game designer. We were able to iterate a couple times on different features and the frequent playtests helped make decisions easier, since we could sometimes defer to our playtest observations. Beginning at halves, we had at least one playtest with a naive user at least once a week.
The playtesters included ETC students and local art therapist professionals, which gave us extra useful information to pass onto our end-user Tom. Many remarked on how it could apply to different types of users that their art therapy study or practice was focused on, from people of color to children with autism. This was helpful because our experience was built for the average mostly-neurotypical adult, but VR for art therapy has great potential for many other audiences.
The final round of playtests were mock art therapy sessions to test our prototype somewhat in context. We began planning for these far ahead of time, and had a wealth of playtest experiences under our belt, so we were ready to manage the complexity of it when the time came.
The main takeaways from playtesting here were to start setting up systems (for scheduling), making connections (to get playtesters), and practicing processes (to run the playtests) early, especially if the playtests are very complex, like our last round of them.
The Not So Good (and Lessons Learned)
Process
One particular point of struggle was finding an effective way to track tasks. This was partially due to my lack of experience as a producer, the changing needs throughout the semester, and the team’s different work habits. In the first half, it made sense to have a Trello board in addition to a whiteboard since there was a lot behind the scenes I as a producer needed to plan for, and a lot going on in active development as well. We initially replicated the Trello board in some capacity, but it was hard to keep track of which task needed to be handed off to which person and when.
Eventually, I moved most of the tasks to my producer tracking, and kept the whiteboard focused on tasks for the current week. We broke our development into bi-weekly sprints, keeping things simple by having most deadlines on Wednesday or Friday. We also switched to a per-person breakdown of tasks, having everyone mark when it was due and who it needed to go to on the board so it was always accessible.
In retrospect, I might have tried an Excel document for digital tracking, since it provided more flexibility, and could allow us to archive tasks week-by-week, so that you can go back and see weekly progress in case a blog was missed, decision was unclear, or someone needs to find media/documentation from that week.
Another pain point in our process was reviews of people’s work. There was added difficulty coordinating schedules, since all team members were TAs for the first years. This made it difficult to have long meetings with the whole team, meaning that the review of someone’s work by relevant team members was often delayed.
Pipeline
Another major stumbling block was the lack of a cohesive pipeline. Design and code development continued for most of the semester in parallel, but didn’t interact very closely very often. There was a person serving as a link between artist and programmer, but design and the programmer had to communicate more directly.
In terms of the art pipeline, the lack of a consistent standard for models early on lead to some extra work replacing models and redoing environment layouts as our iterations continued, since most things needed to be manually re-scaled and re-arranged. There was also sometimes confusion looking for assets since folder and asset naming conventions were not completely standardized.
Playtesting Postmortem
Playtesting was a particular challenge for us, since our end-user needs involved group playtests in VR with somewhat naïve users, as well as some remote users. These are some key lessons learned:
- Set up connections early
- Calendly was a great scheduling resource to send a link to potential playtesters early and still be able to update the available slots at any time
- Practice–a lot. We did some practice, but there were still many moments where we forgot some aspect of set up or found it difficult to troubleshoot confusions/problems with naive VR users. We got a lot of practice by simply doing more playtests, but they definitely could have went smoother and faster with more practice beforehand.
- Set up is very important. This is the best process we arrived at: Prepare visuals to introduce playtesters to our prototype controls. Depending on the playtester, enter the app for them rather than starting them at the Oculus home. Begin wireless casting to a computer browser (better than link cable). Set up guardian boundary.
- Multi-User Hybrid Remote VR Playtesting. This was how we conducted our last round of playtests, which our “client” participants at the ETC and our NYU collaborators as “therapist” participants over Zoom. We tried to use the Oculus party feature, but that lead to echos for the “clients.” The best way was to use a hybrid of Oculus and Zoom audio to communicate, but due to the time it took to set up this, and wanting to respect our playtesters’ time, we end up using just Zoom and a microphone that could pick up sounds in the whole project room.
Technical Postmortem
These are some more specific knowledge points we know in hindsight.
- Standard for how to export models for placement in Unity. Makes it easier to replace assets when needed.
- Clear history
- Freeze transforms
- Set pivot
- Good UV unwrapping – uniform scale, no overlaps (important for baking lights)
- Create standard to scale models more easily
- Standards for how to import into Unity
- Unity model import settings
- Extract to Materials
- May need to recreate materials in Unity
- Unity folder hierarchy
- Enforce better
- Top level Materials, Models, Textures, Sprites
- Within top level, separate programmatically modified materials and textures from static art asset ones
Comments are closed