There are as many ways to get into game development as there are game developers. The same could be said for teaching, writing, or literally any other passion. While my story is relatively unique, it’s possible that you, dear reader, may find that we have a number of things in common. Or not. Either way, this is my story, and if it sparks within you even the tiniest modicum of inspiration, I’ll have done my job.

Back in 2012, I began my first semester at the University of New Mexico, my thumbs tucked in the straps of my backpack filled with freshmen level books. I had decided to get my degree in chemical engineering. Why on earth would I do that, you ask? Well, the simplest answer is money. Leafing through the UNM course catalog, I found that, of all the four-year degrees, engineering seemed to pay the highest straight out of college. And of all the engineering disciplines, the most lucrative was petroleum. But in my imagination, that would land me out in the middle of some God-forsaken field, troubleshooting rusty old oil rigs and spending my nights parsecs away from anything capable of providing an internet signal. However, next to petroleum engineering, chemical engineering paid the highest, and word was that the demand for chem Es was astronomical. Employers were practically lined up with offer letters, waiting outside the graduation hall like vultures.

They say “for the money” is the worst reason to do anything. But what do they know? And who the hell are “they,” anyway? I had no other reasons, so “for the money” seemed like a pretty good reason to me.

So chemical engineering it was.

And I enjoyed it! Physics, mathematics, chemistry. All of it fascinated me.  And, perhaps most surprisingly, I was good at it.

I hung out at the algebra table, a spot where students could go for help from the TAs. Before long, I found myself tutoring other students. People actually thought I was one of the TAs. Eventually, the real TAs told me I should just apply to become one. So soon, the university started actually paying me to hang out and tutor students. I mean, I was just doing it for fun! And if I could explain it to someone else, it solidified my own understanding, so it was sort of my own weird method of studying.

I chose chemical engineering because I had no idea what I wanted to do. But while helping the other students, I experienced something for the first time. I couldn’t pinpoint it then, exactly. There was just something about that moment when the student’s eyes lit up, and the wave of understanding washed over them. Like a blindfold was lifted. They gazed upon their problem with a new set of eyes. I didn’t quite realize it yet, but I had found it. I had discovered what I was meant to do.

I started interning at a national laboratory. My mentor introduced me to Python programming. I picked it up quickly, and after writing several programs for her, she told me I was a computer scientist at heart. The book I learned from taught me Python by creating basic games. It didn’t take me long to realize that game development and programming were way more fun than solving chemical engineering problems. Soon, I wanted to be a game developer more than a chemical engineer. But I’m a sucker for the sunk cost fallacy.

If you’re unaware, the sunk cost fallacy is this: if you’ve invested time, money, or anything else into a particular endeavor, then later realize that the endeavor is futile, the smart thing to do is cease the endeavor. But since you’ve already poured so much of your soul into the endeavor, the tendency is to continue, to go all in, because all of your previous expenditures would otherwise go to waste. And one thing I just can’t let myself do is quit. So, I finished my chemical engineering degree.

So my internship turned into a full-time position after graduation, but I had continued my game development passion in the meantime. I taught myself C++ for the sole purpose of programming games in Unreal Engine. I even started making a portfolio so I could apply for jobs in the games industry. I needed something to show that I had expertise. That I was a problem solver, and that I was creative.

Something that’s always fascinated me about games is procedural generation. Spending hours and hours playing Diablo, I always wondered how they made algorithms that could spawn random dungeons and loot. So, for my portfolio, a challenge I decided to take on was to create my own random dungeon generator.

I spent nearly a year trying to figure out how they did it. Most of the techniques for procedural dungeons were at the time (and still are) proprietary. Therefore, it was up to me to figure it out on my own. This was one of the most frustrating (and growth inducing) experiences of my life. I actually discovered many computer science principles on my own in the process. I felt like Ramanujan when I later learned about them in a formal classroom (Ramanujan was an Indian mathematician who discovered many advanced math concepts on his own, without any formal training, finding solutions to problems that, at the time, were considered unsolvable). One such technique I discovered was the heap-in-an-array trick.

See, my experience with data structures at the time was limited to mostly arrays. But for my procedural dungeon, I’d found one of the few books out there on the topic, which explained that a dungeon could be generated by partitioning a space into smaller and smaller rectangles. You start with one large rectangle, rectangle A, and split it into B and C. The newer rectangles, B and C, are “children” of A, so you could create a graph, with A at the top, and B and C connected to it. This is before I learned about graph theory, or trees, but the concept was simple enough.

B and C could be considered two “rooms” in the dungeon. But you could continue this process, splitting B into two smaller rooms, D and E, and splitting C into F and G. B and C then become parents of their own two children, and thus, the tree grows in size.

You could go on splitting rectangles like this indefinitely. So, since I only had arrays, I needed to figure out how to store this tree, while still maintaining parent-child relationship information. I needed to know, for example, that room D was a child of B, which was a child of A, and so on. Well, I discovered that as I split up the room, if I added each rectangle to an array, I’d end up with the following:

Now, I knew that A had children B and C, and B had children D and E, etc. And After banging my head on the wall enough times, I discovered that rectangle i was always a parent of rectangles 2*i and 2*i + 1 (see for yourself... if B is at element 2, its children, D and E, are at 2*2=4 and 2*2 + 1=5).

It was a handy formula, but eventually I hit so many roadblocks I had to put the procedural dungeon aside for a while.

But then I started taking computer science courses. My employer was kind enough to pay for me to take them at UNM. And I remember the day I sat in Data Structures and Algorithms when my instructor said: “and here’s the heap-in-array-trick” and my jaw just about hit my desk.

Because of that class, I finished the procedural dungeon generator. All of the techniques I was missing were taught in that class. The breadth-first search provided me with a way to connect each room with doorways. Depth-first-search allowed me to create hallway systems. Using stacks and queues for the rectangles allowed all sorts of clever tricks. And at the end of the semester, I showed my instructor my random dungeon generator.

That algorithm was perhaps the biggest feather in my cap when I decided to apply for game development positions. The company that ended up hiring me allowed a 15-minute presentation during my interview. I showed my random dungeon generator, and 15 minutes turned into nearly an hour and a half of me answering eager questions. “Yes, I ended up using a stack data structure to store the room nodes. Breadth-first-search to connect the rooms, depth-first search to create the hallways. Spawning room tiles was O(n^3) time complexity until I discovered how to make it O(n^2)…” That dungeon was the ultimate showcase in Data Structures and Algorithms techniques.

I landed the job, and working on a professional team gave me the experience I wouldn't have gotten from online tutorials and books. The Agile process, Scrum daily standups, source control and code reviews. Ridiculous water cooler conversations about time travel and whether or not Oreos qualify as sandwiches. By day, I was slowly becoming an actual software engineer. But by night, I started teaching C++ and game development. And in my eyes, that was my true work. I started creating courses. While I wasn’t programming at my day job, I was developing game projects and speaking into a microphone at my desk for hours, imagining millions of students around the world, ears perked up and hanging on my every word. Eventually, I took the leap and quit my job to be an online instructor full time.

They say money’s the worst reason to do anything. But what if you have no idea what you actually want to do? I didn't. Sometimes you’ve got to just find a reason, pick something, and start doing it. I’ve found that the answers will always come. You may not end up at your original finish line, but that's because the process will show you your true finish line. Get out there and do, and the thing you’re meant to do will find you. At least, that’s how it worked for me, anyway.