Recently, a university undergraduate asked me on twitter for advice on becoming a graphics programmer within the games industry. I wrote a fairly detailed email response and thought the information was good enough to make an article for AltDevBlogADay. This is all my personal opinion of course.
최근에, 한 대학교 재학생이 나에게 트위터로 게임 산업에서 그래픽스 프로그래머가 되기 위한 조언을 구했다. 나는 꽤 상세하게 이메일 답장을 적었고 이 정보가 아티클로 만들기 충분하다고 생각했다. 이것은 물론 모두 나의 개인적인 의견이다.
If you're at university, you should research whether there's a programme to do a summer or year long internship at a games studio. There was nothing like that when I was at the University of Liverpool '97-'00 (or I wasn't aware of it), but I've seen people come through that kind of programme with much greater practical game development knowledge and it goes a long way towards persuading an employer to take you on. EA, Lionhead and other large companies tend to run this sort of programme so look on their job pages too. Beware that sometimes companies don't respond to intern applications for various reasons (team is deep in crunch, budget spent elsewhere, etc) and places are extremely limited.
만약 당신이 대학교에 재학중이라면, 게임 스튜디오에서 하계나 일년동안 할 수 있는 인턴쉽 프로그램이 있는지 조사해야한다. 내가 리버풀 대학교에 1997년 부터 2000년까지 다녔을때는 그런게 없었다. (혹은 내가 몰랐을 수도 있다.) 그러나 나는 훨씬 더 실용적인 게임 개발 지식을 가진 프로그램을 통해 온 사람들을 보았고 고용주에게 당신을 뽑도록 하게 끔 한다. EA Lionhead나 다른 대기업은 그들의 구인 페이지에 이런 종류의 프로그램을 볼 수 있도록 하는 경향이 있다. 몇몇 회사들은 다양한 이유로(팀이 크런치 모드에 들어갔다던가 예산이 다른곳에 낭비되었던가 등등) 인턴을 뽑지 않을 수 있으니 주의하라. 그리고 자리도 매우 제한적이다.
Your best bet is to make a graphics demo, either on your own or with a small group of people. You learn more by doing than by just reading. Pick a modern graphics technique that interests you and implement it. Even better, do more than one. This is also great training for motivating yourself to get a project finished which is often the hardest part of games development, for all disciplines. Make sure you're prepared to talk in detail about the choices you made, performance (in milliseconds, not frames per second!), quality, alternatives and trade offs in a job interview.
당신의 가장 좋은 베팅은 혼자서 혹은 사람들과 작은 그룹을 만들어 그래픽스 데모를 만드는 것이다. 당신은 단지 읽는 것 보다는 해보는 것에 의해 더 많이 배울 수 있다. 당신이 관심있는 최신 그래픽스 테크닉을 하나 고르고 구현해봐라. 물론 하나보다 더 많이 하면 더 좋다. 이것은 또한
게임 개발의 모든 분야에서 종종 가장 어려운 부분이라고 여겨지는 하나의 프로젝트를 완료했다는 것에 대해서 스스로에게 동기를 주는데 훌륭한 연습이 된다. 당신은 잡 인터뷰에서 만든 것, 퍼포먼스(밀리 세컨드 단위, fps아니고), 퀄리티, 대안, 트레이드오프에 대해 당신이 선택한 부분에 대해서 자세하게 말할 준비를 확실히 하라.
When I was in university I did a straight computer science course - there were barely any games courses available back then, but I still think that employers still value computer science graduates above games graduates as there's a perception that you learn a greater range of software engineering skills. This could be a misconception though, as games courses are a lot better than they used to be, but you may have to fight your corner in an interview and prove you know your stuff (and not just the curriculum you were taught).
내가 대학교에 다닐때, 나는 컴퓨터 사이언스 과목을 들었다. - 거의 어떠한 게임 관련 과목도 가능한 게 없었다. 하지만 나는 여전히 고용주들이 컴퓨터 사이언스 졸업생을
게임과 졸업생보다 더 넓은 범위의 소프트웨어 엔지니어링 스킬을 배웠다고 인식하고 있기 때문에
더 가치있게 본다고 생각한다. 이것은 게임 과목들이 예전보다 많이 좋아졌기 때문에
오해일 수 있지만 면접을 볼때 맞써 싸워야 하는 부분이고 당신이 알고있는 것들을 증명해야만 한다. (당신이 배웠던 커리큘럼 뿐만 아니라)
Computer science courses also tend to be quite maths heavy (I would hope games courses are similar), which is vital for graphics programming. Make sure you understand homogeneous coordinates, matrix maths, dot products, cross products, quaternions, normal vectors, tangent bases, etc and how these things (and countless others) are useful for transforming and lighting geometry. Learn big O notation for algorithmic execution time, understand colour spaces, gamma correction, what high dynamic range means and so on. Learn some basic lighting models - Lambert, Phong, Blinn, etc.
컴퓨터 사이언스 과목은 또한 그래픽스 프로그래밍에 필수인 꽤 깊은 수준의 수학을 배우는 경향이 있다. (나는 게임 과목도 비슷할 거라고 희망한다.) 동차 좌표계, 행렬 수학, 내적, 외적, 쿼터니언, 노말 벡터, 탄젠트 기저 등등을 확실히 이해하고 있어야 하고 이것들(셀수 없이 많은 다른 것들도)이 어떻게 변환과 조명, 기하에 유용한지를 이해해야 한다. 알고리즘의 실행 시간을 위해 빅-O 표기법을 배우고 색상 공간, 감마 보정, HDR의 무슨 의미인가 등등을 배워야 한다. 몇가지 기본적인 조명 모델을 배워야 한다. - 램버트, 퐁, 블린 등등.
Software
In my experience, Visual Studio is pretty much universal as a code IDE (except for Apple, Linux, Android and Nintendo games), though you can of course use your favourite editor if you really want to, as long as you know Visual Studio. There is a free Express edition available from Microsoft (http://www.microsoft.com/express/Windows/), so it won't cost you any money to learn. The PS3 is a little different as there is a separate hardware specific debugger, but you should be able to learn that on the job.
소프트웨어
물론 당신이 정말 원한다면 당신이 가장 좋아하는 에디터를 사용할 수 있지만, 내 경험으로는 Visual Studio가 꽤 많이 세계적으로 사용되는 코드 IDE이기 때문에 (애플, 리눅스, 안드로이드, 닌텐도 게임을 제외하고) 적어도 Visual Studio는 알아두자. Microsoft에서 Express 버전은 무료로 사용가능하며 배우는데 어떠한 돈도 지불하지 않는다. PS3는 별도의 하드웨어 종속적인 디버거가 있어 조금 다르지만 직장에서 그것을 배울 수 있어야 한다.
You should be familiar with a source control system. Perforce (www.perforce.com) is a good choice as a lot of game studios use it and it's free for single users. Try to learn it on a project with other people as merging, branching and integration are good skills to have. With all source control systems, similar concepts apply so it's essential knowledge to have. Shockingly, my university course never mentioned source control and I was naive enough to believe that people just shared code over the network or on floppy disks.
당신은 소스 컨트롤 시스템에도 친숙해야만 한다. 퍼포스가 많은 게임 스튜디오에서 사용하기 때문에 하나의 좋은 선택이될 수 있고 개인 사용자에게 무료다.
머징, 브랜칭, 인티그레이션은 알아둬야 할 좋은 기술이므로
다른사람들과 함께 하나의 프로젝트를 통해 배우도록 노력해라. 모든 소스 컨트롤 시스템에는 유사한 컨셉이 적용되기 때문에 필수적인 지식이다. 놀랍게도 나의 대학 강의에서는 소스 컨트롤에 대해 전혀 언급하지 않았고 나는 사람들이 단지 네트워상으로나 플로피 디스크로 코드를 공유한다고 믿었었다.
As you're unlikely to have access to devkits at home or in university, you'll most likely be learning your skills on PC. In what may come as a surprise from someone with a decade's game development experience, I don't know much OpenGL as there's never been a pressing need for me to learn it. Most PC games use DirectX, though if you learn DirectX 11, make sure you also learn DirectX 9 as it's still current for Xbox 360 and many PC games still use it to support the dwindling, but still large Windows XP market. DirectX 10 is completely superseded by DirectX 11, so it is not worth learning (you can write DirectX 11 games for DirectX 10 hardware, and even DirectX 9 hardware).
집이나 학교에서는 개발킷에 접근할 수 없기 때문에 PC에서의 기술을 배워게 될 것이다. 십년간 게임 개발 경험을 가진 사람에게 놀라움으로 다가올만한게 나는 OpenGL을 배워야만 할 필요가 없었기 때문에 잘 모른다. 대부분의 PC게임은 DirectX를 사용하고 만약 DirectX 11을 배웠더라도 Xbox 360과 줄어들고는 있지만
윈도우 XP 시장이 여전히 크기 때문에
많은 PC 게임들이 여전히
DirectX9을 사용하고 있어서 배워야 한다.
(하지만 번역중인 현재는 Window 10이 나왔기 때문에 DirectX 11로 봐도 될 듯 하다!) DirectX 10은 완전히 DirectX 11에 의해 대체되었기 때문에 배울 필요는 없다. (DirectX 10 하드웨어, 심지어 DirectX 9 하드웨어에서 돌리는 게임을 DirectX 11로 작성할 수 있다.)
It's also definitely worth learning a graphical debugger. PIX for Windows isn't as good as the Xbox 360 version, but there are fantastic free alternatives (Intel GPA - http://software.intel.com/en-us/articles/intel-gpa/, Nvidia Parallel Nsight - http://developer.nvidia.com/nvidia-parallel-nsight). These tools are not just for performance tuning on the GPU - they're also for debugging your draw calls, working out why something doesn't draw, why it looks wrong, and so on. You can also learn about how a GPU works as you can see all the renderstates, shaders, meshes, textures, etc for any draw call in a frame and really understand what the GPU is actually doing with the data you give it.
또한 그래픽 관련 디버거는 배울 가치가 있다. PIX for Windows는 Xbox 360 버전만큼 좋지 않지만 멋진 무료 대체 프로그램들이 있다. (Intel GPA, Nvidia Parallel Nsight) 이 툴들은 GPU상에 퍼포먼스 튜닝을 위한 것 뿐만 아니라 드로우콜, 왜 어떤것이 안 그려지는가, 왜 이상하게 보이는가 등등을 디버깅할 수 있다.
한 프레임 안의 어떠한 드로우 콜에 대해서
렌더 스테이트, 쉐이더, 메쉬, 텍스쳐등 모든것을 볼 수 있기 때문에 GPU가 어떻게 동작하는지에 대해서 배울수 있고 GPU가 당신이 보낸 데이터를 가지고 실제로 어떤 일을 하는지에 대해서 이해할 수 있게 된다.
Other Duties
As a graphics coder you'll probably have to do some tools work too, working with mesh compilers, animation compilers, plugins for Maya/3DS Max or in-house editors for the artists to use. Remember that your job is to provide technology to support the artists in their daily work, so it needs to be presented in a friendly manner. If you give your art team a tool that lets them tweak some coefficients of a fancy rendering algorithm and they have no idea what the numbers mean, they probably won't use it. Also, technical artists are your friends - they're the best people to talk about requirements for artists and to work out the best workflow for the content creators.
다른 의무들
그래픽스 개발자로서 당신은 또한
메쉬 컴파일러, 애니메이션 컴파일러, Maya/3DS Max 플러그인이나 아티스트가 사용하는 인 하우스 에디터와 같은 몇개의 툴들을 다룰 수 있어야 한다. 당신의 일은 아티스트들이 일상 업무를 지원해주기 위한 기술을 제공하는 것임을 기억하고 그들에게 친숙한 방식을 제공해야 할 필요가 있다. 만약 당신의 아트 팀에게 환상적인 렌더링 알고리즘을 위한 몇개의 계수 값을 바꾸기 위해서 하나의 툴을 제공한다면 그들은 그 숫자들이 의미하는 것에 대해 알지 못할 것이고 아마도 사용하지 못할 것이다. 물론 테크니컬 아티스트들은 여러분의 동료이다. - 그들은 아티스트들의 요구사항에 대해서 이야기할 수 있는 가장 좋은 사람이고 컨텐츠 생성을 위한 가장 좋은 워크플로우를 찾아낸다.
It's also good to learn general performance and optimisation techniques as this often falls to the graphics/engine team to do. You probably won't have to write any (or very little) raw assembler, but you ought to be familiar with what the C/C++ compiler is doing to your code, how to spot problems and what to do about them. For example, one of the biggest performance problem will be L2 cache misses (you lose hundreds of cycles per miss on all modern hardware), so learn techniques to reduce them (almost always changing the data, not the code is the fix).
또한 그래픽스/엔진 팀이 해야하는
일반적인 퍼포먼스, 최적화 기법을 배우면 좋다. 당신은 아마도 거의(혹은 매우 적게) 어셈블리어를 작성해야만 하지는 않을 것이지만 C/C++ 컴파일러가 당신의 코드를 어떻게 하는지, 어떻게 문제점을 발견하고 그것들에 대해서 무엇을 하는지에 대해서는 친숙할 필요가 있다. 예를들어 가장 큰 퍼포먼스 문제중 하나는 L2 캐쉬 미스 문제일 것이다. (모든 현대 하드웨어에서 미스당 수백 사이클을 잃어버린다.) 그것들을 줄이기 위한 기술을 배운다. (거의 항상 코드가 아닌 데이터를 변경하는 것으로 해결한다.)
Online Learning Resources
Online resources are a goldmine, and there's much better stuff out there than there was when I was at university as a lot of companies publish papers on their techniques which are pretty useful stuff. A few examples...
http://www.valvesoftware.com/company/publications.html
http://publications.dice.se/
Also there are a few good blogs posting regularly about graphics. A few good examples...
http://aras-p.info/blog/ - Lost in the Triangles. Aras Pranckevičius's blog (a lead programmer for Unity).
http://www.realtimerendering.com/blog/ - Real Time Rendering has good information (also the book is a worthwhile read!)
온라인 강좌
온라인 리소스는 금광과 같고 내가 대학교에 다닐때 보다 훨씬 더 좋은 것들이 많다. 많은 회사들이 자신들의 기술에 대해서 매우 유용한 자료들을 공개하고 있다. 예를들어 위 링크와 같다.
또한 그래픽스에 대해 규칙적으로 포스팅 하는 좋은 블로그들이 몇개 있다.
위에 링크 참조!
Make sure you read the relevant presentations from GDC (very useful) and SIGGRAPH (slightly less useful as a lot of it is for non-realtime graphics, but useful as a crystal ball for future techniques).
My last handy tip is that if you live near a big dev studio, find out which pub they go drinking at after work and join in on a Friday night. You'll learn a lot just chatting with developers. You can also join twitter and talk to many games developers there who are willing to share their experience.
GDC(매우 유용한)와 SIGGRAPH (리얼타임이 아닌 그래픽스에 대해 더 많이 유용해서 약간 덜 유용하지만 미래의 기술들에 대해 수정구슬(?)과 같이 유용한) 관련있는 발표를 읽어라. 나의 마지막 유용한 팁은 만약 당신이 큰 개발 스튜디오 근처에 산다면 그들이 업무가 끝나고 술 마시러 가는 펍을 찾고 금요일 밤에 가라. 당신은 개발자과 많은 이야기를 나누며 배울 수 있을 것이다. 또한 트위터에 가입하고 그들의 경험을 기꺼이 공유해줄 많은 게임 개발자들과 이야기를 나누어라.
출처: <http://www.altdev.co/2011/05/10/so-you-want-to-be-a-graphics-programmer/>
