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.
5 responses to “A More Efficient Ghost Communicator”
I don’t think efficiency is the only criteria for good code. Your code can be efficient, but if it’s unreadable and uncommented, it’s a nightmare to go through, add to, and change. In my opinion, commenting your code is one of the best things you can do for your project. Let’s say you drop it and come back to it six months later. You absolutely do not want to spend the first week of your return just dragging your feet through the hundreds of lines of code you can barely understand. You want to read the comments past-you wrote, comments that explain how all of the code works, and get right back to business. Also, readable code is super important. Good naming conventions for your variables, functions, objects, enums. Consistent casing rules. (EX: Camel case for variables, underscores for functions, etc.) You gotta have these things. Again, it’s not just for others; it’s for future you.
You might already know these things; I just figured I’d talk about it, specifically with regard to what makes for good code. Anyway, fun read!
Honestly, sometimes the hardest part of writing code isn’t figuring out the logic of how to do the thing you’re trying to do, but coming up with good names for things… especially wen you have multiple variables in the same scope that represent similar/related things but combining them into an array isn’t a reasonable solution for one reason or another.
And I confess, not adding comments is a common failing of mine.
Also, I’m a strong believer that the obvious bares repeating every now and then because people have a tendency to look for the unusual, especially when something isn’t working right, and thus miss the obvious.
What a terrific point! I agree 100%. I haven’t worked on coding collaboratively, but the engineers I’ve worked with all discuss things like variable name conventions at length with each other, because they live in that space every day and need to be able to understand what each other’s code does. For my code, I give my code blocks descriptive names I understand like, “Plays the Video” or “Pushes the Record Button” for exactly that reason. The better I name things, the easier it is for me to dive back in.
Re: coding strategies: as you say, looking for duplication is a big one. If you’re doing the same thing by hand lots of times, ask yourself if the computer could do the repetitive part for you. But there are some tricks to that…
Think about when (whether?) to remove duplication of code: if you try to generalize too early, it’s way more mentally demanding and you risk making the wrong things flexible and the wrong things rigid. Often it’s good to copy/paste code to several places first. Enough that you can SEE which parts change and which stay the same, but not so many that it’ll take you hours to find and replace them all. Creative people usually lean toward copy/pasting too many times; programmers not enough times.
Instead of writing a new function/script and trying to replace all the similar code pieces with it, try gradually editing all (hopefully only a few) similar pieces of code to make them MORE similar until they’re identical, and THEN pulling out the identical code. This lets you keep your code working the whole time until you’re sure you’ve found all the roadblocks to making them the same…
More generally: take a little time away from the computer to think about what you’d want if you could have anything. Negotiating interesting compromises between what you want and what your tools and skill allow you to build is easier if you know what’s important to you when you’re not distracted by a maze of technical details.
That’s some knowledge right there. Get the code to work via copy-pasting, then gradually make it more efficient over time as you see the commonalities. I like that approach!
Also, take time away from the computer? You don’t have to tell me twice! ^_^