Unity is now at version 3.5.1, and has improved every step of the way.

Even better, Unity is completely free to use, so long as we don’t need the Pro features. The free version is quite complete, as it includes everything needed to create finished games and compile them for Mac, Windows, and in-browser play. Most of Unity Pro’s features are beyond what we have time to use at our scale anyhow.

Some of my classmates and I created Freezing Solid in Unity, and it’s only one of four VGDev projects that used Unity this semester. Dusk was still another VGDev game made in Unity, and it came out a year ago in Spring 2011 (tip: read the instructions on that one).

To help more developers get started in Unity, I created a one hour tutorial this semester on how to put together something basic but functional.

This first tutorial covers a number of essential concepts to using Unity, and is sprinkled with a handful of more recent tips that I’ve picked up while working on Freezing Solid, Crystal Ball, and class projects. After a few practice runs for groups at Georgia Tech, I’ve now recorded the tutorial as a YouTube video, to hopefully help HGD readers and visitors get past the initial hurdle of figuring out how to get started.

Even if you don’t have a project in mind at the moment to make with it, simply working with the tool and making it through the tutorial may get your gears turning about what you might like to create. In addition to trivially providing 3D environment editing, optimized physics code, and handy in-game debugging functionality, Unity is also a really convenient way to easily deploy cross-platform and web-compatible games. Why not give it a shot:

Please note that the source and version linked above include a few minor additions that were not covered in the video for sake of time, namely multiple camera modes and slightly better input hookup. Simply inspect the source code linked above if you’re curious about how those changes work. For the part of input changes that are not apparent in the script differences, go to Edit -> Project Settings -> Input in Unity when the downloaded project’s scene file is open. The scene file to open is located inside the Assets folder.

But the answer is no. Releasing a game just as soon as it’s done is kind of a bad idea. When someone is new to game development, and they’re mostly just making projects as way to figuring out how things work, it’s not really a big deal. Once someone has a bit of experience though, and they’ve invested themselves into crafting something that has potential to be of interest to strangers (a good litmus test, since strangers won’t just play it to be nice to us), there are at least two more small steps to take after completion before releasing it.

First, if you haven’t already done so earlier in development with a build that looked finished, it may be useful to promote the game a bit and create some decent promotional materials to point people to. A short and simple YouTube video will do, but make it entertaining instead of descriptive. Also, take a bunch of screenshots to pick out the few best to represent the game on the web. Maybe even gather a few player testimonials from private testing.

Lots of people that either don’t play games or don’t have the time or set up to play your game right this minute: classmates and family members on Facebook, friends without the particular platform or specs you develop for, even recruiters at game development companies (you’d be shocked by how many people working at game companies don’t play videogames). Having a decent video can help these people quickly learn about the game, and even share it with others that may be able to play it.

Meanwhile for people that do have the time and system specs to play your game, watching even a half minute of the developer showing one way to play the game the way that it was intended (even if not the only way to play!) can help players get started quickly instead of fumbling around trying to figure out what’s going on.

It’s 2012. People are busy and there are a ton of exciting, free, easy-to-reach things competing for everyone’s limited free time. Watching a sweet video may be just the thing needed to bridge the gap and convince someone to try it. If they decide it isn’t for them, no big deal, but at least then they can base that decision on information other than the game’s title.

Retail commercial games come in a packaging that allows undecided players to get a quick sense of the game by the cover art and information+screenshots on the back. Think of the video, screenshots, and (if relevant) testimonials as your version of packaging. And just like it would not be acceptable for a game company to just sell their retail games as unpackaged DVDs laying on the shelf, even otherwise happy players will pass on your game if you don’t show enough interest to package it decently.

The second thing, and this of course comes before packaging but it’s equally important, is to really user test the ‘final’ game with people that have never seen you play it or had you explain it. This isn’t really about fixing bugs, so it doesn’t matter how thorough of a programmer you are, it’s about identifying accidental design slips that you would likely apologize over if you saw someone struggling with it. Yes, it’s necessary to write a game that doesn’t crash, and it’s necessary to ensure that it installs and/or runs decently on a variety of machines, but I’m assuming that you’ve solved those problems already.

This is about having one last chance to smooth over, fix, or improve the places that new players get stuck or confused by when sat in front of the game without help. If someone needs you as the developer to explain, clarify, coach, or point something out to them when they sit down to play the game, multiply that problem times 1,000 players and realize that you won’t get an opportunity to talk to any of them.

Take whatever it is that you find yourself desperately wanting to tell your playtesters and either embed that information blatantly into the game at a relevant time. Or, even better, if at all possible find some clever way to remove the need to provide that clarification. You will always, always catch something surprisingly important by doing this for each game. Not doing it would be like shipping code without even first trying to compile it to see if any errors come up. Madness!

Testing the would-be-final version with a few people can make a big difference. It’s well worth putting a few extra days into, at least. If you don’t feel like you can even bother a few of your personal connections to try it, are you really sure that you’re ready to bother a few thousand strangers with it?

By comparison to how long is needed to take a game from concept to release, we’re really only talking here about a tiny percentage of total development time – maybe a few percent for some immediate gains, or a bit more if you’re really wanting to polish it, say, for commercial release.

That little bit of extra work at the end, even though the game is technically functional enough and feature complete so it could be released, can greatly amplify the size and satisfaction of your audience. While there’s obviously more to being happy with a game project than simply hitting bigger numbers, these two practices can also help your game wind up in front of the sort of players that it’s intended for, and increase the probability of them seeing all or more of the content that you (and your team, if applicable) worked so hard to create for them.

1. How long have you been doing this?

I started modding videogames in 1996, when I was in late elementary school, and started developing them from scratch as a hobby starting around 1998 when I was in middle school. I have making games professionally off and on since 2005.

2. Do you mainly work with people, data, things, or ideas?

In this line of work I begin by coming up with ideas, followed by working with those ideas to figure out how to turn them into data, after which I present that data to other people as though the data were things. The work a lot of my peers do in game development involves gathering a ton of data about how people interact with these things, leading to ideas about what to change about their games.

Anyhow, since the chain of events begins with ideas, in response to the “mainly” aspect of the question, I will pick: ideas.

3. What do you like most about it?

I like that each project is different, bringing new and different types of challenges. I also like the ability to “wear many different hats,” performing a variety of types of work on each project. I get to lay out levels, program exactly how things work, pull together the work of other talented people creating music and art, plan out and oversee the player’s experience (what they first see, how the menus look and work, what we show or give them for winning and doing well), etc.

4. What are the most frequently recurring problems?

Communication is a challenge every step of the way. When starting a project, there’s a challenge of communicating with other collaborators to make sure people understand what they’re getting involved with, since even a very talented developer will be unhappy with the results if working on a mismatched project. During a game’s development, there’s another challenge in integrating the ideas of team members while providing sufficient communication to keep everyone on the same page. Near the end of a project, there’s a much different but very important challenge in trying to communicate with potential players regarding what the new game is like and about, as well as how to play it successfully.

5. How did you get started?

I began “modding” commercial games in late elementary school to get more out of single player games that I enjoyed on PC. As a middle school student I taught myself the basics of C programming from books. I then shifted from writing text programs to figuring out how to use my programming for games by displaying graphics and playing sounds. To do that at that time I first copied assembly functions I found in the back of programming books, then a little later the Allegro game programming library, but there are now many other alternatives with various advantages and disadvantages. When I began my undergraduate years at college I helped start a computer game development club, and I landed my first internship in the game industry through a recruiter we invited to speak at one of our meetings.

6. What type of training is needed today?

A computer science degree can be very helpful, however people come into game development from a variety of backgrounds. Many people continue on to a masters degree in a videogame-related field to further help their qualifications to work in the game industry. All of that is primarily if you are looking to do it professionally, though. If you’d like to explore it first or primarily as a hobby, no formal training is necessary. Much of a game developer’s training today is finding ways to make or mod/extend videogames on our own.

7. What type of technology do you use?

I work on a home computer, no different from the sort used by everyone else (probably pretty similar to the computer that you’re reading this on).

In terms of software, I use plain text editors to write code, and recompile using simple bash/batch scripts. That’s a bit of an old-fashioned way to go about it, many developers prefer managing their projects in more robust editors designed specifically for programming.

In regard to programming languages I’ve done professional work in ActionScript 3 (compiles to Flash), C/C++, Objective-C (for iPhone), C#/JavaScript (for Unity), php with SQL, and a few scripting languages. I also use image editing software, like Photoshop or the free alternative at http://www.gimp.org/, and sound editing/creation programs like Audacity.

8. What changes have you seen in the past few years that affect this as a career path?

Every few years a different business model appears that draws the attention of investors and businesspeople. In order to work professionally, game developers have to find ways to design projects that work well with those new business models. 30 years ago it was paying a quarter to play at the arcades, for the next 10-20 it was largely selling games as $60 retail goods, then the MMO/subscription model seemed to dominate for awhile, followed by cheap/$0.99 mobile games. More recently the free-to-play micro-transaction model used by social games seems to have taken over. Old business models remain of course – there are still new arcade games, and a major part of the industry continues to be $60 console games sold retail – but the arrival of new, larger market segments makes those an increasingly small percentage of professional game development.

9. What personal qualities do you feel are needed to succeed in this?

Game development relies upon having determination, persistence, and patience to self-educate. Many skills are needed that go beyond and build upon what anyone currently teaches, and the only way to pick up those skills is through experimentation, working through problems that arise, and getting a lot of practice.

Another personal quality that helps is knowing how to be flexible while still finishing the work. Rather than stubbornly sticking to something until it’s exactly the way originally intended, in many cases being a good listener and open-minded observer can save or productively redirect work by noticing what parts of the task matter most. Ideally this leads to finding a clever way to achieve those goals without getting stuck on the many details that may turn out to be much less important, or even distracting.

Lastly, but importantly, it will go a long way to learn how to present. Seek opportunities to practice presenting your results, your mid-process progress, and even presenting yourself (as a potential collaborator, as the right person for a particular task, etc.). Think about any game that you enjoy – if someone hadn’t figured out the right way to show that end result to strangers, and to win others in their company or team into collaborating on it, we could never have had the opportunity to play it.

When you begin making nifty projects that you’re proud of, don’t hide them from the world. Be prepared to show and share them in an appropriate way.

10. What advice could you give to me while I am pursuing this?

Game design involves doing a lot of different kinds of tasks, working with a lot of different kinds of information, and communicating with a lot of different kinds of people. Working to become well-rounded is important in this.

Technical understanding is useful (math and science), creative practice is useful (English and art), and the other random information someone knows about (history, literature, film) is what separates their ideas and work from that done by other equally capable people. Even clubs and sports can provide useful insights, habits, and ways to relate that might be missed otherwise.

There were times in school when my friends wouldn’t see the point of a geometry assignment, but I would be excited about it because I knew how I could use it to make my videogames do things I didn’t previously understand how to do. Writing classes, which didn’t seem so obviously applicable to me at the time, have turned out to be every bit as important, as I use much of the same process and ways of thinking now for my non-writing work.

In other words: despite my previous point being the importance of teaching yourself things that other people can’t or don’t yet teach, this point is the importance of paying attention and learning from others about the material that others can and do teach. Self-education is often the only way to learn certain things worth knowing, but when it comes to material that people have spent thousands of years finding ways to explain, don’t insist on reinventing the wheel and trying to rediscover all that yourself.

If you ever have more specific questions about getting started in videogame development, or run into hurdles along the way that I might be able to help answer or get you past, please feel free to write back again at any time.

Good luck!

Download the game or play it in-browser (via the Unity3D plug-in) at FreezingSolid.com

For the development of Freezing Solid I served as project lead (original concept, core gameplay design, team management) and engine programmer, in addition to designing three areas, the player character, and several enemy models.

Many other peers in Georgia Tech VGDev contributed to the project, creating original music, models, levels, sound effects, and programing for additional features – see Credits Hall in the completed game at FreezingSolid.com for full project credits.

All music used in this trailer was composed specifically for Freezing Solid by team members Larry Smith and Matthew Guzdial.

Specifically I was asked, “Is 10 too many?”

My answer was 2-4 per game. Given 10 completely green developers looking to make games, I would advise splitting that group into 3 smaller groups of 3-4, or maybe – just maybe – into 2 “big” teams of 5.

One benefit of keeping the team small is that it’s easier to define clear roles and ownership, to avoid constant confusion over which programmer is implementing which features, which artist is claiming which assets, and so on. Coordinating multiple people to share the same tasks without running into major problems also requires an ability to articulate clearly about the field in a way that is rare among inexperienced developers.

I would set up the roles of each like so:

• One developer focusing on programming and core gameplay design. Combining these roles greatly accelerates the feedback iterations needed to bring what’s implemented into alignment with what’s intended. Since the programmer is the final filter for what gets hooked up in the game and how, this is often (though not always) the position serving as project lead/producer.
  
  
• One developer overseeing the in-game artwork and visual design. If the game’s art can be done primarily by a single person, there’s less of an issue in trying to get all artists creating content to fit with a single coherent style.
  
  
• If there’s a third and/or fourth developer, they might be either overseeing audio, writing in-game dialog, helping author puzzles, or fulfilling whatever other roles offer the most value given the project’s genre. Without these members, whichever of the other two is most capable in the respective areas can fill in.
  
  It’s also possible that party members three and four could be an extra artist or content designer. In such cases it’s helpful for each to have a clearly dilineated chunk of the team’s art or design. One artist might be focused on background and menu art, while another ensures all animated sprites and items are accounted for.  With multiple level designers, rather than sharing all levels, it can help to divide up who is overseeing which.

Note my word choices here: “focused on,” “ensures… accounted for,” and “overseeing.” This is not about putting restrictions on people. It’s only about clarifying accountability. Individuals can trade tasks, ask one other for feedback or ideas, get help with aspects that other team members have more experience with, and so on. It’s not mission critical that each person does exactly what they’re accountable for. What matters is that team members see to the timely completion and presentable quality of every aspect in their area, which in some circumstances means handing it off partly or entirely to someone else.

With six or more people, especially if all the people involved are completely new to videogame creation, there’s risk that the project may become administratively intensive, requiring specialization not just in programming, design, art, and audio, but also experienced and dedicated management know-how. Confusion can arise over who is directly responsible for doing what. Feature creep can grow out of control as so many different visions each pull for the game elements that they want to see. Tasks that several people on the team are quite capable of doing may drag out for weeks, partly because each capable member assumes someone else will take care of it, and partly because everyone’s too busy figuratively stepping on one another’s toes by simultaneously taking different approaches to creating the same core assets.

Sometimes having the right word for a concept can be helpful in spotting it, talking about it, and when applicable, mitigating it. The term central to this concern is Diffusion of Responsibility. Diffusion of responsibility occurs when too many people are all made accountable for the same task(s), without any clarity for which person is ultimately accountable for each.

I’ve found this concept incredibly useful when orchestrating game development teams, both professionally and for hobby projects.

I picked up the concept of diffusion of responsibility from one of my friends in college, in regard to event planning. If we ask a group of 30 well-meaning and perfectly capable students to make sure chairs are set up in the main room tomorrow by 7:00pm, it’s unlikely to happen. Go to one student, instead, ask them if they’ll make sure that it gets done, and it’s much more likely to be accounted for.

The same also applies to, “We need the pickup icons done in time for the demo next week,” or, “The game still crashes every time the rocket launcher is fired.” If there are multiple people that might be responsible for those aspects of the game, these needs are less likely to promptly and decisely wrapped up without additional organizational dialog.

In cases where being vague about who is supposed to do what does manage to work out, it’s often only because someone within that group has the sense to do what the manager didn’t. Someone from within the group has to speak up and play coordinator, making sure that no one leaves that room until it’s clear and decided which individual is going to take ownership over the timely completion of each task.

Nor, to be clear, is diffusion of responsibility a concept only useful for producers. It’s better to err in favor of not falling into the pattern of being just another complicit bystander. If the lead pitches a request to no one in particular, or when it’s clear something is falling through the cracks that may not be claimed by anyone, be that member of the team that keeps everyone around for an extra minute at the end of meeting to confirm who claims accountability for what.

Whether you’re a lead or not, everyone on the project benefits when someone on the team can recognize and overcome diffusion of responsibility. Conversely, everyone on the project risks a great loss from letting untreated diffusion of responsibility serve as an ongoing obstacle to progress. Keep an eye out for it, be brave (though tactful and constructive) about combating it, and you’ll find the projects you’re on more likely to finish well and on-time.

Our small team kicked off a Dev Blog at VisionByProxy.com. We’ll be posting project updates, desktop backgrounds, content reveals, and other goodies as the game takes shape. We’ve actually been working on Ms. Vision by Proxy in the background for awhile now. That head start has given us time to explore, vet, and begin developing gameplay, story, and new character ideas that we’ll be able to share via the blog.

I recently did my first post for the group. It’s a lot like any other entry I would write here on HobbyGameDev, except it’s grounded in a very specific context. The entry is titled 2 New Features in Ms Vision by Proxy. In it I highlight some of the engine changes that I made to the Everyone’s Platformer engine (the full source and tools for which are completely free to HobbyGameDev readers such as yourself) to create Vision by Proxy: Second Edition, followed by some simple tricks we discovered to get still more out of the engine for the upcoming sequel.

I don’t ordinarily focus much energy on “building buzz.” Lately though I’ve been coming around to the idea that done right, people’s discovery of a game and opportunities to read or see more about it can become a part of their enjoyment – and furthermore that doing this part wrong (or not at all) can get in the way of people experiencing it as intended. As always, I look forward to learning a lot along the way.

If you’re at all curious, head on over to: VisionByProxy.com

I’ve decided to categorize this as an Intermediate entry since I presume here that you already have some functional game development skills, and are in the process of figuring out how to best exercise and improve upon them to advance your work and establish a personal identity as a developer. This also partly explains the tension between my previous entry and this one, since an Advanced developer typically isn’t as actively searching for their personal style and undiscovered strengths.

Q: Which is more important when students are making games: quality or quantity?

A: That’s a bit of a trick question. It’s a false dichotomy. Quality is ultimately what really counts, but quantity is a means to quality.

Create even one game that especially stands out in quality, and provided that people find out about it, whatever else you’ve worked on before or work on for awhile after probably won’t seem to matter much by comparison.

The observation of that pattern from hit games sometimes leads to the confused idea that we should simply spend years at a time turning out a quality game. The problem is that quality isn’t like filling up a bucket, in which we can just pour more quality in given enough time to do so.

Quality is a soft concept, and a constantly moving target, wrapped up in all kinds of intangibles and unpredictables: timing in relation to what else has been in popular media lately, how original or innovative or (paradoxically) familiar it feels to the particular audience that finds it, and countless nuances in implementation where thousands, even millions of little decisions along the way need to add up just so to really ‘click’ in the final result. A thorough QA/polish cycle can help make the most of what’s there, but it can’t fundamentally change what’s there.

Like I mentioned in the presentation:

Focus groups seemed to unanimously indicate that Star Wars – the original film – would completely bomb.

Experienced creators and long-time players are continually surprised by what turns out to work and what falls flat. If it were up to game companies and indies, every game ever released would be critically acclaimed, but in practice we know that’s not how it works. It’s generally impossible to tell until it’s too late whether a game will come out well or poorly, and even then, it’s impossible to say for sure either way until well after release.

Part of why giant, completely uncreative businesses like Zynga build their companies by churning out clone after clone of games invented by other people is that the majority of untested ideas don’t pan out, but by verbatim copying the designs of others they’re able to capitalize on the exploratory risks already taken by other people and companies. Effectively, they’re outsourcing their R&D to their competitors. Since I assume you don’t want everyone in the development community to hate you though, I trust that you’re probably looking to do something that’s at least partly new.

(Cloning with variation to learn while growing code and experience to draw upon for later original work is quite different, and something I outright encourage. Competitive analysis is just a smart part of business, too; no sense in completely ignoring the 3 decades of lessons learned. It’s the complete, shameless, point-for-point and creatively-devoid knockoff that’s objectionable.)

Nor is quality directly proportional to the time and energy put into it. There are bargain bins out there overflowing with really bad games, begging to be sold even at a loss, that people invested a lot of money and time into polishing only to see them fail miserably. Occasionally, though admittedly it’s extremely rare, we see games come out of game jams that change the gaming landscape – Canabalt, the breakaway hit by Adam Atomic and Danny B that established the single-button running game genre, “was a 5 day game, most of it was made in a weekend.”

My daily experimental gameplay/interaction series (highlights), which I alternate between being overly proud of and completely embarrassed by, wasn’t undertaken for the sake of making a lot of things, but for the hope of discovering a few things worth being made. I was searching for ideas that I wouldn’t have stumbled upon or developed otherwise. That’s how I stumbled upon the foundational ideas behind feelforit, Tumult, Burnit, and indirectly, Transcend.

feelforit (the iOS version, though this links to the web/Flash port) was an IndieCade 2010 Finalist. feelforit was not hard to make, and did not take me very long to put together, but discovering the idea at the center of the interaction required my making those daily prototypes for 219 consecutive days.

Granted, feelforit is no Canabalt. But you know what is? Crayon Physics by Petri Purhho, which he stumbled into during his binge making monthly games. Or World of Goo, which got its start as Kyle Gabler’s Tower of Goo as part of the weekly single-author experimental gameplay projects. In each case, even though the core game took a larger development push to bring to market quality, the core concepts were discovered through quantity-oriented development.

The PC Freeware I developed or helped develop that I put forth on my older site includes only a tiny, curated subset of the dozens of other finished projects I worked on.

There’s a major selection bias at work when we think about the media we like. We obviously know about the ones that we know about, and don’t know or think much about the ones that we haven’t heard of. The overwhelming majority of commercial failures don’t even get negative press.

Minecraft was not Notch’s first game, he has been making them since he was 8 years old back in 1987.

Bram Stoker wrote more than a dozen books before and after Dracula that weren’t Dracula – odds are quite good you’ve never heard of any of them, despite, I can only assume, Stoker applying a generally similar approach and quality of talent to each of them.

In my effort to combat the idea that quality is somehow the opposite of quantity, I also don’t mean to go too far in the opposite direction, implying somehow that quantity inevitably leads to quality, or that game production is somehow a completely random crapshoot. There’s a lot more than luck going on here.

Part of how volume tends to help is that it splits up what’s going on in our lives at the time, what’s on our minds throughout development, and who we’re collaborating with. Even when a particular combination of circumstances doesn’t directly lead to success, it can still help get some rookie junk out of our systems, get us more comfortable with the process so that we’re less distracted by logistical uncertainty on later projects, and lead to other types of realizations that might indirectly help solve problems we’ll eventually run into on another game. In addition to evolving a mechanic I discovered during the InteractionArtist series, feelforit‘s codebase also built-on graphics tricks I had previously figured out for my earlier iOS title Burnit.

Maybe you’ll find there’s a particular genre or type of work that you do especially well. Creating a variety of projects is much more likely to lead to that discovery than getting buried in one initial effort that has limited potential anyhow. If it turns out something about how you think and work would lead to an amazing racing game, you’ll never know if you devote years to churning out a one-on-one fighting game.

No matter who you are and what you’ve done, the best 15% of your work is better than the other 85% of it. But to apply a filter like that, you first have to have completed enough projects to be able to meaningfully evaluate and curate that set, burying the worst of it while still having something to show.

In closing, this is a little relevant, and a lot of awesome:

“…the most important possible thing you can do is do a lot of work. Do a huge volume of work.” (beginning at 1:05)

Write only as much as you can revise carefully.

Brilliant. Here, in fewer than 10 words, is an approach that applies to nearly every undertaking that we intend for others to see.

Put another way: don’t drive so fast that you lose control.

Is this really Advanced material?

Every month I write entries for four categories: Beginner, Intermediate, Advanced, and Special Topic. This entry is intended for Advanced.

But, I can hear certain experienced readers objecting, isn’t overextension generally a beginner’s mistake?

That way of thinking leaves advanced developers – and everyone else putting trust in their judgment – even more vulnerable. Beginners often have a problem with overextending, certainly, though they do not yet have enough perspective to be able to recognize that as what they are getting themselves into. It is the more advanced developers that are capable of recognizing overextension, and are therefore in position to either ignore it or apply the brakes.

Experience does not render us immune to overextending ourselves. At best it can help us notice when we begin to lose control, after which we still need to take swift and deliberate action to correct for it.

Growing requires stretching a bit every time, but what ought be stretched is the presentable result. Stretching for its own sake without bound is simply stretching further into the territory that we can’t possibly polish to a presentable state. Anyone, no matter how experienced, is capable of growing a project beyond their means to finish it well.

Write only as much as you can revise carefully.

Otherwise, the project may wind up wrecked roadside while others pass it by.

And if you’re working with a team on which you are among the more experienced developers, you have other people in that car.

- Hi Chris. This is my first year in college, and I’m currently a Computer Science [CS] major. However I came in with no prior programming experience, so the math and programming classes so far have been pretty tough. I am thinking about switching my major to something more enjoyable, and just trying to teach my self game development instead. Any thoughts on whether, or maybe why, it would help to stick it out with CS? My dream job is to work in the gaming industry, though I may wind up looking into indie development.

Answer, Part 1

First, full disclosure: I was a CS major, too. That may bias my view of it, but it also means that I can provide an informed, first-hand look at how it did or didn’t help.

Everyone’s path in life and career is different. The decision is purely up to you, and as you necessarily know more about yourself than anyone else does it’s important to weigh my thoughts on this as just one more source of data.

Whether you decide to seek corporate industry work or go independent, I think that a Computer Science degree is still among the most applicable, useful, and broadly marketable backgrounds related to game development. I’ll do my best here to make a case for why I think that’s true.

Note too that, importantly, CS is also a credential respected outside of games, which can make it a practical degree to have for finding or creating back-up plans down the line if necessary.

Comp Sci != Game Making

As you’ve probably already discovered, game development generally isn’t really part of CS curriculum, except perhaps for a single high level elective class. Almost all of my game development during college came from extracurricular clubs.

Learning game development requires a good deal of self-teaching no matter what major someone is undertaking. Experience in CS is relevant though, and it complements someone’s self-education in game development by pushing development in areas that it would be easy to overlook on our own. Material from CS can be useful outside of the classroom, when working through real-world game development problems, sometimes in ways that are hard to recognize until they come up during the creative process as either challenges you’ve prepared for, or – if the skills aren’t there – as apparent dead-ends.

Comic from Abstruse Goose, shared under Creative Commons Attribution

There are no doubt routes to take that are easier or more enjoyable to take in the short term, but those paths may or may not be easier and more enjoyable in the long term. College years are partly about investing in your future capabilities and opportunities; the standards and challenges of a CS degree are just one of the established ways to stay on a solid track to do just that.

If it’s not immediately clicking, it might require spending some more time in the library studying (even if you don’t need the books there for CS, it’s handy as a well-lit place filled with other people calmly working, too), attending more of the optional tutoring and office-hours sessions available through your school, starting earlier on assignments, and staying up later sometimes to hack through getting assignments figured out and working. Many college students wind up automatically paying for resources but not making full use of them, whether via the career center, library assistance, or office hours. Before deciding that a subject isn’t working out, make sure that you’re at least getting your money’s worth and using all the mechanisms available. Outside of working on videogame projects and trying to live a rounded life in college, I spent a ton of time at office hours asking questions to try to fill in for what I didn’t understand yet from the lectures and reading.

Big Company vs Indie

A qualifier about the difference between big company work and an indie career: earnings from independent development can be really, really hit or miss, spotty and unpredictable, and in the majority of cases unprofitable. There’s a huge selection bias in the indies we hear the most about – they’re disproportionately the rare success stories that have done extraordinarily well. The countless others that are barely scraping by or losing money don’t make for good headlines.

Independent work can be a tricky and trying path to navigate, and though it’s potentially very rewarding, it should perhaps be initially thought of as something to develop on the side of some more consistent line of work as the main plan. With a bit of momentum from giving yourself a head start, and a bit of savings in the bank from doing something with a more predictable paycheck for awhile first, you’ll have better odds of lifting off the runway.

One element that helped me in my journey – though again each individual’s mileage from such choices will vary – was to minor in Business Administration. Those courses involved learning and practicing skills that were useful in every scale of work environment that I’ve been involved with, including my time alone: presenting information/ideas/yourself to others, basic financial concepts, project planning, even practical bits like resume preparation. (Even if you go independent, keeping an efficient, up-to-date, professionally presented summary of skills and work can be useful to have on hand.)

Whatever you decide, good luck on the road ahead!

Question, Part 2

- It seems like many of today’s big designers got into the industry with a non-technical major. Do you see the industry moving more towards requiring a relatable degree?

Answer, Part 2

You’re right that many of the current big and/or historical names in the industry have a seemingly random assortment of backgrounds. John Romero and David Perry were both, if I recall, completely self-taught, and did not attend university. Nintendo’s Shigeru Miyamoto went to school for industrial design. In my interview with Atari Adventure designer Warren Robinett, he mentioned that one of his early co-workers in the game industry, “had a degree in Zoology.”

Of course, Shigeru Miyamoto was born in 1952 – so for perspective, Pong hit the market (overseas, here in the US) when he was already 20 years old. Robinett’s undergraduate degree was not in Computer Science – he majored in a CS-like area of math, but when he was an undergrad CS had not yet become a standardized field of study.

That historical difference partly accounts for what you’ve rightly pointed out.

40 Years Ago

The industry didn’t exist when most of the early innovators were growing up. To the extent that some degrees were later relatable, like Robinett’s pre-CS technical/math major, no one at that time could have picked it for that purpose, because those exact jobs and products didn’t exist yet.

Another thing to keep in mind was that computing was very different in the 1960′s to early 1970′s. Far fewer people had access to computers, but among those that did, a much higher percentage of users taught themselves how to program because it was pretty central to being able to use a computer at all. Programming was one of the few activities that could be done on machines at the time; the first word processor didn’t come out until 1972, and the internet didn’t become common and commercialized until much later in the 90′s.

There also wasn’t much ‘prior art’ for a game developer to catch up on. Nearly everything being done at all was new, and by casual assessment equally valid from a business perspective until the market response to a shipped product indicated otherwise. By comparison, much has since been sorted out by now, both from a technical perspective and also from a business perspective. People have already lost a lot of time and money figuring out how to do certain things in impressively efficient ways, how to collaborate effectively on team projects, and discovering what consumers responded well or poorly to. Developers caught up on those findings have an advantage over others starting from scratch, reinventing the wheel, insisting on learning the hard way.

Now that four decades have passed, many of the surviving companies have thousands of employees (or at least compete against companies of that size), and there’s demand for high degrees of specialization for a team to be able to distinguish its products from those that competitors are able to create. Even just keeping up with inflated consumer expectations, especially on today’s higher fidelity platforms, can require specialists. Whether applying for an industry job or creating independent games as a small team, each individual is competing against a tidal wave of other eager, passionate people that have partly designed their education and adult lives around developing skills that have been found relevant to the now more established craft of videogame production.

Increased Importance of Degrees

The increased importance of degrees, though more so for applying to jobs as opposed to working independently, has also become a useful shortcut for hiring managers serving as a company’s first line of assessment. At a company with a recognizable brand, the executive producer or lead engineer can’t personally screen every applicant. Instead, the initial set of applicant submissions first has to make it past recruiters that are not necessarily game development specialists, and thus may look for specific degrees and types of prior experience as evidence of the skills they’re hiring for. Applications making that cut then move on to one or more rounds of interviews, at which point an appropriate specialist from the team may be available to help assess actual qualifications, but getting to that phase with little/no relevant professional experience is part of where the appropriate degree can help.

While there may be capable applicants without relevant degrees, unfortunately there are often enough qualified applicants that do have relevant degrees that it’s easier and more cost/time efficient for a company to hire primarily from the latter pool, for which less screening may be required since college admissions and professors may be thought of as a very specific sort of filter.

Comp Sci is More Than Programming

A CS degree is not just about knowing how to program. Having a particular degree is often also interpreted as evidence, correlative beyond the scope of what’s covered directly by the curriculum for that degree, that someone is dedicating themselves to some predictable set of knowledge, skills, and values. Companies need all kinds of people to thrive, but from a purely practical perspective, it doesn’t take much imagination to picture how a “CS person” can fit in and benefit a company that creates software. Computer Science rewards attention to efficiency, feasibility, robustness, extensibiliy, self-correction, and some other less easily pinpointed but equally useful priorities, in ways that specifically apply to computer programs. (I.e. while it’s true that plenty of subjects may reward attention to efficiency and feasibility, traditional CS approaches these in an extremely rigorous fashion by dealing with their theoretical limits.)

The increase in people hired that have relevant degrees, from the above factors, has created a positive feedback loop. When the people with those credentials get promoted over the years into more senior-level positions, they’re even more likely to value that same (or similar) credential among incoming candidates at an interview stage.

Game Degrees

Another option within the spectrum – which you haven’t asked about directly but I’ll address here for sake of completeness – is in degrees more specifically and narrowly about videogame development. These haven’t been around as long as Computer Science, making them a bit less standardized, and consequently more of an unknown, unproven value to many people in industry. Anyone with a CS background has a pretty clear idea of what someone with a CS degree from another school likely covered, but there’s so much variety between game degrees that it’s hard to know what skills and work culture to expect unless someone in a hiring position is personally familiar with that exact school and educational program.

Partly as an effect of having not been around as long, there are also fewer senior-level people (yet) from those types of educational backgrounds.

The flip side is that some of the same factors that have made the CS degree of more interest to the industry are likely at work for those more game specific degrees: easy shortcut for hiring managers, evidence of (probable) commitment to certain knowledge and attitudes beyond the curriculum, and as time progresses, more senior level people coming from that background will be held up as evidence of the type of value associated with those degrees.

That path can also be a more risky value proposition to students, however, since those degrees sometimes cost comparatively more (being seen as more vocational, and thus framed more as a financial investment) and can be more limiting to videogame industry work. Students with those degrees have less of a clear back-up plan, not only if they can’t find a fit in the game industry, but also if the game industry undergoes a major shift as it did when arcades mostly phased out, when MMO’s seemed like the next/only big thing for awhile, when digital/mobile distribution lowered barriers-to-entry for competitors with much smaller staff, and as social games have grown to absorb an increasingly sizable chunk of game company investment capital.

How good of a back-up plan comes out of a mostly game-specific degree varies greatly between how individual schools have chosen to implement such programs. I have heard peers in such programs report everything from their studies being typical Computer Science in-disguise, to specific tool training (which can seem the most useful in the short term, but can be the least useful in the long term – teach yourself the tools, instead!), to amounting to little more than an excuse for networking. Remember though that a recruiter without direct connections to the particular program (perhaps less likely outside the industry than within it) may not have an easy way to quickly discern one of the above from another, and that could affect whether an application makes it to a stage in the process at which someone with the necessary domain knowledge takes the time to sort out the candidate’s relevant capabilities.

Closing

The case, by contrast, for a CS degree is that its emphasis is on fundamental concepts, which aim to extend well into the future largely independent of specific technologies or how the market may change. At any time in game industry history, even just a five year span has covered some pretty dramatic changes, but a proficiency for the skills and mindset of proper software development has remained central and relevant.

Lastly, as a reminder: I have only an outside, second-hand perspective of the alternatives. Your best bet for gaining a more balanced perspective would be to pitch this same question to some game developers with different backgrounds. There’s no one right way to go about it, though the odds are better some ways than others.