Get the latest Education e-news
 
  • A Player's Guide to the Games Industry

    [05.01.14]
    - Kaye Elling
  •  It's not easy getting into game development. Especially if you're studying at university and have your sights set on a career with the developers of your favorite billion-dollar selling game. The truth is that there aren't as many game development jobs in existence as there are university courses feeding into them. Competition is tough, and expectations are high.

    Many development studios find it difficult and risky to hire graduates into development roles. I should know; I was one of the developers doing the hiring. In 2008, as an Art Manager, I needed to recruit seven artists for my team, including some graduate artists for junior roles. I remember viewing 100 portfolios, from which we made exactly three offers. Of those, only one of them was accepted. A 1% success rate, which even my maths couldn't misinterpret. That was when I realized there was a mismatch between graduate skills and the games careers graduates aspired to, which ultimately led me to leave the development side of games and get into games education.

    Cut to five years later, where I've been running two games courses at the University of Bradford: The BA course is for budding artists and the BSc course for budding gameplay designers and indie developers. I teach game art and game design students-I don't teach code, that's someone else's specialist field-and mark hundreds of projects every semester. It's an amazing job, but can be extremely frustrating when I see students making the same basic mistakes over and over again, despite my best efforts to prepare them for the realities of life in games.

    This is how my list of "51 Things Every Game Student Should Know" started. I'd have a document open while grading projects, where I could express my frustration, disappointment and disbelief at the assumptions and misconceptions my students had about making games, as I encountered them. It was a therapeutic tool, laced with a hint of humour to make the bitter medicine of my advice easier to swallow.

    On a whim, I published it on my blog, and it quickly went viral through Twitter. From the huge response it netted from games educators and industry people worldwide, it seems that I'm not the only one to despair at the state of the wannabe developer. So here are some of the most popular, contentious, and in my opinion, vital "things" that every game student-or at least every game art and design student-should know.

    On university study

    Let's start with university courses. Maybe you're on one right now. Maybe it's game related or a more general Higher Education course. Either way, the choices you make, the way you work and organize your work, say a lot more about who you are than you might realize.

    Your first year at university should be really tough. This is where you learn how to learn, how to self-motivate, and generally get your shit together. Make sure you have your shit together by the end of this year, or repeat the process at significant financial cost.

    Your second year at university should be really tough. This is where you learn the majority of the required skills for your discipline. Know what that discipline is: Read job specs for all the jobs in industry, not just the one you think you want. You need to know the whole deck before you can play poker.

    Get used to benchmarking your work. Your target is: INDUSTRY STANDARDTM. If you don't know exactly what that means, then you can never hope to reach it. At the most basic level, you should be able to reverse-engineer a game to determine what the industry standard is. This is pretty easy for artists and animators, but can be harder for coders and designers. In terms of gameplay, pay attention to how actions are mapped on controllers and keep track of where narratives branch off, or look behind in-game economies, or how attack and defense is balanced for different players and in different locations. Observation skills are essential, so learn to play like a developer first.

    Work strategically. If your course is a good one, there will be flexibility in the curriculum for options or within the briefs themselves. Resist the temptation to go for safe topics that you already know, otherwise your whole portfolio will be very one-sided. I once had a student who knew so much about JRPGs that his only chance for a job was working in one studio in Japan. He is not working there. (Or working at all.)

    Your final year at university should be really tough. If it isn't almost breaking you,

    you're not working hard enough. Your final year is a litmus test for how you deal with pressure. If you can't take it here, you can't survive in the industry.

    On communication

    Quad: face with 4 sides, Triangle: face with 3 sides, Polys: can refer to either of the above. Polycount: the maximum number of triangles allowed-even if quads are used. Just yesterday I graded a student game environment which had blown the poly budget by 180% because they didn't know the difference between quad and triangle, even though this had been explained to said student many times. Goodbye, impressive grade point average! Seriously, you need to know what the nuts and bolts of all things 3D are called, because everyone has to talk about them-even programmers who don't go anywhere near 3D asset creation themselves.

    Most developers don't say "mobs" when referring to mobile units in games. I worked in console games for 13 years, and never heard the term mentioned until Minecraft came along. Console and PC developers use more precise terms to refer to mobile units in games, such as NPC (non-player character), Enemy or Bot, or even "critter" when referring to non-interactive or decorative units such as birds and butterflies. This is because of the specific gameplay behavior of different unit types. Sometimes they lazily use the umbrella term "AI" (much to the annoyance of programmers). But "mob" was one of the more contentious entries to the presentation, as it angered the MMO/MOBA/MUD development crowd, which has different needs for character and mobile units in their games. This is a great example of how your use of jargon can identify you as a professional, or an amateur. Most of my students using "mob" were just doing it because of Minecraft community forums. I was shunning the word because of my console background. To the MMO dev community, both examples are equally revealing.

    Nailing down this understanding of basic terminology isn't just about being pedantic, it's about communication. Game development is a team sport played by grammar Nazis. Games are made by a lot of people working together to tight deadlines, and so effective and efficient communication is vital. Code needs to be syntax-perfect down to the last semi-colon. It also needs to be annotated so that other developers can work with it at any time. Developers need to be able to access the info they need quickly and intuitively, and share it with a lot of people. They're very good at communicating verbally and in writing. They know when to elaborate, and when to summarize. (This is why the main iteration of my "51 things" article is in a quick-to-read PDF slideshow format, and this long article is an evolution of that.)

    Speaking of efficiency: Know your acronyms. Q&A = Questions and answers. QA = Quality Assurance. You'd be amazed at how many people get this wrong. This sort of gaffe exposes your ignorance on the most basic of levels, and marks you as an amateur who doesn't read up on their chosen industry. This, in turn, hints at a lack of awareness of more important areas of game development. And it offends everyone in QA on whom you will one day rely, when your game is nearing submission and you've worked yourself into a glass-eyed state of near death. Do not hack these guys off. Ever.

Comments

comments powered by Disqus