The Challenge

Our company is currently developing a VR game called "The Raft" for StarVR, a proprietary VR hardware system for IMAX. The Raft is unique in that multiple players will exist in the same physical space while cooperating to stay alive in their environment. The setting is a haunted river in the deep South, and players don the roles of several rednecks sporting 80s-inspired technology.

I'm not a super fan of the theme, but it would have been really awesome to work on the project regardless. I particularly love cooperative games, and designing systems to encourage player behavior is one of my greatest strengths and passions. Despite asking, I wasn't picked for the project. That hurt, but at least I was given a month's respite on a toys-to-life prototype for Hasbro in July. I'm currently back on Bold Moves, and very anxious to move off of it for both resume and sanity reasons.

Lately the client has come back and challenged our studio to a match of Guns of Icarus, an online game that I'm very familiar with, and a frequent cited reference for the direction they'd like to take The Raft. Everyone at work seems excited by the opportunity, but I'm completely embarassed for us. IMAX assures us that we 'should beat them easily' in the upcoming match, but the message is obvious: 

"It's clear that you either haven't played or do not understand the source material that we constantly reference, despite months of design talks. We want proof that you have played this game and understand it."

This is a pretty embarrassing situation for us to be in, especially as professionals. We appear to have so little understanding of the game we're developing that we need to offer proof that we've at least played their most-referenced source game. I'd since accepted that I wasn't part of the project, but hearing this news this last week is extra disheartening. You don't have to have a passion for the specific type of game you're developing to understand the core premise of what you're trying to achieve. That's kind of what defines one as a game dev. Instead, we come across as software developers that just happen to write code for games, and the creative direction has to come from outside the studio because we look like we have no idea what we're doing.

I've been pretty frustrated with work lately. It's hard to have to stand by and watch the ball be dropped like this while being stuck on a game without any creative needs left to it. 

Interviews

I'm really fascinated by the interview process. Hiring the right person is possibly the single largest impacting factor on company culture. Almost by definition, good companies are made up of excellent employees.

A good company--especially in video games--will always be doing things to disrupt the market and innovate. Market disruption and innovation doesn't come cheap: it requires passionate, creative, and very collaborative team members. Employees that have these characteristics are constantly hungry to achieve and use their talents and energy towards creating incredible products. Good employees like this should be hard to keep a hold of. If you're not competing for their employment with another company, you're probably competing with the employee themself from going off to do their own thing.

Sub-par employees are the opposite: they're rarely thought of when looking for a high-performance role outside the company, and they are frequently satisfied with their environment. The end result for the company is that excellent employees will eventually leave for different, better paying, or more interesting jobs, while the company is left with the mediocre employees that aren't driven enough to do anything but stay in your company forever. 

To me, it seems that with every mediocre hire there's a permanent spot in your company that is occupied by someone who could have been an excellent employee. And with every excellent hire it's only a matter of time before they move on to something else. The only employees driven enough to leave are your excellent ones, and with every hire you run the risk of hiring a mediocre employee who will stay forever. It seems all companies run into the problem of 'mediocre decay'.

That being said, keeping your high-performing employees isn't an impossible task, but that discussion is for another post.

The thing that fascinates me the most about the interview process is how much thought we put into it while knowing that it's nothing like a job at all. An interview tests a candidate's prepared responses and, at best, tests their ability to think quickly and improvise thoughtful answers they hadn't pre-meditated. Yet it's still remarkably easy for poor candidates to appear the best fit in this environment. Candidates who are stubborn, rude, have low work ethic, or sub-performing can be considered top candidates after an interview process. It's not until a few weeks into the job that it becomes clear that this person was either a fantastic hire or a complete lemon. 

As a result, I always find myself reading any article touting information of good questions to ask potential hires. I can't get enough of it. As I find more articles, I'll add them to this post to start accruing a collection.

The 7 Questions Recruiters At Companies Like Amazon And Spotify Wish You Would Ask

Three Habits Of The Best Job Candidates I’ve Ever Interviewed
Never Take A Job Before Asking These 10 Questions
https://www.inc.com/jeff-haden/5-job-interview-questions-that-reveal-what-a-candidate-has-really-accomplished.html

Staging is Important.

Bug fixing data-driven gameplay can be challenging, and Chris and I have put a lot of time towards developing a process for the many stages that are needed to test before pushing to the world. To make things more complicated, Bold Moves will pull data from one of two servers depending on the kind of build that the game is published on.

For a while, our pipeline consisted of DEV, TEST, and PROD. The problem that arose from this is that we didn't have a safe environment to test data on the production server before releasing to the world. Each of these stages have their own manifest file, and without STAGING we had to test pre-live builds by manipulating the actual data that consumers were using in a way that also wouldn't disturb them. 

Very bad practice. 

At the time, TEST was pulling double-duty: it was for testing data in preparation for consumers as well as new features and back-end functionality. It was an appropriate test environment; TEST data rarely changed compared to DEV, and it was mostly the features that were intended to become live. The biggest problem with this is that TEST is on a different server from PROD altogether. We couldn't guarantee that all the necessary assets were in place before the new data hit live.

We've built in a few compatibility checks to the data that prevents the game from downloading out-of-date data, which allowed us to get around the problem for a while by preparing builds that were on a different version number on PROD. Ideally, Bold Moves development will reach a state where we rarely push new updates and deliver content entirely through server-side data. Without a change in code, we would have been unable to test new data on the Production server without consumers also seeing this data.

Data Driving Tools

Bold Moves is a data-driven game, which means that the content is completely separate from the code base and can be loaded in a separate step. It does some incredible things for us, as we're able to dynamically change level content and perform A/B testing just by changing a few files on the server that all the devices download from.

Currently, I'm the only person capable of managing the data on the server, and what data each device downloads. Anytime data needs to change on the server--whether it's test, dev, staging, or production data--I have to be there to make sure that it happens correctly.

I really hate processes like this, where one person is the only one capable of making changes to the game, so I've been spending the past few weeks developing some publishing tools to allow other people to make changes to data, as well. This next launch, Chris is going to do all the data management and give me feedback on how to make the tool more intuitive and user-friendly. The hope is also that we'll be able to identify the most important missing features of the tool and put time towards that, as well.

Lame Reward

Over the past year, I've helped develop and launch Bold Moves, a match-3 game for the Oprah Winfrey Network. It's been a really tremendous experience, and I've learned a lot about freemium models and data-driven gameplay. Bold Moves has been a huge success for the studio, and is actually RED's largest and most profitable game to-date.

As Bold Moves ramps up in success, it attracts more attention of people inside RED and at OWN. This isn't terribly surprising, but as more people come onto the project it feels like I have less and less control over the direction the game takes, and even what I spend my own time on. 

It's both flattering and frustrating. Chris and I worked to build this fantastic game that RED has never had experience doing before, and it works. Now that it's proven successful, higher-ups want to steer it in a direction to make it even more profitable, but don't want to "shake things up" by moving Chris or I off the project. 

Keeping us both on the game is a really lame call. First, taking control from the team actually developing the project is the biggest "shake up" you could possibly do. Chris and I have a history of making excellent games, and I feel like our reward is to stick around on one of those games without any say in it. Either he or I would be much better utilized in any one of the many incoming projects for RED. Second, there's really not that much to do on the game presently, and all the remaining work are things that a new hire could pick up perfectly well and still be excited by.

Highly creative team members require a lot of maintenance. They are like a fire, and you need to keep fueling that fire with exciting things to work on. I keep getting passed up for working on other projects because I did such a great job on this project that I can't be taken off. That's not much of a reward for doing great.

Determined Weak Link

I've since taken the job at Red, and it was a fantastic choice. Right away I jumped into level designing for a Cut-The-Rope clone game for the San Diego Zoo, which should be releasing to the app store within a month. Red focuses on fun, and frequently their clients pay up-front for a game without any monetization at all, so our job is exclusively to make the game as fun as we can. It's a dream come true.

After spending a few weeks designing all the levels for the SDZoo game (I was the only level designer, so I'm quite excited to see people's reaction to the game), I switched projects and jumped onto Onwords, a Match3/Hangman mashup for Oprah. I'm working on a team with Chris Rawson, who I worked with on Cyber Heist during grad school at the University of Utah. The promise of working with Chris again was one of the major draws to the job here in the first place, and Chris does not disappoint.

Chris is a very inspiring and extremely talented person. His work ethic is tremendous, and he's frequently the first person into the studio in the morning and occasionally even the last one out. His art background gives him a great eye for visual aesthetics and he frequently uses his art skills to help improve the games he works on, with or without another artist. Most impressive, however, is his command of code and knack for architecture while laying out the foundations of a game.

It's this that made me want to post in the first place. I don't have a degree in engineering and I'm far behind Chris' experience, which makes life hard and feel like I'm always catching up. Fortunately, Chris is pretty patient with me in explaining what I need to know in code structures that I haven't encountered before, but it puts me into a situation that I'm not really used to: Being the weakest person on the team.

Being the weak link is very challenging, especially when we're looking into tasks to divide up. I have to decide what I'm capable of when assigning myself to tasks, and many times I don't have a full knowledge of how to even accomplish the task. I regularly code-review with Chris to see what kinds of things I can do better and how I can improve, but sometimes it feels like it might be faster for Chris to have done the work himself from the beginning. In the end I definitely contribute, but it can be painful to divide the tasks up for a sprint based on what I'm not currently capable of doing.

It's certainly a different kind of challenge than I'm used to, and I'm learning to be more patient with myself and more determined. It's very difficult, but I'm really enjoying the work. Fortunately, I really feel like I'm picking it up quickly and I'm already contributing a lot, despite the setbacks from my lack of coding background.

Red Interactive

I had a lot to think about over Thanksgiving weekend, as Red Interactive offered me a job for about 40% more than what I'm currently making at Disney.

It was the worst kind of thinking, too, because I didn't have all the other factors laid out. It's hard to think about something and consider two different routes to take when you don't have one of the options on the table and you have to just imagine your choices based on what your second option could be.

After all that thought, though, it wasn't too hard of a choice to make in the end. Disney said that they wouldn't counter anything. I'll be starting with Red as a software engineer on December 15th!

I was leaning towards Red anyway, even though it was a for-real full-time Engineer position, but I was curious to what Disney thought all my efforts were worth over the past 9 months. Apparently, not more than I was currently making. It was good to know. I really loved my time at Disney and I'm sad to go, but stuff like "no counteroffer" makes me think that I'm leaving at the right time. Disney has a reputation for stringing people along almost until they're not legally allowed to any more.

The thing that was driving the possibility of me staying at Disney was a producer title, and it looks like that was farther away for my career than I thought. Getting a producer title would have been nice, because it the only qualification for being a producer is "having been a producer", an irony that is not lost on me. But, if Disney isn't willing to offer me a producer title while I'm about to leave for another company, they're probably not going to offer me one later just for being a swell guy. I suspect that I was 2-3 years out on landing that title, and that's too long. I have stuff to get done.

I'm extremely excited to start with Red, for a lot of reasons. They run many, simultaneous projects that last around 6 months each, with 2-4 people per team based on the need. Smaller teams means that my creative contributions will be much more likely to help steer a project, and it will even be possible to be a developer that completely understands all aspects of the project I'm working on.

Even though I'm horrified that I'll be getting paid to do engineering, I'm excited to really give it the majority of my attention. In the past, I've tried to engage with engineering but have always found more important things to work on. Cyber Heist needed a designer, Disney needed a producer, and even though I've always loved engineering it's been more important to do other things instead. Everyone at Red assures me that there is way too much engineering to do compared to the rest of the responsibilities there, so I feel hopeful. It seems like the perfect step to take for my career.