Much like the first half of the semester, the second half of the semester did not go as I planned. I had intended to focus on building a tutorial space, with a particular focus on how participants could navigate virtual spaces. Instead, my semester turned out to have much more of a focus on editing code than doing the initial prototypes myself: David produced the entire first draft of the first tutorial room and I spent most of the semester tuning up the code so that it would scale well when we build the plantation experience. During this process, it occurred to me how similar it was to a writing/editing relationship in literature. Because I didn’t have to immediately worry about the creative side, I was free to direct my attention to streamlining the code and building an intuitive infrastructure. Most of what I took from this half of the semester relates to a few design heuristics about where and how to store the information we need to run the experience.
The three main ideas I came away with are that information should be stored as locally as possible, scenes in Unity provide a natural unit of size around which to work, and scripts can be used for both information processing and information storage. Storing information as locally as possible is basically what it sounds like: For example, suppose I have some logic that is needed to have a sphere light up when it is targeted with the hand controller. I could either put that logic in a script that is attached to the entire scene or a script that is attached to a sphere game object. By the heuristic, I should put the information in the script attached to the sphere. Keeping information local prevents the scripts we’re writing from getting cluttered and makes it easier to swap out game objects and functionality. In essence, good localization of information cuts down on mental overhead needed to keep track of what everything does and helps improve modular design.
Related, I discovered that scenes in Unity provide a good way to ground a sense of scope and locality. Scenes lend themselves to thinking of three states of size, from smallest to largest: within a scene, at scene level, and between scenes. Within-Scene size usually pertains to game objects that don’t need to persist for the entire scene and don’t necessarily need to know about other objects within the scene. At-Scene size keeps track of information that is relevant to a particular scene, but doesn’t need to be transferred to other scenes. Between-Scene size is information that persists (surprise surprise) between scenes and has to deal with the state of the experience as a whole. Together with the previously mentioned “as local as possible” heuristic, I will first try to place information at within-scene scope, then bump it up to other scopes as it becomes necessary. The exception would be if it’s obvious that the information should be stored more generally in the first place, such as an inventory.
The idea that scripts can be used for information storage as opposed to information processing is a little more disconnected from the theme, and mostly worth mentioning because it is counterintuitive to how I have been taught to use code. In my formal education and resource, the primary and often only purpose of a piece of code is to take information and process it. Storage is mostly done in text files, CSV files, or databases. In the majority of circumstances, I do think these methods of storage are most appropriate and effective. Unity and experience development may provide an unusual situation where it makes more sense to store some information in the form of scripts: a lot of information that needs to go into an experience relates to a variety of disjoint events and triggers, which programming languages support better than databases or text files. It’s just taken me a while to arrive at the mental distinction between a script that stores information and a script that processes it.
Looking forward to coming semester, one highly relevant lesson I want to mention is how careful we need to be when it comes to scoping our project. At the beginning of the year, I thought I could have a tutorial room finished before fall break. Admittedly, I wasn’t able to find as much time to be in lab as I would have liked, but we didn’t even finish half of what we wanted for a tutorial experience in the full semester. What our incomplete tutorial suggests to me is that we need to hone in on what is really essential to the experience and focus on that. Although I will be doubling my official working hours next semester, I think it would be wiser to leave that extra time as a buffer for unexpected developments, rather than assuming I can get twice as much done. Regardless, I am looking forward to having the full team together and figuring out what we’re going to create.
Author: Zachary Segall
Zachary Segall ‘18 is a Math and Computer Science double major with a Policy Studies concentration. The Unity developer and C# programmer for the Uncle Sam Plantation project, he is interested in the intersections of technology, psychology, and social issues.
0 Replies to “End of semester retrospective: Using Unity for digital humanities projects”