Lackluster Blog

Making Games

One of the trickiest parts of breaking into the games industry is that a lot of the jobs want applicants to have prior game development experience. I know that this is not always a hard and fast requirement–a lot of them will accept candidates with experience in non-gaming fields. The problem was that, at this point in my career, I didn’t have any professional experience, gaming or non-gaming. I decided that it would be a good idea to get myself some experience developing games.

I had read and fairly thoroughly researched the options available for a solo game developer and ultimately decided to attempt to make a game with Unity. Also, I had used Unity in a game development class when I was at university so I was fairly familiar with the interface and workflow. I tinkered around for a while and completed several online tutorials, but since I had no real direction, I never completed a project or even ended up with anything resembling a proper game.

Moreover, I may have been a bit too ambitious. I think one of my early projects was meant to be a 3D re-creation of The Curse of Azure Bonds. I spent most of my time modeling a full-scale copy of the town of Tilverton using primitive meshes before I eventually got discouraged and quit working on the project. Maybe, I thought, I should start a bit more simply. Once I dialed back the scope, I was actually able to complete a couple of simple windows console-based games.

Game of Life

The first of these was an implementation of Conway’s Game of Life. While it’s not really what I would consider a game (since there’s no way to really win or lose), it was a fairly easy project to ease myself into game development. The Github repository for this project can be found here.

As you can see, there is not a whole lot to this one. The main thing that I learned on this project was how to use a second thread for input handling. Under normal circumstances, I don’t think that would be necessary, but in this case it made sense because we are clearing and re-drawing to the console on loop iteration. This could lead to user input messing with drawing the board correctly.

Tic-Tac-Toe

Next, I coded up a console version of Tic-Tac-Toe. My initial implementation was for a standard 3×3 tic-tac-toe board and would just brute-force check for a win (or full board) after each move. I extended the program to accept user input for width, height, and win length. This caused the win checking to be a bit more complex, but I’m fairly pleased with the results. The checking is still entirely un-optimized and there are definitely some bugs in this code. For instance, there is no bounds checking for the width, height, and win length inputs (negative numbers are accepted with potentially disastrous results) and it is possible to input a win length that is longer than the width or height of the board. Also, in my refactoring, I forgot to re-implement the check for if the board is completely full and there is no winner.

Further Applications

Moving into February 2017, I still didn’t have a job–not in software engineering, anyway. I tried driving for Uber for a little while, but I ended up just breaking even most days. I eventually took a job bar-tending at a local brewery so that I could contribute, at least a little bit, to our family expenses. Luckily, we were renting a granny flat from some friends and our rent was ridiculously cheap.

It was at this point that I decided it was time to broaden my job search to include companies outside of the games industry. However, I made it a point to apply only to positions that I felt would help me build skills that would be applicable to game development (primarily, C++ roles) or look good on my resume.

This wave, I sent out applications to General Atomics, Microsoft, Northrop Grumman, NuVasive, ViaSat, Insomniac, Epic Games, and Cryptic Studios. Interestingly, Insomniac and Cryptic (game developers) were the only two that I heard back from this time. Both sent me programming assessments, Insomniac also included a text document with some programming and design-related questions.

The Insomniac programming assessment tasked me with implementing a memory manager in straight C. I banged my head against if for a couple weeks before finally conceding defeat. I emailed the recruiter to let her know that I was withdrawing my application and wished her the best of luck in filling the role. I then proceeded to search online for resources related to custom memory managers in C and C++. I’ll admit that, after reading multiple articles and chapters on the subject, I still found it to be a bit too arcane for my current understanding. Also, I think I even found an article by John Carmack in which he said something to the effect that writing your own memory manager is “not a good idea”. I’m probably taking that out of context, but it was good enough for me.

The test from Cryptic had two parts. The first was to perform mathematical operations on an input string based on operators contained in the string. I was able to come up with a brute-force solution for this portion and decided to go with that and devote my remaining time to the second problem.

The second half of the Cryptic assessment was to implement a method to link 2×2 square tiles in a manner similar to dominoes. The tiles could be rotated, but could only link to other tiles if they matched exactly on the attaching sides. I was, sadly, unprepared and inexperienced enough that I, once again, could not finish the assessment.

Based on my application/interview experiences up to this point, I was starting to think that maybe I wasn’t cut out for a game dev career.

Early Applications

I graduated in December 2016, but I’d started applying to jobs a couple of months earlier. For my first round, I applied to Riot, Bonfire, Epic Games, Activision, Blizzard, and Nintendo. I don’t think I heard back from a single one of those, apart from the auto-reply email from the candidate screening software.

In January 2017, I completed applications for Bungie, Daybreak, Disney, Naughty Dog, Zynga, Bioware, and Rockstar. At this point, I was tailoring my resume to each job posting–which was fairly difficult since I didn’t have any real experience–and composing unique cover letters to accompany each application. I guess it must have worked, because I got a couple bites this time. Bungie sent me a programming assessment and Daybreak contacted me to set up an interview.

The Bungie assessment was a bit taxing for my current skill set. If I remember correctly, they wanted me to implement a Boggle solver in C#. I had very limited experience with C# at this point but gave it my best shot. I reasoned that at least I could learn something in the process. I came up with a solution, but the execution was painfully SLOW. There was a soft time limit for submission and I had blown past it, so I submitted my code and hoped for the best. A couple of days later, I received an email thanking me for my time and informing me that they were proceeding with other candidates. Frankly, though, this was not totally unexpected.

I’ve always made it a point to not cheat on programming assessments. Specifically, when I’m given an assessment to complete, I do not search for an online solution before or during the test. I do, however, check my solution after I’ve submitted it. For the Bungie test, a Google search for “Boggle solver implementation C#” yielded a much more performant solution and introduced me to a data structure I’d never heard of: the trie/prefix tree.

The Daybreak interview was pretty exciting for me since I was a pretty big EverQuest fan, not as big as Ultima Online, but I was over the moon at the prospect of working on such a venerable project. I’m sure the only way I was able to land this interview because of a recommendation I received from an Daybreak engineer whose wife I had spoken with a few times at the local library during the children’s story time we were both attending with our babies.

I had my first interview (which I now know was just the technical pre-screen) with Jenn Chan. She asked me some basic C/C++ questions and I was so nervous (and inexperienced) that I’m pretty sure that I bombed hard. So, immediately following the interview, I emailed Jen to thank her for her time and apologize for my nerves.

It must have worked, because I got an email back from the recruiter at Daybreak to set up my next interview with Jenn, Lauren McLemore (Lead Senior Producer), Adam Schmidt (Senior Software Engineer), and Justin Michael (Senior Programmer on the EQ2 team). Before the interview, I made certain to review all of the questions I had been asked in the first interview–particularly the ones that I knew I had answered incorrectly or had just guessed the answer. I wanted to be prepared, just in case they wanted to revisit any of these topics. Moreover, I saw it as a learning opportunity. I mean, if they are asking these questions in an interview, they must be important for a game developer to know. One question that stands out in my mind is, “In C++ can you call a destructor explicitly and why would you want/need to?” (The answer is yes, by the way. The most common reason you’d probably do this is to perform cleanup on an object that has been constructed in pre-allocated memory with placement new).

The interview was virtual with webcams–my first experience with interview format. It was pretty cool to get to meet and talk to the developers of a game that I’d actually played and loved. But, I was still ridiculously nervous. All of the interviewers did a great job of setting me at ease, but I still choked when they asked me how to detect a collision between two axis-aligned squares in a 2D plane. A few days after the interview, I received a rejection email. This prompted my purchase of a used copy of Real-Time Collision Detection by Christer Ericson to brush up on the topic.