Design Reflections:

As the game director, I saw my role as one of balancing: allowing our production team at Second Avenue Learning to use their expertise, passion and background for design while ensuring that the voices of our Oneida collaborators remained at the forefront. Fortunately, I found many fantastic supports from my community. I believe this support came, in part, due to the extensive pre-proposal planning done for the project. While the game was ultimately funded by an NEH Digital Projects for the Public grant in 2020, a lot of brainstorming happened before we began the proposal process. I was eager to make an Oneida game, but I also wanted to make sure it was a game that would have value for my community. Together with supporters from the Oneida Arts program and the Community center, we kicked around a ton of ideas, considering everything from a game like Just Dance that could teach our dances to something that could teach raised beadwork (a traditional Oneida craft). While we generated a list of cool ideas, the thought of a language-based game, and particularly one that could share ka'nikuhli:yo seemed to have the most support.

I've researched and created games before, but working on a language game was an entirely new endeavor for me. My humanities advisors Kristin Arola, Carol Cornelius, Elizabeth LaPensee, and Emily Legg, were invaluable for keeping our focus on Oneida language at the forefront of the design process. For example, early on in the planning process our list of vocabulary words included all nouns—not just Sky Woman, man, turtle, and water, but also loon, muskrat, beaver, and geese. However, as our advisors reminded us, most Native American languages are heavily verb-based, and Oneida definitely falls into this category. Making the vocab list entirely nouns doesn't express the language in its own terms. Our list was revised, and while we kept some nouns in there, we added helped/helping, giving thanks, and having a good mind. Not only did this work in important Oneida verbs, but it also helped us bring the values more to the forefront.

In addition to sharing ideas, drafts, and prototypes with the Humanities Advisory Board, I shared drafts with my Oneida language consultants and knowledge keeps as often as possible. This allowed me to ensure that multiple perspectives on the design, mechanics, and word choice were heard. This led to some relatively minor but important changes. SPOILER ALERT: The muskrat dies. In our creation story muskrat dives down and manages to get the dirt for Sky Woman, but he dies in the process. This is an important element of the story, as it shows his sacrifice for our people. However, given the age of our audience, we were concerned about animating a dead, even recently deceased, muskrat in the game. We spoke with several Oneida teachers early in the design process who agreed that leaving his fate ambiguous was an acceptable way to handle the situation. We moved forward and wrote and animated this story with muskrat's fate left unstated. Of course, not everyone agrees on what an "ambiguously dead" muskrat looks like.

In the penultimate version of the game, one language consultant brought to us her opinion that upon returning with the dirt muskrat looked a bit too lively. We made the simple, but important, change of coloring eyelids on him. This is just one example of the many small changes we made throughout the project, as new insight from a variety of community members helped us to refine both the art and the mechanics of the game.

Completing the project entirely virtually (due to the Covid-19 pandemic) created its own set of challenges, but also its own opportunities. It forced us to move away from our original, carefully planned design document. As we did so, we were called to return to our design philosophies for guidance when making decisions about how to rearrange budgets and schedules, and how to move forward with the project. Ultimately, these challenges actually led us to focus more on how we could best embody good mind principles in this unexpected situation.

I have been an artist for all of my adult life. The Cyberworld was something I have been reluctantly drawn into, an alien space where I have mostly been uncomfortable. One day, I received a communication that told me there was someone developing a video game for Oneida and was interested in using my work for the concept art for this game. My initial response was half-hearted but with a son who is a video game enthusiast (who actually worked in the gaming development business), I decided to learn more about it.

I was introduced to Wendi Sierra, the designer of A Strong Fire. As she explained the goal of the video game, using Oneida traditions to help to teach and retain Oneida language and culture, I became an enthusiastic participant. After all, this is what I had worked my whole life to do, through my art. This would allow me to reach a younger audience as well as working as a mentor to a young Oneida artist who would also be working on artwork for the game.

It has been a truly amazing experience watching my concept art be transformed into an animated digital format by the studio artists. I had feared the changes that would be made to it, but was surprised and delighted to see it still looked like my art! I work primarily with transparent watercolor in a very controlled, yet ethereal style. I use Oneida stories and traditional art as inspiration for my work and so it seemed to fit seamlessly into the format that Wendi was developing. Sadly, I have yet to meet Wendi in person as well as Lexandria Metoxen, whom I mentored virtually in art and design, due to COVID. The best part of this experience is to be able to share A Strong Fire with my grandchildren, bringing their Oneida culture into their young lives in a relatable way.

The challenge of composing the music for A Strong Fire was exciting for several reasons. I was also proud to accept an Indigenous composer apprentice for this project, Christina Shulpa, a Diné high school student who was interested in learning more about creating music for games.

Composing for video games is not the same as composing for film because movies are edited and unchanging thereafter—the activity onscreen never changes once edited. The composer looks at film scenes, decides where to add music, and the music is matched to the film, frame by frame, to exact specifications. With game music, no such exact synch-up exists: the music accentuates whatever may happen in the playing of the game in a fluid way.

First, it was an Indigenous themed project, specifically Oneida. So I decided to develop musical ideas from the Oneida songs Robin Dance and Old Moccasin as cultural references with which the game players might be familiar. You can listen an Oneida verison of the Robin Dance created by our language nest here, and you can hear the Oneida Youth Singers version of the Thanksgiving address here.

Second, the music was intended to loop (repeat) several times, so I designed the beginnings and endings to start and end in a smooth way when looped. By creating rhythmic pauses in the first and final bars of music, the “looping” pause was heard as simply another pause (among several) and more naturally perceived.

Third, the outer menu music served a different purpose then the internal menu music. With the outer menu, a player would be choosing from among main selections but not playing a game; therefore the music could be more dramatic and bigger. With the inner menu, however, a player would be focused on a language or memory game, and the music required a contemplative mood, one that would not distract from mindful concentration.

It was easy to see the potential for a beautiful app when Dawn's artwork was first presented as inspiration. The challenge came in adapting its tangibility with the paper, linework, and watercolor to something digital that could animate on screens. We were also toeing the line between how complex we wanted the animations to be, and the technical limits of the platform we were building.

We wanted the story to feel alive and constantly moving, but also stay true to Dawn's striking poses and composition. To do this, I decided to approach our digital story the same way I would a real, illustrated storybook. I planned out the illustration and animation on every page, and hand painted every single frame. In the final app, we're able to have constant movement in elements like clouds, water, and Sky Woman's hair, but what really tells the story is the way the characters are posed and framed. It's wonderful to know that you could probably take a screenshot of any point in the story, and still see a unique and complete illustration.

In our minigames, we were able to include actual art painted by Dawn and her apprentice, Lexandria. This actually worked out in an interesting way. Since Dawn and Lexandria (Dawn's apprentice for the project) painted their art by hand on paper, we leaned into the idea of tangible game pieces. In the games, we can have their paintings displayed on cards or cut out slips of paper, which is just another element we use to make the whole app of A Strong Fire feel tangible, real, and relatable to the Oneida source material.

Developing for A Strong Fire offered some interesting challenges. The game format was the first major challenge. For this project we needed both playable games and an interactive visual novel. There are dozens of game engines that specialize in one format or the other, but none that excel for both. The designing for accessibility across as wide a range of devices as possible was a second major challenge. As a game developer, when I hear “game” and “wide support” I immediately jump to game engine Unity. Ideally, the best way to achieve wide support would be to design multiple different apps: one for the iOS store, one for the Android store, one for the Windows store, and one for any other operating system we wanted to support. Unfortunately, the scope of this project did not allow us to dedicate time to making apps designed for each operating system. This led us to decide on the most widely supported medium, HTML in a web browser.

Although the Unity game engine supports HTML as a platform, it exports into a format called WebGL. WebGL has wide support for standard laptops and desktop computers but is far less supported on mobile devices. Most mobile devices that were made after 2016 can run a WebGL game in their browser. Our audience, which includes both Oneida tribal members and elementary schools, offered a unique challenge though. After reviewing the devices available both to tribal audiences and to target elementary schools, we discovered that many people were using far older devices than we imagined. Not to mention that for some, the only way they had internet access was through their mobile phone that could be 10 years old.

By developing this in native HTML and JavaScript we could make sure we supported those old devices by following standards online. Not all functions and features of HTML and JavaScript will work on older devices. Luckily, much of this is well documented. A good example of this is our animation framework. JavaScript has many libraries we could have used to assist us in animating the visual novel. Unfortunately, most libraries use modern functions that are not well supported. To get around this, I created my own animation framework that allowed me to take sprite sheets from my artist and have them animate using her animations. To do some of the more complex camera work like zooming and panning to different parts of the scene, I used simple CSS animations as they are lightweight and will run on older devices. The goal here was to make sure all animations played as high quality as possible, and which had the least impact of performance. Just because in theory it can run on a 10 year old device, doesn't mean the hardware will be able to keep up if I write unoptimized code.

Some of the functions I needed to use to keep this optimized still would not run on older devices. I simply could have used slower performing code to do the same thing but it might be noticeable to our audience. Why should we punish the larger share of our audience just to support a small segment of it? To get around this, I used a strategy called writing polyfills. Basically, I would check if a certain feature is supported by the device, and if not, I had code that implemented that feature on said device. This would mean that that device might take a performance hit because it had to run many more lines of code to do the same thing another device can do in one line of code, but by using polyfills we were able to support older devices while not sacrificing performance on newer devices.

The older devices had another problem. Older iPhones have very little RAM. We determined that a non-insignificant amount of our audience would have a device with only 256MB of RAM. That's 256MB before the operating system and any other running apps are opened, so in reality we had to work with a maximum of under 200MB. In total, with all our assets A Strong Fire is around 300MB, and that is just for assets. To make sure this would run on older devices I designed an interesting loading strategy. In HTML you cannot explicitly delete an asset from memory. The best I can do is load assets incrementally and remove old assets from the DOM and hope that the garbage collector did its job when the device became maxed out on memory. Luckily for us, the garbage collector did its job.

The most interesting challenge for me was dealing with the varying screen sizes. Because we had such a large set of supported devices, these devices brought dozens of different screen sizes and aspect ratios. A Strong Fire is a full screen application, and especially so on mobile as every pixel of screen real estate matter at that size. Making sure the UI scaled properly and added black bars horizontally when needed was the first challenge to this. Once I got that working, the rest became rather easy. The way my animation framework was written, each animation was drawn to its own HTML Canvas element. The support for this became quite an elegant solution. All I had to do was detect the current screen size, compare that to our source aspect ratio, and resize the animation based on a ratio of current screen size vs source. Because each animation was its own Canvas element, this resizing is very low impact of performance and allowed me to have to write very little code to support this. I did not have to test this on dozens of different screen sizes and write bits of CSS for each edge case; it was all handled in JavaScript with a dozen lines of code.