PRACTICE Makes Better: Self-Improvement Through Game Design

Original Author: Ben Serviss

A slide from Robert Yang's talk, Well-Made: Back to Black Mesa.
A slide from Robert Yang’s PRACTICE 2013 talk, “Well-Made: Back to Black Mesa.”

“How do you let people betray each other?”

“How do you handle gay marriage?”

“How do you get people to want to play?”

No, the above aren’t results from a Google auto-complete gone wrong. These were just a few of the questions posed at the Open Problems session at PRACTICE: Game Design in Detail, the NYU Game Center’s annual game design conference held last week. Now in its third year, the weekend conference brings together game designers working in digital games, analog games, and other disciplines of design for a series of in-depth discussions about game design.

Despite talks by name-brand designers like Warren Spector, Michael Brough and Sean Vanaman on emergent narrative, designing experimental games and postmortems on past successes, it was the Open Problems session that truly made the event special.

Between sessions, conference staff set up games referred to in the talks so attendees could contrast the actual game with the speakers’ thoughts. (Source: dylanpm. Click for video)

At Open Problems, designers bring design issues they’re wrestling with to the assembled brain trust for on-the-spot input, and it was at this year’s session that I realized a core truth: Much more so than other mediums, the practice of game design is about relentless, accelerated self-improvement.

Where the writer might have an editor or a group of readers, the sculptor might show works-in-progress to a select few, and the filmmaker might screen a rough cut for production staff, the game designer aims to get a project in front of as many people as possible as soon as possible to test his or her assumptions against reality.

Less subjective than most authored media, the interactive nature of games helps illustrate objective truths through testing.

For example: If players keep running by the exit door and missing it, it’s highly likely that you need to make a change to make the door stand out more.

Only by embracing these truths and changing, bit by bit, can a game improve enough to fulfill its intended function better than it did before.

The Truths Are Out There

Of course, the search for ways to improve the self-improvement process is not limited to game design and development. The opening talk of the conference, “B-boy Jams: The History and Organization of Breakdance Competitions,” gave attendees a crash course in the history of Hip Hop with regard to breakdancing as well as a new lens through which to consider issues of design.

Yes, the struggling NYC breakdance scene is kind of similar to the equally-small competitive fighting game circuit, as one attendee pointed out. Yes, rule variants for breakdance battles inherently involve aspects of design that aren’t common to video games – like the skill of the contenders, the high level of braggadocious posturing inherent to the activity and the need to keep spectators entertained.

Robert Yang game development
A slide from Robert Yang’s PRACTICE 2013 talk, “Well-Made: Back to Black Mesa.”

Yes, the design of the events themselves may be a way to enable faster growth for the breakdancing scene – and yes, this would be game design at work.

At the conference’s closing session, involving a – you guessed it – group feedback dialog on what attendees liked, didn’t like, and would like to see next year, there was a clear push for more outside perspectives.

The crowd called for theatrical designers, breakdancers, urban planners, industrial designers and more voices outside traditional game design to share their experiences. Of how they can touch people in their own disciplines, even if they share little in common with traditional games.

The suggestions went on and on. As if by unspoken consensus, the group made it clear: they were hungry for more perspectives than what games themselves had to offer. Hungry to become more informed in what the world had for them.

“Theme park designer,” someone said. “Playground designer,” someone else said.

How many more occupations could we name? How many other perspectives would we want to hear from?

It was almost as if the search for self-improvement, itself, had become a game.

From Rags To Game Dev

Original Author: Josh Hughes

Hello! My name is Josh Hughes. I’m a 30 year old in Great Falls, Montana crazy enough to think my crew and I can make it in the game industry. In one form or another, I’ve been trying since my Junior year in High School. My 10 year high school reunion was Spring 2012, and the road my family walked since I graduated was a weird one, but we walked it, made it our own and through every road bump faced I’ve fallen more in love with the art form of video games!


For the start of the story, I guess we could go back to when I was in grade school and told my mom that my future would involve game design. Or, how (after playing Street Fighter and becoming obsessed with fighting games) in Middle School I couldn’t wait to come home so I could play Battle Arena Toshinden and write fighting game design docs on my mom’s old school word processor. Another potential start could be me (again, in Middle School) bawling my eyes out to the infamous Aerith death scene in Final Fantasy VII and falling in love with how fantasy stories can elicit real human emotion. Regardless, the real introduction to the industry came (like I mentioned before) in my Junior year of High School.


Dev’ing To The Choir


At that time, I made contact with a start up game studio. I grew up in a Christian family, and this studio was looking to mix some of the Christian belief system with game design and I was interested. I wrote the Lead Game Designer and we formed a fast friendship. I told him how I was in love with video game stories and how they grab players and make them a part of the journey, and he offered to bring me on staff so I could help write, come up with characters and learn game design. I was ecstatic!


Pretty much all of us at the studio were Christians, so our assumption was we should hit Christian Publishers. We were also all gamers so we wanted to make something we’d actually play of our own accord (pretty much all Christian games at the time –and even now- were comprised of taking secular games and giving them overt religious references and bright ‘family friendly’ visuals). So, we fashioned the story of an angel who gets trapped inside a suicidal teen’s mind. This allowed us to go with darker survival horror-esque themes (which I loved as a Resident Evil nut at the time).


We learned a lot making that first game and even got some accolades (including from a site that made fun of Christian games advising us they were canceling their plan to make a video mocking our game because it was the first one they actually had fun playing, it was great to know our art could speak past pre held bias and faith/culture barriers).


Unfortunately, Christian Publishers didn’t see it the same way. They told us they liked what we were doing, but the response we got every time was they were afraid of what the Christian Bookstore Market would do to them if they supported a game with our kind of imagery in it. We debated several solutions on the team, but at the same time my family’s home life was about to get flipped upside down.


Losing Everything


My brother, Trevor, is 6 years younger than me. The game I helped make came out the year I graduated High School (2002), which was also the year Trev entered 7th grade and a friend pressured him to try out for football. After failing the physical 3 times, doctors discovered what was wrong. A genetic dysfunction caused his bladder to balloon 9 times an average size and back urine up into his kidneys, which were basically poisoned to death. As of 2013, he’s had over 70 surgeries (we’ve stopped counting) and is on the transplant list as well as home dialysis (for which our Mom and I had to train a month to be assistants on).


When we first learned this, our father wasn’t pleased. Christmas that year he told Trev to his face he didn’t want the bills of a sick child, so he took the family van and left down south. After he left, we found out he refinanced the house several times behind Mom’s back and the debt collectors were calling. Since they couldn’t reach our father, it fell on Mom’s head. We had to go bankrupt and lost our house as well as the car Mom bought to replace the van, and we moved in with her parents. Trev’s pediatrician also told Mom that, if she wanted to save Trev’s life, she needed to quit her job of 18 years managing a group home to focus on his health and get him on government assistance to assure he can get the care he needed. She gave up her career and I took a dead end job at a call center to help make ends meet.


One day, while we were in the waiting room for one of Trev’s surgeries, I told Mom we had to change our tactic. Normal wasn’t working for us, we had to try crazy. Crazy meant taking back our lives and doing what we love. Crazy meant starting a game studio.


Taking It Back


I left my friend’s studio on good terms (he and I are still friends to this day) and Trev and I started Team KAIZEN ( under our previously founded company Add-A-Tudez Entertainment Company (AEC). Our local Small Business Development Center, The Great Falls Development Authority, found out about us through a long chain of events. They told us, if we were serious, they’d take us under their wing and train us to be investment ready entrepreneurs. Rebecca Engum of the Authority sunk herself into the industry so she could be our Jedi Master, and we owe more to the GFDA than we can possibly put into words! Rebecca helped us realize our lofty goals were achievable through hard work and helped us realize we could aim higher. Our goal wasn’t to just take back our lives anymore, it became our goal that within 5 years of receiving principle funding for our projects Great Falls and North Central Montana would become the Park City for Indie Video Game Entrepreneurship!


Around that time, a group called Fortitude Entertainment Group also found out about us. They reached out and told us they were looking for artists who were Christian but not looking to develop for the Christian Bookstore Market. After my experiences at my friend’s studio, this sounded like a dream. Fortitude signed a Strategic Alliance Agreement with us (we had paralegals look over it and they said it was a dream contract with no hidden strings) and said they wanted to fund development of our first IP, Shattered Soul. Shattered Soul is the fighting game concept Trev and I came up with as a way to resurrect the crazy 3D fighters  the 90’s like Toshinden and Bloody Roar.


Of course, that dream contract didn’t look so dreamy 3 years down the road when we didn’t have any funding yet or even a countersigned copy of the contract for our records (despite asking several times). Finally I decided to go to Fortitude’s site and see hat projects they were involved with or if there was any news. The site wasn’t there. A quick Google search uncovered that Fortitude had gone under, and I found out they had taken one of our animators behind my back to do their own projects (he thought I was aware of it) before they tanked.


I was blown away. We weren’t even the worst case of what Fortitude had done to people (one prominent rock musician they were working with lost millions). Regardless, it was time for us to jump back into the driver’s seat!


Finally Getting Traction


We developed a pitch for Shattered Soul and ended up pitching to a major publisher. Reps from this publisher spent about 90 minutes with us on the phone going page by page, telling us what they did and didn’t like. At the end, they asked us to make a tech demo and repitch. After some pitfalls here and there, our team is now working on a 2 fighter 1 arena demo in Unity and we’re currently in animation stage.


Around the same time, Sony announced on the PlayStation Blog that they teamed up with a crew named HASTAC (Humanities, Arts, Science and Technology Advanced Collaboratory for a contest. To enter, people just had to make a LittleBigPlanet level that could teach Science, Technology, Engineering and Math (STEM). I’m a HUGE ride/roller coaster fanatic, so I was already building rides in LBP and had a few I hadn’t published yet. So, I put them in a straight line with ride attendants that explained the different forces and engineering concepts in play.


I thought I bombed out, but I didn’t care because I had fun making it. A few weeks passed and I got notification I was a finalist, cool! Then, 2 weeks later, I got the shock of my life: I was a grand prize winner, Best in Show for Physics, and Trev and I needed to be in New York so HASTAC could announce at the Games 4 Change Festival that we were being given a $40,000.00 grant to extrapolate my 1 level into an entire free to play LBP pack! I hit the floor!


Going out to New York, I thought our experiences in the Secular game industry would translate pretty easy. I thought edu-games were just normal games with academia mixed in, boy was I wrong…


HASTAC pulled the winners into a separate room so we could discuss what the grant program detailed and expected. Those of us with a traditional gamer background were wondering about confidentiality and what we could/couldn’t show during the development of the levels. So, we asked HASTAC if we could invite outside people to beta test our levels. They started rushing around in a controlled panic trying to figure out how to get us certification for human experimentation! (As it turns out, you can beta test levels without this. However, if you test whether or not people are learning from your content, you cross the line into human experimentation and need an IRB board to monitor the ethics and such.)


It was at this point we realized this was the meeting of 2 worlds, 2 worlds with very different terminology and rhythms. HASTAC introduced us to a whole new experience that was directly adjacent to the game industry, but with subtle differences we had to learn!


LittleBigPlanet 2 released during our work with HASTAC, so we did our pack in that ( link: ).


Secondly, we also teamed up with our local school system (which had some representatives in the audience at our talk) to create a test program we call LittleBigPlanet Club. In LBP Club, we have kids learn game design in LBP then create levels/mini games infused with STEM or History. The first year had 8 kids (4 boys/4 girls grades 4-6). Year 2 had almost 60 kids split across 3 schools. Now, we’re doing it as a camp format with a local art museum as well as working with VisionNet to develop a teleconferencing version to reach out to rural and distant schools.


We love this program because it allows us to spread the passion for game design, and we’ve seen it work wonders on the participants. It resonates with many kinds of students, but most especially with ones disenfranchised by normal school life. There is entire leagues of kids who aren’t sports stars or are the top of the academic pile, yet these students found their voice in game design. Through game design, they had something they were good at , something to be proud of! We have had several instances of students who had trouble communicating with adults/peers at the beginning of the year finding their feet and proudly giving news interviews by the end of the year. We’re continuing to refine our curriculum and are even taking some of our star pupils and making them ‘Win-terns’, where we teach them more about the industry through hands on experience at the camps. To see some of the kids’ work, check out  

The indie roadmap

Original Author: Cedric Guillemet

Last week I had lunch with some friends who enjoy their new-indie game developer status. We discussed game ideas, concepts, some mechanics… And right after the first beer, they told me: “We don’t have anything playable yet but I’m working on the decal system.” This brought me back to my own troubles working on .the rush//. I tried to make them understand that if when you don’t have something playable within the first week of development, even if you spend the next 10 years in production, you won’t have a good game….or even just a game. With my humble experience I’ve made an Indie GameDev Roadmap.

It doesn’t guaranty you will make a good game but not following those simple rules will decrease your chances to release something worthy.

Step 1 : The first hour/the first night.

The universe, Minecraft or your game, all started with a big ambition.

Always Multiply Your Estimates by π

Original Author: Yossarian King

Project estimation is a black art, nowhere more so than in game development. I once heard of a mysterious cabal of numerologists that multiplied their time estimates by π. The practice allegedly gave them sufficient buffer for new requirements, testing, iteration, and other arcane changes in scope.

This struck me as curious and arbitrary, but I was intrigued. I am now delighted to report that I have been able to put their Circular Estimation Conjecture on a firm mathematical footing.

The Circular Estimation Conjecture: You should always multiply your estimates by pi.


Allow me to explain.

Someone — a designer, your lead, the exec producer, a friend, your mom — asks you to do something. You think for a bit, jot down a few notes, consider what’s required, and come up with a plan and an estimate.

What you planned to do.


But things change. Turns out there was some stuff your designer / producer / lead / friend / mom neglected to mention, and as you did the work you had some ideas to improve it further. Your scope grew.

 What was needed.


And of course it didn’t all go smoothly. Your first try was an instructive failure. Then you rushed the second attempt and created a bunch of problems that took a while to fix. You spent two extra days to look at an alternative solution. All in all, you followed a positively circuitous path to your objective.



So how long did your journey take compared to your original plan? Turns out the numerologists were right …



And there you have it — whatever you think when you start, once you get through the research, design, discussions, prototypes, failures, testing, requirements churn, and all the other vagaries of the creative process, you will indubitably have done π times as much as you originally planned.

Now some may question my mathematical rigour, and even dispute what I believe to be the incontrovertible conclusion. People may claim that the correct multiplier is not in fact π — but that it is rather 2, or √2, or e, or the golden ratio φ. I am, however, aware of no one who claims the multiplier is less than one.

Regardless of your numerological leanings, the point is that you must give yourself permission to admit that — when you start a project — you don’t have the full picture, you don’t know how things will go, and there is work ahead about which you have almost no idea. No amount of planning and task analysis can change that, so don’t try too hard. Instead, give yourself a plausible buffer and get busy doing the work.

Oh, and that to-do list you made last weekend? It’s no coincidence you only got about a third of the things on the list done. 😉

OpenGL dumb mistakes: the mysterious Perfect Circular Hole

Original Author: Adam Martin

I’ve got a long-running project around rendering 3D Earth in interesting ways. It’s being used in a game project, and some non-game stuff too. Here’s a recent screenshot:

I added a particle system that uses Vector Fields to move the particles based on arbitrary incoming data, and then wraps it round a globe. Yay!:


(click image for larger version)

…and then I increased the size of each particle, and something very strange happened. I wanted to splurge them out to be huge, but

The mysterious Holes Of Doom

… these weird holes appeared in the middle:


(click image for larger version)

WTF? I must have done something stupid. I double checked everything. I removed the textures. I switched from quads to basic tris, with vertex colours … but still, this perfect circle cut out of the center! My vertex and fragment shaders by this point were exactly one line of code!


(click image for larger version)

…I spent ages looking at this, trying to understand what could possibly create “holes” in my geometry. They were obviously holes – you can see through them!

Eventually, tired, and with lots of more important work to do, I gave up, shelved it, went off to do other things. Then today I suddenly realised the problem. I’m sure it’s obvious to most of you, but it’s taken me ages to figure it out.

When a hole is not a hole

And this is what makes it worth posting: the hole is not a hole.

My particles are on a 2D plane, so that I can calculate simple x/y coords from a vector-field. Great. My shader wraps the corners to a sphere. I’m rendering quads / tris like this:

Great. But GL doesn’t “bend” the edges – it draws straight lines between corners. So … when I made my tris larger … the corners were still slightly above the surface of the globe.

…and the EDGES were still slightly above

…but the centers … slightly interesected the globe. And so, of course, the depth-test cut them out. In the diagram below, it looks as if the quad moved closer to the center of the globe – but it hasn’t. The corners are all still the same height above the surface – only the middle has (implicitly) gone “inwards”.

Lesson to self: sometimes, it’s not a triangle-with-a-hole-that-I-can-see-through … instead, it’s a triangle-that-has-a-sphere-poking-through-the-middle


(originally posted on  

4 Beginner Projects for Launching into Game Programming

Original Author: Brice Morrison


Photo credit: minipixel

Lots of students and beginner developers ask me, “What’s the fastest way to become a game programmer?”

Once you’re an amazing programmer, the world is open to you. You can make your own indie projects. Other developers and artists will want to work with you. You can get a job at a small or a large studio. The possibilities are endless!

So how can you turbocharge your skills as best as possible? There are lots of techniques out there, but the trick that I use in my personal life and the advice I give to my students is always the same: build your skills through working on projects.

Experience is the best teacher. By designing your own project that you then execute, you learn innumerable skills that you would never learn from just reading a book or a tutorial. Think about it. If you just read a tutorial called “How to do Collision Detection in C++” then you aren’t going to be a master at collision detection. Heck, you’d still have to refer back to the article to know what you were doing! It wouldn’t be practiced – it wouldn’t be internalized.

On the other hand, if you decide you want to learn collision detection in C++, and then you design a project for yourself that involves lots of collisions, by the time you’ve finished that project, you’ll be at least at an intermediate skills level, if not an expert.

Does it take more work than skimming a book or tutorial? Yes. But is it more effective? Absolutely. You want to learn by doing.

In this article I’ll cover four projects that I think are perfect for beginner game programmers to get them up to intermediate level, in order. Then we’ll talk briefly about how to design your own projects for the purpose of learning skills.

Project #1: Simple Text Game


Back in the days before GUI’s (graphic user interfaces), many of the fun games were just all text. You’d have a console and enter commands, and see what happens. If you aren’t familiar with this genre, here is a link to an online version of Zork, one of the earliest interactive fiction games. Players explore the world, typing text as commands and moving about, talking to people, exploring objects, and solving puzzles.

It’s amazing how much fun you can have without any images at all, just text and your imagination. The image above is an old Kirby text based adventure game where you type in commands and explore the world. I wrote this a long time ago in Visual Basic, but today it could just as easily be written in Java.

The first project I always recommend as an introduction to programming is one of these simple text games. It’s ideal for a few reasons:

  • Learning how to deal with logic (if/then/else, case/switch)
  • How to deal with variables
  • How to communicate concepts to the player through text and numbers
  • Generally, how to make a program and turn it into an executable or flash file
  • Familiarity with a basic programming language (Java or Flash Actionscript 3 are good places to start)
  • Don’t have to worry about images, animations, etc yet

In short, working on this game will open doors to learn even more valuable skills and more complex game titles.

You can also add sound effects and music, which can make even a simple text game come alive. For the Kirby game I added background music depending on what area you were in, which made the world feel much bigger. Building your own game with even a few simple rooms will do wonders to get you started with beginning game programming concepts.

Project #2: RPG Battler

After you get an interactive fiction under your belt, it’s time to get artsy with some images!

An RPG battler is a good next step project. You have your character and they have different moves, and you fight an enemy, trying to knock down their HP. Think of it as original Final Fantasy or Pokémon without the overworld where you walk around.


This is a screenshot from an RPG battler game that I put together in Flash. It consists of an image of you, an enemy, HP bars, and buttons to click for your moves each turn. It may not look pretty, but it was good to teach many basic concepts.

Starting to put in images is a good introduction to the visuals part of game development. You can either make the images yourself or you can start to learn to collaborate with another artist. The screenshot above is some simple “programmer art” that I put together along with borrowed sprites from another game. This worked great because it allowed me to focus what I was trying to learn at the time: the programming side.

The skills that you learn by making a game like this are fundamental to programming all games. They include:

  • Handling sprites
  • Keying animations (if you have them)
  • Coordinate positions
  • Hit boxes (for clicking buttons)
  • Mouse input
  • Visual feedback

Once you make a game like this, you’ll be well on your way to some more interesting games, such as…

Project #3: Puzzle Game

Doing a puzzle game is a great next step for a couple of reasons. A puzzle game consists of:

  • Standard pieces that follow certain rules
  • Pieces are laid out on a board or level
  • Multiple levels
  • Some type of scoring
  • ADVANCED: Some type of way to save and load your game

Some examples of good puzzle games to model after are Minesweeper, Candy Crush Saga, or Triple Town. All of these games are a lot of fun without many moving parts.


Here’s a simple example game I built in Flash. Each level is made up of a grid with different pieces. Trees, grass, water, etc. Each piece has certain rules. By clicking each piece, the player moves through each level until they complete the game.

By doing a game like this, you learn a lot of skills that build on the skills from your previous game, including:

  • Constructing levels from pieces
  • Creating grids and coordinates
  • Creating classes and rules for certain pieces
  • State machines
  • Saving and loading levels
  • Making a progression or level select screen
  • Storing information in memory and retrieving it

Note that I’m NOT talking about puzzle games that have real-time movement or collision (we’ll get to that in a minute). You’ll have more than enough to learn with just simple step-by-step gameplay. This rules out games like Tetris where blocks are falling down and things are animating on timers. You want to focus on something that’s turn based, where things don’t change until the player takes a turn.

This is also great point to start publishing your games and getting feedback as well. If you’ve never shared your games and gotten ratings or comments, then starting to do so is VERY enlightening. Being able to interpret feedback correctly is key to getting better as a developer.

Project #4: Action Game


Finally, doing an action game is a great next step for a couple of reasons. An action game consists of:

  • Gameplay that depends on timing or time pressure
  • Collision
  • Monitoring frame rate
  • Simple physics, like gravity
  • Possibly third party resources, like Flixel

Some examples of good puzzle games to model after are Angry Birds, Canabalt, or classic Super Mario.

In an action game, you’re really learning a lot of the same problems that come up over and over again in all games. How do you make collision believable but not too sensitive? How do you keep the game from chugging so slowly that it affects the fun? How do you design the levels, the timers, the moves and controls?

By the time you’ve finished all four of these games, you will have mastered a number of the most common game programming skills needed to continue on. You’ll be able to start dreaming up a number of new ideas to try out.

So what next?

Designing Your Own Projects

By starting to do these projects, you’ll begin to pick up beginner programming principles that you’ll be using the rest of your life. But what next?

Now that you get the technique, the best and fastest way to make yourself into a lean, mean game programmer is to start designing your own projects. Start by selecting some skills you want to learn. How about procedural generation like Minecraft? How about a 3D game? How about a game where players can play against each other?


Once you pick the new features or skills you’d like to learn, then come up with a simple game that uses those components. Then design it and build it out. By the time you’re done, you’ll be well versed in the knowledge. Through the project you’ll likely do lots of research, look up lots of tutorials, and run into tons of bugs and problems. But by the end, because you learned by doing, you’ll be much further along than someone who just read and did nothing.

For more info on game careers, design, and development, head over to Complete Game Development Toolkit

How to become a Graphics Programmer in the games industry

Original Author: Oliver Franzke

As we were recently hiring a new Graphics Programmer at work I had to identify what kind of technical knowledge and skills we would expect from a potential candidate. Although this definition will be somewhat specific to what we look for in a candidate, it might still be of interest to other coders trying to score a job in the industry as a Rendering Engineer.

This post might help you to identify areas to learn about in order to get you closer to your goal of becoming a Graphics Engineer, whether you just finished your degree or perhaps have been working in the games industry in a different role. Alternately, if you are a seasoned Rendering Programmer, then you know all of this stuff and I would love to hear your comments on the topic.

Know the Hardware

Learning about the strengths and weaknesses of the hardware that will execute your code should be important for any programmer, but it’s an essential skill for a Graphics Engineer. Making your game look beautiful is important; getting all of the fancy effects to run at target frame rate is often the trickier part.

Of course, it would be unrealistic to expect you to know every little detail about the underlying hardware (especially if you are just starting out) but having a good high-level understanding of what is involved to make a 3D model appear on screen is a mandatory skill, in my opinion. A candidate should definitely know about the common GPU pipeline stages (e.g. vertex- and pixel-shader, rasterizer, etc.), what their functionality is and whether or not they are programmable, configurable or fixed.

Very often, there are many ways to implement a rendering effect, so it’s important to know which solution will work best on a given target device. Nothing is worse than having to tell the artists that they will have to modify all of the existing assets, because the GPU doesn’t support a necessary feature very well.

For example, the game that I am currently working on is targeting desktop computers as well as mobile devices, which is important because mobile GPUs have very different performance characteristics compared to their desktop counterparts (check out my 5 minute micro talk on this topic if you are interested). Our team took this difference into account when making decisions about the scene complexity and what kind of effects we would be able to draw.

A great way to learn more about GPUs is to read chapter 18 of Real-Time Rendering (Third Edition), because it contains an excellent overview of the Xbox 360, Playstation 3 and Mali (mobile) rendering architectures.

Good Math Skills

Extensive knowledge of trigonometry, linear algebra and even calculus is very important for a Graphics Programmer, since a lot of the day to day work involves dealing with math problems of varying complexities.

I certainly expect a candidate to know about the dot and cross products and why they are very useful in computer graphics. In addition to that, it is essential to have an intuitive understanding for the contents of a matrix, because debugging a rendering problem can make it necessary to manually ‘decompose’ a matrix in order to identify incorrect values. For example, not that long ago I had to fix a problem in our animation system and was able to identify the source of the problem purely by looking at the joint matrices.

In my opinion, a candidate should be able to analytically calculate the intersection between a ray and a plane. Also, given an incident vector and a normal, I would expect every Rendering Engineer to be able to easily derive the reflected vector.

There are plenty of resources available on the web. You can find some good resources 3D Math Primer for Graphics and Game Development” does a great job explaining a lot of the fundamentals like vectors, matrices and quaternions to name just a few topics. I would also strongly recommend attempting to solve some of these problems on a piece of paper instead of looking at a preexisting solution. It’s actually kind of fun, so you should definitely give it a try.

Passion for Computer Graphics

An ideal candidate will keep up to date with the latest developments in computer graphics especially since the field is constantly and rapidly advancing (just compare the visual fidelity of games made 10 years ago with what is possible today).

There are plenty of fascinating research papers (e.g. current SIGGRAPH publications), developer talks (e.g. GDC presentations) and technical blogs available on the internet, so it should be pretty easy to find something that interests you. Make sure to check out the blogs of fellow Rendering Engineers for some really inspiring articles!

Of course implementing an algorithm is the best way to learn about it, plus it gives you something to talk about in an interview. Writing a cool graphics demo also helps you to practice your skills and most of all it is a lot of fun.

If you want to maximize your chances of getting a job make sure to spend some time making your demo look pretty. You may have implemented the most efficient tessellation algorithm, but if people can’t see what’s going on they might not be as impressed as they should be. Creating visually pleasing images is a big part of the profession, so it’s generally a good idea to show that you have this skill as well.

Performance Analysis and Optimization

One of the responsibilities of a Graphics Programmer is to profile the game in order to identify and remove rendering related bottlenecks. If you are just starting out I wouldn’t necessarily expect you to have a lot of practical experience in this area, but you should definitely know the difference between being CPU and GPU bound.

An ideal candidate will have used at least one graphics analysis tool like PIX (part of the DirectX SDK), Intel’s GPA. These applications are available for free allowing you to take a closer look at what’s going on inside of a GPU, isolate bugs (e.g. incorrect render-state when drawing geometry) and identify performance problems (e.g. texture stalls, slow shaders, etc.)


The job of a Graphics Programmer is pretty awesome since you’ll be directly involved with the visual appearance of a product. The look of a game is very often the first thing a player will know about it (e.g. trailers, screenshots) which has been very gratifying for me personally.

Truth be told, you won’t be able to write fancy shaders every day. You should be prepared to work on other tasks such as: data compression (e.g. textures, meshes, animations), mathematical and geometry problems (e.g. culling, intersection computations) as well as plenty of profiling and optimizations. Especially, the latter task can be very challenging since the GPU and the associated driver cannot be modified.

To sum up, becoming Rendering Engineer requires a lot of expert knowledge, and it is certainly not the easiest way to get a foot in the proverbial games industry door, but if you are passionate about computer graphics it might be the right place for you!

The Beginner’s Checklist

#gamedev Lead Quick Start Guide

Original Author: Mike Acton

Congratulations! You’re a lead. Now what? In general, whatever skills you’ve demonstrated that got you to this point aren’t the same things you’ll be doing from here on out (or at least not as much.) Not everyone is suited to a lead role or would be happy in one. Trust I believe you have every chance to excel as a lead; Otherwise, you wouldn’t be one.

What follows is a entry-level description of my expectations for a #gamedev lead. There are a lot of things to know and a lot of new skills to master, but my hope is that this will get you going for your first couple of weeks in your new role.

I expect you to read this.

Do not skim. Block out some uninterrupted time to read this guide and make sure you understand my expectations. Take notes for our follow up discussions.

  • Is there anything here that you don’t feel is completely clear?
  • Is there anything here you disagree with?
  • What do you think will be the real challenges with each of these expectations?
  • What do you think will be your practical approach to meeting each of these expectations?
  • Most importantly: Have a point of view. i.e. I expect you to adopt a position and risk that we disagree rather than simply agreeing or being apathetic about what I’m saying.

Congratulations! If it’s broken, it’s your fault.

There is no one thing that has more of an impact on the quality of the game, the cost of development, the engagement and happiness of the gamedevs and the future of the studio than leadership. A bad leader can do more damage than the rest of the team combined; A good leader can help to make every individual gamedev on their team twice as effective as they would be on their own.

I expect your process to reflect you.

I asked some gamedevs recently to list the most common reasons why gamedev sucks:

  • Studio closures
  • Canceled projects
  • Bad projects
  • Unhappy gamedevs
  • Overworking gamedevs
  • Unrealistic expectations
  • Layoffs
  • People who are incompetent at their jobs
  • Favoritism

All of these problems are leadership problems. None of these problems are process problems.

You must be wary of any process that purports to address these issues. Take the latest development fad with a truckload of salt and stay focused on being the best leader you can be. Actively research and learn what has worked and what has failed for others but ultimately adapt everything to what works best for you and your team.

If you absolutely must have a formula for doing your work, here’s mine: Figure out what doesn’t work and do less of that; Figure out what works well and do more of that.

I expect you to be a champion for the direction you’re given.

You probably have a lead. That might even be me. That lead needs to make decisions. When you agree with those decisions, things are easy. Anyone can be a champion for a decision they agree with. I don’t expect you to always agree. I do expect you disagree in private or in a leads meeting where that disagreement is encouraged. Outside that, I expect you to not just agree, but sell the direction to your team. Once the decision is made, I expect you to figure out how to make yourself believe in it. You should expect the same from your team.

I expect you to find the right problems to solve.

I expect you to know the problem space of your team better than I do. You spend much more time in your problem space than I do, so I certainly also expect you to be able to come up with solutions much better than what I could come up with. When I suggest what problems we should solve it’s based on the best information that I have. When you have better information, it’s up to you to speak up. If what I suggest doesn’t make sense, it’s up to you to tell me that. If there’s a better option, it’s up to you to bring that to the table. As soon as possible.

  • Is there anything you think we should remove from our development process?
  • What decisions of the past do you feel get in our way?
  • Where do you believe we are asking the wrong questions?

I expect you to delegate.

For some leads, this is the hardest part. You may in fact be the best person to solve a particular problem or implement a particular system. That does not mean you are always the right person. It’s difficult to help your team solve their problems when you are heads-down in the trenches with your own issues. You need to figure out what the best balance is. You need to consider what is best for the team. You need to appreciate your role as teacher and mentor on the team. Use your experience to develop your team so that (eventually) they can do what you have done best better than what you could have done it. They have the advantage of having you, you didn’t.

When you are working on implementing something yourself, remember you are setting the example and the bar for how you think the problem should be approached and solved. Take the time to step your team through your process so that you all can be more confident on some future problem that your team will even better than they already are.

Congratulations! If anyone on your team is off in the weeds, it’s your fault.

You are responsible for the work of your team. You are responsible for knowing how their work will affect the game and the players’ experiences. You are responsible for knowing how their work will affect development of the game and all the other gamedevs in the studio.

I expect you to provide clear values to your team.

In order to lead others you need to know yourself. Constant introspection is crucial to leadership. Understand what you value most and make sure you can articulate that to your team in a way they can understand and articulate to others.

If you are having a difficult time figuring out what your values are, take some time to answer these questions the best you can. We can discuss what you come up with and see if together we can’t work out how to describe what you value.

  • Why are you here?
  • Why games?
  • What does success mean to you?
  • What is most important to you about the player experience?
  • What is most important to you about the development experience?
  • What frustrates or irritates you most about the player experience?
  • What frustrates or irritates you most about the the development experience?
  • What frustrates or irritates you most about the yourself?
  • What are three things that you would like other gamedevs to say about you?
  • What are three words you would use to describe your point of view on technical issues?
  • What are three words you would use to describe your point of view on personal development?
  • When was a time when you felt a lead personally let you down?
  • When was a time when you felt a lead really helped you out?

I expect you to establish a clear direction for your team.

Your direction is the mission for your team. It should be clear. It should be a concise description of what you team ideally does. “Make good games” is not good direction because no one will argue with it. If no one can disagree with what you’re saying, you’re probably not saying anything. As a goal, it should be hard. It should also be a method of judgment for the team. For any given problem, they should be able to judge whether or not their proposed solution would take the team closer to the goal or further away without consulting you personally.

  • For instance your team may be focused on the Player Experience. Your direction might be: “Be Invisible. No player ever notices anything not directly related to their gameplay experience.”
  • Or your team might be making animation tools and your direction might be: “Frictionless experience. No animator is ever waiting on anyone else to complete their work. No animator should ever wait more than five seconds to see the results of their work in-game.”

Perhaps your team has more than one mission. Perhaps your mission changes over time. Don’t get too hung up on it. We’ll adapt as we need to.

I expect you to set clear expectations for your team.

Clear expectations is not micro-managing. It means that your team can predict with some accuracy whether or not you will think things are going as anticipated. (And if not, that your teams knows whether or not they are handling the unanticipated well.)

The easiest way to enumerate some of your basic expectations for any given problem, in my experience, is to simply ask yourself: “What would frustrate me if not done or not done well?”

Where setting expectations is most difficult, that’s where it’s usually most important.

  • You need clear expectations for those “soft” but extremely critical skills e.g. communication, growth, leadership, cultural fit, etc.
  • You need to draw a clear line to what results your gamedevs are ultimately responsible for.

I expect you to define problems and constraints for your team, not solutions.

Everyone on your team is here because they are problem solvers. Give them problems to solve not solutions to implement. They are the experts (or you are helping them to become the experts.) They will spend more time with the problem, more time with their tools, more time with the data than you possibly can. Always expect your team to come up with a better solution than you can envision with your limited information.

However it’s up to you to give your team the right problems. To provide the constraints to the solutions. And make sure the problems are just outside their immediate grasp. A Junior Engine Programmer will not be able to solve the same types of problems as a Senior Engine Programmer. But both need to be challenged.

I expect you to know what everyone on your team is doing.

You can’t help your team if you don’t know what they’re doing. You can’t figure out how the development pieces fit together if you don’t know what’s going on. And we’ll both be a lot less effective if we don’t know where things are at. There shouldn’t be any surprises.

Congratulations! If your team is not growing and improving, it’s your fault.

You will probably spend most of your time talking to your team, preparing to talk to your team, talking to others as the representative of your team, preparing to talk to others as the representative of your team or preparing your team to talk to others.

I expect you to understand your team.

You should know your team. The gamedevs on your team should know each other. Spend time with them. Ask questions about their background and hopes for the future. Know about the things most important in their lives. e.g. Their family, hobbies, religious beliefs, food restrictions, etc.

I expect you to put as much effort into the gamedevs on your team as they put into their work.

Every gamedev on your team will need something unique. It’s up to you to figure out what that is.

Along with constant ad hoc discussions, I highly recommend that you have scheduled one-on-one meetings with every gamedev on your team. I suggest those meetings are scheduled at least once every week or two weeks. Anything less than that will be a problem.

What should a one-on-one consist of? This will be unique to you and the gamedev you are talking to. But as a general framework,

  • Let them know whether or not they are meeting your expectations. Do not put this off. Do not avoid this discussion.
  • Answer any questions your gamedev may have. Listen to any feedback.
  • Ask probing questions.
  • I find 30 minutes to be a reasonable guideline. Times can vary greatly from gamedev to gamedev and situation to situation. Sometimes 10 minutes is perfect. Sometimes you need an hour or more.

Here are some questions you could ask in a one-on-one to help start a discussion. The goal is not necessarily to get the answer to the specific question, but to open the conversation and ultimately see if there’s anything you can do to help.

  • What concrete, specific feedback would you like to have about yourself?
  • What has been the same for a long time that you think needs some more attention?
  • What do you find most difficult?
  • What do you find most frustrating?
  • Where do you feel like you are being held back?
  • Is there anything you feel is wasting your time?
  • What do you think I need to be more aware of or paying more attention to?
  • What do you think you need to be paying more attention to?
  • What do you consider your next big career step? What are you doing to get there?

In addition to one-on-one discussions, I also highly recommend regular team meetings. Avoid rounds of status reports. That can be done over email. These meetings should be about reinforcing your direction, building the team and honestly discussing problems as a group in a safe environment.

I expect you to develop a leadership team.

If you have leads on your team, those leads as a group are also a team and have unique issues you must address outside the full team setting. I highly recommend separate leads meetings as a forum to discuss problems, issues with the development of particular gamedevs and honest feedback, including criticism of your decisions.

If you do not have leads on your team, you should be identifying those gamedevs that have the potential to be leads in the future and be actively working to develop them.

I expect you to be continuously training your team.

How good your gamedevs will be tomorrow is much more important than how good they are today. There are simply a lot more tomorrows. Every problem is an opportunity to train. Make sure your gamedevs are working on problems they don’t immediately know how to solve. If they do, perhaps it would be better to give it to someone else on your team that could learn more from the experience.

Train through the work itself, but also keep an eye open for more formal training opportunities and exercises. These are much more difficult to get right. Not everyone learns well in a classroom setting or feels comfortable doing group exercises. Just keep experimenting and you’ll find something that works for your team.

I expect you to help your team define their own goals and vision.

Help your gamedevs get where they want to go. To do that, they need to know where they want to go. It’s often true that people simply don’t have a vision for their own growth and careers. It’s your responsibility to help them create that. Then do what you can to help them make progress along their path.

Together you may discover that the very best place for them to be and to grow is not on your team. There’s nothing wrong with that. Assist them in moving on, make the best use of the time you have and make sure it’s worthwhile for everyone.

I expect you to hold each of your gamedevs accountable for their performance.

As much responsibility as you must take for the performance of your team, there is a bar they must meet themselves. Defining that bar is hard. It includes not just objectively measurable results and skills, but your subjective view on their growth, progress, potential and fit into the team. Give your gamedevs every opportunity to meet that bar, but if they have clearly established to your satisfaction that it simply isn’t going to happen, you need to figure out how to help them into another situation where they are more likely to succeed. That may very likely be off your team.

It doesn’t matter whose fault it is if things aren’t working. Accept that it’s probably yours. But for whatever reason it’s not working, once you’ve decided it’s not working, you need to make the change as quickly as possible.

Congratulations! If your team doesn’t trust you, it’s your fault.

As a lead, you have power over people’s lives and livelihood. Your choices affect not just the game, but your gamedevs, their families, their children and their future. Develop a healthy fear of wielding that power. The minute you do not fear abusing that power you stop becoming a good human leader of people and start turning into a monster ruling a tiny fiefdom by force. Your team must trust that you are ethical and honest. If your team can’t trust you, nothing you do will work.

I expect you to treat your gamedevs like adults.

Foremost, your gamedevs are human beings. They have lives and responsibilities. They have good days and hard days. They make decisions about lives, deaths, marriages, divorces, children, houses, cars, living arrangements, schools and any number of other major life decisions, both long and short term. They are certainly capable of making a good decision about what they need to be doing at any given time to contribute to our games. Assuming of course, they have a good lead to support them and good information to work with.

I expect you to ensure each of your gamedevs are treated with respect.

You will not commit or allow to be committed through inaction the disrespect of any gamedev on your team. You will in no way permit racism, sexism, homophobia or any other dehumanizing behavior from or toward any member of your team. If anyone has a problem with this, they can just Fuck. Right. Off.

I expect you to address the ethical concerns of any of your gamedevs.

Do not ignore ethical issues. These are often the most difficult issues to uncover since a many people are uncomfortable discussing them until it’s way too late. You are responsible for starting the conversation with your gamedevs and uncovering any issues that may lay under the surface.

Everyone has a different line they will draw in the sand. Some gamedevs are uncomfortable making violent games; Some gamedevs will not cross the line into gambling; Some gamedevs would happily make a game about eating babies or abortion, where others might find that problematic. No one will be at their best when asked to cross that line and we can’t always cater to the concerns of every gamedev on the team, so when it happens the best way we can support them may be to help them find another place better suited for them.

I expect you to protect the health of each of your gamedevs

You are not babysitting. You’re not your gamedevs’ parent. Whether or not they eat their veggies is their own business. But you must be vigilant against any abuse of power which, either directly or indirectly, asks your gamedevs to trade on their health for results.

Congratulations! If you don’t become a good lead, it’s my fault.

My job is to do everything in my power to help you succeed. All of those things I expect from you, you should in turn expect from me.

  • What do you think I need to be more aware of or paying more attention to?
  • Is there anything you’re doing that you’d like to bring attention to or for me to take more interest in?
  • Name one thing you might do differently in my position.

There is however, an exception. You may decide this job isn’t for you. You may find it’s simply not what you want to do. If that’s ever true, just bring it to me and we’ll work things out.

I expect you to have a 90-day plan.

You should expect me to review it. Offer suggestions. Help you focus in on the things that would be most helpful.

I expect you to focus on developing yourself as a lead.

You should expect me to do everything in my power to help you do that. If you don’t feel like you’re getting enough support, let me know right away!

I expect you to aggressively seek feedback.

You should expect regular feedback from me. You should expect me to help you get feedback from others.

  • Who do you believe is most critical of your work personally? What do you think is valuable about their point of view?
  • Who do you believe is most critical of our work as a team? What do you think is valuable about their point of view?

I expect you to ask for help.

You should expect me to give it.

I expect you to have some doubt.

There will be moments when you doubt yourself. There will be times where you feel this overwhelming feeling that you’re doing everything wrong. The best medicine for that is perspective. Self-doubt is part of the growth process. Knowing you don’t know is a whole lot better than not knowing you don’t know.

Congratulations! Good luck!

We’ll review where things are at in a couple of weeks in our regular one-on-one meeting. I’ll let you know where you’re meeting my expectations above and we’ll discuss those things that need the most work. And if it seems like you’re ready to dig a bit further, we’ll go over some these expectations and guidelines in more detail. If everything goes well, we’ll be discussing these issues and many more for a long time together.

Finally, if you need a mnemonic device to help you remember the points above, remember: Broken Weeds Grow to Trust Me. 😉

You have failed

Original Author: Angelo Pesce / C0de517e

This appears also on c0de517e.

Today i was watching SIEGE 2013 on leadership, and it prompted me to stop the article I was working on to start drafting this. I recommend watching his talk, it’s quite good and it talks about the key to leadership: responsibility.

Indeed, leading is about accepting responsibility, it’s different from management and its methodologies, and I don’t think really it applies only to the people who we identify as “leads”. It doesn’t come with a tag, really, leadership is a quality that is valuable regardless of your position and most of the good traits of leadership are the same, only the scope, or sphere of influence changes with your job. And that is exactly because leadership it is about responsibility, which is an universal value, even outside the workplace really.

It’s maybe even a pet peeve of mine, I hate when we (and we all do to a degree) think about circumstances or the faults of others, without first thinking about what we did or what we can do. Now, among all that responsibility entails there is something that people shy from talking, something very fundamental that we have to discuss, and the reason I’m writing this. Failure.

If you never failed, you didn’t try hard enough really, right? To a degree I think we all agree that failure is important, it is a metric of how much you push yourself out your comfort zone but it isn’t in any mean a positive thing, I won’t make some hippy case for the contrary. We all want to be successful, we want our programs to work, our games to sell, our research to innovate and so on.

Success is good, failure is bad… but on the other hand, we don’t just sweep under the rug our failures, right? Failures are problems, problems… well that’s something we can work on, it is information, it is learning, it is part of our job, it is part of being responsible.

I find it hard not to be defensive, we instinctively are I think, surely I can be and it requires applying quite some thought and attention to detect these instances in oneself. Even what I just wrote is an example of it, I changed into “I can be” my original “I am” because writing something negative about yourself seems to trigger some internal alarms.

Have you ever experienced a studio head coming in and saying words along the lines of “we didn’t do well” and “things didn’t work out as we expected” so we have to do some crunch and overtime maybe even throwing in a few hints at how that’s kind-of normal in our line of business anyways? Would you not have preferred someone saying I was wrong, I approved these decisions that didn’t pan out, now we have to ship and I think this is the best course of action, and of course if you want to talk about alternatives come and we will figure things out?

If that’s something that you agree and experienced, then be responsible, and apply the same lesson to yourself as well… Wouldn’t it be a better world if we knew for example all the interesting ways a given technique fails, not only the ways it succeeds? Why we can’t be open about failures? Honesty leads to facing issues in a positive way, it leads to trust, it is a remarkable value. Managing failure is part of leadership, educating about it is part of leadership, and certainly the more influence on the studio culture you have (or should have) the more you’re responsible for these aspects, but really it starts with everyone, leader or not. It’s a good skill to learn.

Let go of defensive instincts, they won’t make anything better.