I don’t know if I’ll ever be able to program well, but my experience in Unity is helping me think more like a programmer.
The hallmark of good programming is efficiency. It’s one thing to write a program that works, but it’s better to write a program that works and uses minimal system resources, thanks to efficient code. The process reminds me a lot of writing. My first drafts, particularly ones I write quickly, are overly long with run-on sentences. As I rewrite, I take out unnecessary words (9 times out of 10 it’s “that”), shorten sentences, and make them more clear. It’s all part of the drafting process.
I started version 2 of the Hologram Ghost fresh. New project file, baby! No more “Net Cores,” whatever those are. I no longer needed Fungus, my old visual scripting environment. I built an FMV project with Unity and Playmaker for my first Doborog game jam. I purchased a voice recognition plugin for Unity a year ago when it was on sale, on the off-chance I’d want to remake Hologram Ghost. The pieces were on the board for Hologram Ghost 2: Resurrection. I just needed to find the best way to place them.
The first thing I did was play with the demo scene for Undertone, my voice recognition plugin. Unfortunately, I have no coding knowledge, so I had no idea how Undertone worked technically. But sure enough, the demo scene worked as expected. When I pressed record and said the words, “Look at my cat,” the words showed up exactly how I said them on screen in a text box. Perfect. The design of Hologram Ghost prompts the player to say a keyword like “yes” or “true.” I would tell the program to record audio, then search the text box for the correct keywords. If it found the right keyword, it would play the next video. If it didn’t, it would play a default, “I didn’t understand you” video in response.
My first instinct was to create a video tree in Playmaker. First would be a code block that says, “Play Video 1.” Then there would be code blocks directly attached to Video 1 for pressing record, searching the text, then sending the player to Video 2, Video 3, or Video Huh?? I started designing this, but an hour in I realized how woefully inefficient it all was. I was repeating duplicate functions multiple times. More importantly, I thought about a future version of this game. This tech demo has six videos, but what if a polished game was sixty videos? Or six hundred? Say I wanted to change it so Video 30 went to Video 54, instead of Video 367. I would have to do a lot of monkeying around in the visual script editor. I was getting flashbacks to Dorian’s horribly inefficient visual novel scripting system. Never again.
It didn’t take me long to figure out how this project should be built. The game does the same thing over and over again. So I should have one code area for Playing a Video, one code area for Pressing Record, one code area for Searching the Text Box, one code area for Prepping the Next Video Based on Discovered Keywords. Only the values change (video file, keywords), so I didn’t need to repeat the same code over and over again. I just needed a way to tell the program what values to plug in when. And it hit me. I needed the sword at every narrative designer’s side. I must unsheathe… my spreadsheet!
I would list all the video files in the first row of a spreadsheet (ex. “00_Intro”). Then in the first column, I would list all the keywords (ex. “No”). Under each video header, I listed which video to play if the player says a specific keyword. So, for example, if the player says “no” during 00_Intro, then it plays “4,” which the system knows (thanks to an array in the game) is video 04_Banish. (That’s the video where I yell at the player for refusing to help me figure out if I’m dead or not. That’ll show ’em!) Using a spreadsheet meant I could easily change the connections between videos and their keywords without messing up the main code.
I had so much trouble figuring out object dragging and collision in Motion Picture. By comparison, getting the game to parse a CSV file was a snap. There was a perfect tutorial for doing this in Playmaker on YouTube. I followed the instructions and it just worked. It makes me think I should choose future projects that are more database-y (ex. visual novels, simulators), as opposed to action games with dreaded collisions.
The more difficult challenge was the idea of buttons. The Hologhost’s final form would not have a mouse or keyboard. Everything should be controlled by voice. However, the plugin works by pressing a record button. Since I don’t know how to program, I couldn’t change how the plugin worked. My first idea was to have Playmaker virtually “press” the button. I thought that would be a thing, but it was not a thing. There are no Playmaker actions for virtually pressing a button.
My next idea was to have Playmaker run the script associated with the button. This was warmer. There were several different actions for running a script. They were all a little confusing and none of them appeared to work. It took a lot of fiddling, but eventually I figured it out. The way I programmed it to work is that, instead of the player clicking a button to record their voice, Playmaker runs the record script at pre-planned times. It records everything said for a short window, then closes the script. When a video is ten seconds away from finishing, Playmaker runs the script. Luckily, the timing worked out for all six videos. If for some reason I had asked the player “Yes or No” twenty seconds before the video ended, I would’ve had to create a database of video times, too.
All told, I spent a month or less on the software side of Hologhost. No challenge overwhelmed me. The whole process was pretty fast from start to finish. I’m proud of myself for building the more efficient system. I could’ve built the cheesy version in a week, but I learned how to import databases and call scripts, which is sure to be helpful in future projects. Next would be the more daunting task…
The hardware. *Lightning Strike*
🎲 Your Turn: Did you have to solve a creative challenge recently? How did you do it? If you’re a programmer, what are your tips for structuring code more efficiently? What are other aspects of good coding? I’d love to hear from you! Reply directly to this email or leave a comment by pressing the orange button below.
Leave a Reply