Part 1 of 4: Making a Game
The DayKnight 30 is a variation on the sort of one month challenge like the National Novel Writing Month that is organized and produced as part of the community activities of Day9.tv. It invites participants to choose a personal project and work towards goals for that project over a one month period. Projects pull from personal development, fitness, education, game development, art and music, and other similar areas. Many editions of the event have included group game jams, with groups of community members coming together to produce a game, often incorporating a specific theme. We provide tools and resources for planning these projects, structuring work throughout the month, and helping participants support each others efforts.
This is the first DK30 that I’ve been able to participate in myself. For me, though, I approach it from kind of the other direction of what is typical. The only way I’ve figured out to keep a large number of efforts moving forward, whether in physics, art or music, has been to be highly organized and structured in my day: I generally always am using the approach we use in the DK30. However, this time I had a small project that fit nicely into the time frame for the DK30, so it was a great chance to work alongside the community.
The project I’ve set out to complete is a small set of game audio assets, including both the sort of foley work produced for in-game FX and full tracks for in-game music. Further, I wanted to structure the project as if it was a small contract job, to get just a little bit of the flavor of producing assets for a client. After all, while I’ve a lot of experience in producing art for clients, I have comparatively little experience with producing music for others.
—-
This DK30 has a theme for game development, “Rise of the Machines.” Described elsewhere, some have encouraged participants to explore some of the ML/AI-powered art and music generation frameworks that have become popular recently. While I see some benefit to the tools, too quickly people have taken to both exploiting the tools (ex. passing off generative art as traditional in competitions) and leveraging the unresolved intellectual and copyright issues. Almost in lock-step with the rise of the NFT, people have also quickly moved to couch generative art in the language of the traditional, claiming the world should afford the same value (both philosophical and monetary) to digital and algorithmically-generated art as to that from traditional processes. For me, though, an intrinsic and necessary component to art, whatever the medium and media, is the process of the creation and not just the end result. However the painter expresses something, it is produced through a combination of their experiences, their training, their physical state, and the tools they choose. I argue that removing all of that removes the value of the art itself.
While a minimum requirement for my DK30 was a fictitious client with a game already designed, I’m always looking for story in something. I also wanted to represent some of the issues with artificially-synthesized art and to throw in a little bit of commentary, even if only for myself, on these systems and as part of the game. And, in typical style, any chance for a play on words is worth taking.
Consider, then, the rising of bread dough. I’ve titled my project “Bread Machine”, and have developed a bit of background story for the game, that of a machine that is trying to make bread, but ends up making something far worse by removing the result from the framework of the production. Tacking on as much meta-context as I possibly can, I crab Shelley, and explore some of the ideas behind Frankenstein’s monster, in the same way that generative systems derive from previous material.
—-
Before I could start the process of writing the music and creating the audio for a game approximating the above, I needed the game itself. I’ve had a little bit of experience with game development in the past, but the timeframe for this one was somewhat freeing in that I had very little time to actually stress about the design. I needed to put something together as quickly as possible, and as streamlined as I could make it. It was refreshing to not have production meetings and reviews, and to aim for the lowest bar I could.
To start, having built a fair bit of the SLAC National Accelerator Laboratory as a race track in Unity, I started there. I could have easily built the game in XCode, but while I have much more familiarity with Objective-C than C#, one can spend a lot of time dealing with asset import in XCode, and I knew that I wanted to target an industry-standard audio engine. So, Unity it was. Next I considered what would be some of the most simple game types that I could implement. I considered platformers, shooters and the like, but ultimately settled on a side-scroller like R-Type, Tiger Heli, or U.N. Squadron, games of my youth.
I knew that I wanted to write three pieces of music that would address three common use cases in a game: a cinematic track, a loading/menu screen, and a game level. I knew that the first two would come later and need very little from the game engine, so I focused first on building the game level. Dropping into Blender, I made a background tile and a couple of pieces of geometry to represent the player avatar and some enemies and a boss. Once I got all of those models into Unity as prefabs, I hopped over to Illustrator and made some projectile art. I figured there should be a way to import a sprite sheet in Unity. Once I figured that out, then I made a four frame explosion and figured out how to import that as a sprite animation.
With the visual assets created, I then started wiring everything up. I’ve done a ton of animation in code working with my live 3D compositor, Collider, so the movement of the pieces was easy to implement. Further, I didn’t need anything beyond simple hit detection to eventually trigger sound events, so as soon as I had colliders and trigger events, and a little bit of game logic, I could call that enough to move on.
—-
Having created a game (simple as it was), I was officially ready for the start of the DK30, at which point I would be focusing almost entirely on audio. I didn’t necessarily know where that would go (or even whether my studio would be operational during the DK30), but it still felt good to finally participate in the event. In the next installment of this series, I’ll be focusing on the start of the audio production for the project.
