• Kylie Blair

Game Sketch: "Sugar Needs Sugar"


Project #2: Individual Game Sketch

“Sugar Needs Sugar”


For my individual sketch, I wanted to visualize and create a digital interaction with my experience as a Type 1 Diabetic. There are many web and mobile applications for managing Diabetes, educating about Diabetes as a chronic disease, and teaching the effects of Diabetes; but I have seen few applications or games where the character is a diabetic, or where you experience Diabetes as a subjective experience that relies on a more personal engagement.

The name for my game, “Sugar needs Sugar”, stems from a memory I have of my grandmother. As a small child with Diabetes, I oftentimes relied on assistance from my family and friends to manage my disease. When I was experiencing hypoglycemia (low blood glucose), my grandma would sometimes say “sugar needs sugar” (an endearing term she bestowed upon me as a child, which translated to “Kylie needs juice”).

Stage 1: Brainstorming

At the beginning of my ideation phase, I knew that I wanted to focus on storytelling, but still develop the mechanics of my digital game sketch; this would allow me to simultaneously focus on context, narrative, and visuals, while still giving me a chance to practice coding and scripts, an area that I continue to struggle with. I immediately knew that I wanted to create a 3D game, although I was unsure if I wanted a first-person or third-person controller. I prefer third-person perspectives and a third-person perspective would allow me to practice my ability to design, model, animate and code a character. Yet I decided that, were I to use a third-person perspective, I would lose the emotional connection enabled by first person perspective--something that embodies a diabetic experiencing hypoglycemia. With first-person perspective, I could literally share my view with those who have never experienced Diabetes or a hypoglycemic episode. After weighing the pros and cons, I decided to stick with the first-person perspective.

I also decided I wanted to use Unity instead of Unreal for game development. Despite my affinity for Unreal’s graphics, I have had some experience with Unity before, and overall I feel that there is more support for Unity versus Unreal. I also felt that I would learn code with Unity more-so than Unreal ( I believe learning the fundamentals of C# or JS will be more applicable than C # # or blueprints).

Overall, my refined storyline is a diabetic in need of a juicebox when she becomes dizzy. After a certain amount of time, if she does not receive a juicebox, she will faint. Overall, my game fits under various genres including exploratory, time-based, and scavenger hunt.

Stage 2: Pre-Design

As I moved forward with my theme, tools, and narrative, I decided to lay the basis for the visual components of the game. I knew that I wanted a more realist approach to the video game, but I thought it might also be interesting to incorporate some drawings or 2D animations through the beginning UI and menu screen. This would allow me to contextualize and briefly explain the point of the game, while providing more imaginative visuals to engage the player.

I always like to start with color palettes and quick sketches of my ideas:

Stage 3: Development-Tutorials, Scripting, Main Menu and Level 1

After getting a rough idea on my aesthetic theme and narrative, I decided to use my prior knowledge of Unity along with three different tutorials to begin piecing the different portions together: mechanics, narrative, level design, flow, and visual aesthetics.

The three tutorials I used for reference, and what I referenced:

Unity Roll a Ball Tutorial

  • Creating Triggers from objects

  • Disabling objects once triggered

  • Tallying scores from objects

  • Using tags on various game objects

Unity Survival Shooter Tutorial

  • Scoring Points

  • Player Health (I had a difficult time implementing this into my own project, but I would still like to reference this section, because in future iterations I would like to implement a health system)

  • Attaching audio to play after specific actions

Brackeys Start Menu in Unity Tutorial

  • UI for menu

  • How to create various pieces of the menu with buttons

  • How to switch from one scene to the next using a script

My first iteration involved creating the very basis of my level. I created a rigid body first person controller, a terrain, and cubes to pick up. The goal of the game was to begin with a blurred camera, pick up a cube that resulted in a scored point and turned the blur off, and destroy the game object after it is retrieved. Using the tutorials above (mainly the roll a ball tutorial) I was able to work through the basic mechanics and functions in my game that would be pivotal for my interactive narrative. I also very roughly placed the slides of information in the proper order for my main menu.

The main script I had the biggest issue with (and never resolved) was the health bar and timer. I wanted a timer to begin when Sugar entered a blurred camera trigger, and for the health bar to be mapped to a timer. If Sugar doesn’t get a juice box before time runs out, she will faint. If she gets a juice box, it resets the health bar (directly resetting the timer). I had issues creating this scenario without even incorporating triggers - less so with the timer, and more so with a health bar representation of the timer. I realized that, if I could not effectively code a timer and regenerating health, I would have a very difficult time attaching these to different triggers with different effects. I also wanted a “game over” stage at the end, but without the timer, I felt that it was unfair to say “game over” to the player without a set rule of when the juice needed to be picked up. After hours of trying to create this code, I decided to leave it alone for this iteration and explore it later on.

Stage 4: Replacing Placeholders with Assets

After completing a skeleton version of my game, my next step was to replace the primitive objects with my assets. My most important asset to create was my juicebox. I modeled the juicebox using Maya, and I used Photoshop to create the color and bump map materials.

I transferred these models to Unity, where I reconnected the material, added a golden point light for glow, and I added a transform script to make the juicebox more attractive by slowly rotating (the unity roll a ball tutorial helped me in this section).

After placing the juiceboxes, I imported a slurping sound from freesound.org to be triggered when the juicebox is picked up. I came across a difficulty in this scripting process: I couldn’t figure out how to have audio play for a piece that is instantly destroyed. In order to make this audio work, I altered my script to turn the juicebox off of active, rather than destroy the object.

My next step was to start building my level. I imported an audio track that my husband and I worked on together (soundscapes from freesound.org mixed with a track of my husband playing our kalimba), as well as materials I have acquired and created over many years for the terrain (asphalt, concrete, and dirt). Next, I imported these assets from the Unity store (all free):

  • Unity Standard Assets

  • Unity Image Effects

  • Unity Post-Processing

  • Polypixel Freebie

  • Unity Adam Asset packs

  • Various sky boxes (I found many were either too pixelated or didn’t work properly- classic skybox worked the best)

Using these assets, I built a small city section that included a wispy skybox, roads, sidewalks, buildings, a park, bus stops, patio areas, etc. with the juicyboxes dispersed randomly throughout the scene. I also used Unity post-processing to create a more cinematic effect for my scene, as I added heavy components such as depth of field, anti-aliasing, color correction, grain, and bloom, along with directional lights to set the environment and recreate the sunlight suggested by the skybox.

After creating a more polished level, I added trigger colliders with attached script (and destroyable objects) to create random fields where the camera blur is turned on (hinting at Sugar getting low). Therefore, Sugar gets low, and needs a juice. She gets low again, needing another juice, and the cycle goes forth for around 5 iterations (this is not so far from the truth- I too have had moments in my diabetes where I have gone up and down and needed multiple sugars to boost my blood sugar back to normal).

My last section to polish was the menu section. Here, I added the UI assets I drew in Photoshop. This included a logo, a brief introduction to Sugar and her Diabetes (with visuals), and what she needs when she gets low. I used one scene for my menu with multiple panels to cycle through, leading to a button that opens the level scene.

After playing through my scene, fixing collisions and z-shading issues, as well as spots where the player could fall off the terrain, I was able to see the full sketch of my game.

Stage 5: First build: massive failure

I decided to save my scenes and folder and create a build: unfortunately, the final build created a huge corruption within the build, as well as the rest of my file. While my build had glitch effects, material and lighting errors, and had insane lags during player movement, my project file turned dark and all of my assets disappeared (their bounding frame was still there, but the materials, visibility and ability to move them was no longer there). After many hours of failed attempts of debugging, re-importing assets, removing assets, and simplifying my project, I realized I could not fix the corruption within my file, and I would have to start all over if I were to have something to show the next day. Lesson learned: save ENTIRE project folders (not just the scenes) - and save them far away from the other files. While I am still uncertain of what corrupted my scene (my suspicion is that the post processing asset broke my render - I have read numerous people complain about this particular version messing up their scenes), I begrudgingly assume that this could have potentially been avoided if I had just saved the proper backup files to a separate disk. I guess this is a really hard lesson learned.

(Difficult to see in this image, but while my UI was working, my camera was corrupted, the lighting was altered, and all of my assets that are turned on and possess materials are present in the hierarchy, yet missing in the scene. I could not make adjustments to these pieces)

Stage 6: New Build, Final Game Sketch

My only steps moving forward were to create a new build, from scratch… in about 4 hours. As I began my new scene, I quickly became distressed because I couldn’t even use the same scripting files. They were corrupted and said they had “compiler errors” although they matched perfectly with my original code. I started fresh, quickly recreating my scripts, and slowly importing only the most vital assets. I steered clear from post processing, the Polypixel assets, the Unity Adam assets, and any other assets that didn’t feel essential. Instead, I created a much more abstract, stark, and almost futuristic setting for my game. I relied only on Unity primitives (terrain, cubes, planes) to create my models (except the juicy box), and utilized good materials, a sunset skybox, directional lights, shadows and a limited color palette to recreate my scene.

While my game sketch is much less detailed than its predecessor, I am happy with my results, and I know that I truly learned from this experience: I learned proper file management, I am more critical of Unity assets, but most importantly, I learned that I learned, because I was able to recreate what took me over 3 days in about 4 hours. I also feel like I learned more about the direction I would like to take this piece: while I am happy with my narrative and mechanics, I am interested in making less realistic, concrete levels, perhaps moving towards a hybridity of realism and abstraction, tethering my reality to my player and narrative rather than the environment in which they explore.