Alleylight: Reflective Statement
Alleylight was, in many ways, a successful example of gameplay and design. Originally designed as a user-friendly way to light up or otherwise activate a dark alley, Alleylight as a final product has achieved this easily. Based on user testing and feedback, it is clear that the gameplay loop of the project resonates with people in such an intuitive way that the learning curve is essentially nil. On top of that, the active moving aspects of the app (i.e: the floating objects that the user hits) do provide enough movement that the screenspace is never completely still, and Alleylight is never not keeping the space active and moving.
Despite my initial billing as a project lead, my intention from the start was to minimize my role in the actual design of the final product, unless my input was strictly necessary to avoid a glaring design error. Nonetheless, my project lead status was due to the necessity of all other assets and pipelines conforming to the requirements of my technical limitations within Unity, for example the necessity of sprites to be a set perspective and consistent dpi (Unity Technologies, 2017).
Chief inspirations for my design processes came from lessons learned during the creation of previous projects, specifically the early stages of Matter and its Kinect and physics implementations. This previous project taught me to constrain physical objects on certain axes, and it also taught me to be wary of the Kinect’s tracking capabilities regarding microdexterity and accuracy (or lack thereof). Actual implementation of the Kinect was helped by tutorials from Andrea Sassetti (2015) and thenappingkat (2015). Some forum threads, such as one by techmage (2013) documented attempts to add collision to the Kinect’s depthmap visualization, which was my initial plan. However, their implementation was too complex for my timeframe, so instead I deferred to a simpler, more abstract implementation. This implementation used template code and assets from the Microsoft Kinect 2 SDK for Unity (n.d.), which was then reverse-engineered over time – a process made necessary due to a lack of proper documentation from Microsoft.
From my perspective as the programmer of the project, Alleylight is somewhat rushed and inefficient. Yes the end result works in every way that it initially stated it would, but I believe that certain components could’ve been constructed better, in order to make the end result more modular and simple for the end user. For example in the image below, each grey vertical pillar is a special object spawner that generates one specific type of floating object at a random interval (Unity Technologies, 2017) between two floating point numbers. However, because there are multiple types of floating objects, and they both need to be able to come from either direction, each side needs one spawner for each type of object, which generated a far larger logistical nightmare on my end whenever more items were added, and caused unintended behaviour because the object killzones behind the spawners were so far apart, resulting in a buildup of objects off-screen. Were I to improve on Alleylight in the future, I would consolidate these spawners into a single prefab per side, which picks a random object to spawn based on an array of available objects. This makes the entire project cleaner and more streamlined, but also creates a single script that I can easily genericize and re-use in a later project. The actual end-user experience that this issue creates, however, depends on whose perspective is considered. From the perspective of the person setting the experience up in the space, a more streamlined backend could potentially streamline their workflow somewhat through a simpler setup. But for the actual person playing, none of this backend work applies at all, until it generates a bug such as objects spawning inside each other.
Another feature I wanted to add as a secondary objective was a more modular interface for the end user’s use. This would’ve entailed a cursor-based system to position and/or scale the island based on the specific dimensions and obstacles present on the final projection space. Other potential additions include an interface to tweak the rate of objects spawning, the disabling and enabling of specific spawned objects, and more janitorial options such as clearing and reloading the scene, disabling the Kinect hardware, and any other specific functions that the operating end user may ask for. The decision to defer these additions until after the semester was due to their non-critical nature compared to core features such as item spawning.
Overall, I am rather happy with the state of the project at this time, as it not only clearly demonstrates the concept we created, but also has ample room to expand and evolve.
Unity Technologies. (2017, August 29). Sprite Render - Unity Manual. Retrieved October 11, 2017, from https://docs.unity3d.com/Manual/class-SpriteRenderer.html
Unity Technologies. (2017, October 06). Random.Range. Retrieved October 14, 2017, from https://docs.unity3d.com/ScriptReference/Random.Range.html
Sassetti, A. (2015, November 17). Develop a game using Unity3D with Microsoft Kinect v2. Retrieved October 15, 2017, from https://andreasassetti.wordpress.com/2015/11/02/develop-a-game-using-unity3d-with-microsoft-kinect-v2/
Thenappingkat. (2015, June 08). Unity Gaming: Integrating Kinect (part 3). Retrieved October 15, 2017, from https://thenappingkat.azurewebsites.net/unity-gaming-integrating-kinect-part-3/
Techmage. (2013, December 19). Using Kinect Depth map to generate collision mesh. Retrieved October 15, 2017, from https://forum.unity.com/threads/using-kinect-depth-map-to-generate-collision-mesh.218540/
Microsoft (n.d.). Kinect Tools and Resources. Retrieved October 16 2017, from https://developer.microsoft.com/en-us/windows/kinect/tools