I’m almost done with DigiPen. Time to write down some learned lessons. I was only at DigiPen for two years, so others could probably write this better, but until they do there is this post. In both years I was in the most successful game team of the Master’s program, which is my claim to being qualified to write this post. So here are a couple rules, starting with

1. Gameplay first

This is the first point on Blizzard’s mission statement, and they mean “prioritize gameplay.” Do that. But for student games I consider it even more important to interpret that as “work on gameplay first.” The biggest mistake I have seen on student games is wasting time on features that don’t improve gameplay in the end. You do not have time for a student game.

Now how do you finish gameplay first?  Obviously you need tech to do your gameplay. If you want to make a physics-based puzzle platformer, someone has to implement your physics. But I would consider it a mistake to work on the physics until you know that it will result in good gameplay. Which is a problem.

This happened: A game team was building lots of systems for their planned RTS, without ever having something playable. After the first semester was over they learned that they had over-scoped and couldn’t actually build an RTS. They decided to make a starfox game instead. They lost most of several months of work.

The way I suggest you solve this is through iterative prototyping. For every feature, AI, graphics, physics or any other category, build the simplest thing possible first. Build the simplest thing that could possibly allow you to evaluate whether that feature has a positive impact on gameplay. If you can’t think of a “simplest thing possible,” and the feature needs time to be worked on, be really careful about the feature. Consider dropping it.

Test the simplest thing, and if it doesn’t have a positive impact, drop it. Very often you will find out that you can’t actually know whether it has a positive impact on gameplay or not. For example if you are working on AI, but you can’t build real levels yet. In that case work on other things first. Do not continue working on a feature until you can evaluate it.

This happened: A game team had precisely the situation with the AI and the levels. After spending months on the AI before getting it in the game, the team figured out that enemies weren’t all that beneficial. They made a puzzle game instead.

If the simplest thing has a positive impact, work on the feature for real. Re-evaluate once you have an approximation of what it will look like in the final game. Did the glimpse of a positive impact actually come through? Are there complications with other features? Be honest with yourself in this, and drop the feature if it isn’t good. Drop features early before you waste time on them. The worst thing is if you never cut it and a bad feature stays in the game because you were too invested in it.

What if there’s a feature that you absolutely want to work on because you consider it really cool, but it may not have a positive impact on game design? If the feature is more important to you, change the game design. Make it so that the feature becomes important. Do not continue working on the feature until you make it important for the game design.

2. Make sure that everyone can always work on the game

Plan your project well enough so that nobody will ever be blocked by anyone else. I don’t consider planning very important otherwise. But never plan so poorly that someone is blocked. For some reasons programmers tend to be really good about not blocking other programmers, but I have seen terrible cases of programmers blocking designers and artists.

Make sure that your artists can get their assets into your game. Spend the time to make it easy for them. Don’t slow them down by making them understand the internals of your engine and edit config files just to get a model in the game.

This happened: Several game teams at DigiPen have failed their artists because they couldn’t get the art into the game. The artists had lots of assets, but those are worth nothing if you can’t get them in the game quickly and iterate with them.

Always have a playable, bug-free game. Otherwise you can’t build gameplay. If you aren’t careful with iterative prototyping, there is a real danger that you end up with half-finished, buggy features. Especially since you’re all still students and not experienced programmers. If you find that a feature is valuable, make it bug-free. Spend the time on it. Do not delay fixing those bugs. Otherwise you’ll be slowing people down.

If anyone can not work on the game because he is waiting for a feature, cut that feature. It is better to concentrate on your core than to block people by being too ambitious. If you can not cut that feature, consider how you can unblock that person in the quickest possible way. Change the feature, make it less technically demanding or work on a simpler version first that will get you 80% of the way. If none of that is possible and you need the feature fully in order to unblock someone, prioritize that feature. Work on nothing else. And work on it in such a way that you can unblock that person in the quickest way possible. There always is a way to unblock someone more quickly if you think about the problem from that angle.

Another solution is to say that if someone is blocked, make her work on something else for now. I consider that a terrible solution. You’re hiding your problems and you’re working on less important things. Also, if that person is blocked on a more important feature, chances are that you can not evaluate the less important feature for it’s gameplay impact as well as you could if the more important feature was finished.

This happened: A designer was waiting for months for his game team to provide him with the tech to build bigger levels. They had enough tech for the designer to build a playground-sized level. The designer had to guess the impact of features because he couldn’t build real levels. At the end they had the barest minimum of a game but lots of little-used features.

3.  Be experimental

You won’t finish your game. It just won’t happen. To properly finish making a game, even a small game, you need years. The best example of this would be Braid, which had a prototype up in a tiny amount of time that looked remarkably like the finished game, but the final game took three years after the prototype. So if you make a game that has been made before, you will only ever make a worse version of it.

This happened: We made a worse version of Mirror’s Edge. We thought we had the focus and the time to improve on it. We didn’t.

The only way to create something really good as a student game project is to make something experimental. And if you make something experimental, I would refer you back to point 1: finish your gameplay first, because you will need to change directions and you will want to come to that point within the first couple weeks.

4. Finish stuff

In the end a student game is about getting you a job. Once you’re done with college you need to apply at game development companies. And the only thing that will get you past the first round of the hiring process is if you have something finished.

What do I mean when I say “finish?” For any given feature, I consider it finished if it is in the game and it is beneficial to the game. Let’s say you want nice soft shadows and implement exponential shadow maps in one of your classes, and they look really cool. What you have is a tech demo. To actually finish it you have to get it in the game. You will suddenly run into tons of complications that you didn’t think about. And if you get it in the game, but it doesn’t make a difference to the game, then it is still only a tech demo and not a finished feature. Any programmer can make a cool tech demo. Not many can actually finish a feature.

This happened: One programmer didn’t want to show off his two-semester game to employers, because it only had lots of half-finished features. He showed his one-semester game instead because despite it having much simpler features, they were more finished. (having to build a game in one semester allows you to focus much better)

5. Watch this talk

by Jonathan Blow about how to make independent games. It is a must-watch.

This happened: A game team used a task-based engine that would allow them to write easily threadable code. They had a barely finished game at the end that didn’t take advantage of the fancy tech.

6. Optimize the time spent on tech.

Never start from scratch. Always re-use the tech from the last project that you worked on. Change bad parts, but always have something running. You’d be surprised how quickly you can turn a 2D engine into a 3D engine. More quickly than if you start from scratch. You have forgotten how much work writing an engine is initially. And you have forgotten all the small bugs that you had to fix along the way, that will pop up again if you start over. Refactor constantly. If a piece of code annoys you for the second time, change it. Be aware of whether a piece of code annoys someone else who may be afraid to change it.

This happened: In our project we once had a case where one programmer was using low-quality code that I had written. I would have cleaned that code up before working with it more, but the other programmer didn’t know my code well enough. When I finally did refactor that code it was a mess because I also had to change all his code.

Artists

I also have a couple points for artists. I’m a programmer, so there may be more important lessons that I’m not aware of.

1. Don’t be too dependent on the programmers

If you can not easily get a piece of art into the game yourself, bug the programmers to make it easier for you. If they won’t make it easier for you, consider switching teams.

This happened: In both of my years at DigiPen, there was a game team where the programmers failed the artists completely, and the artists had very little to show at the end of the year.

Part of the problem was, that the artists stuck to that team until the end, because the team promised to deliver later. If the programmer doesn’t get the art into the game, she may still pass her class. You however will fail your class.

2. Lighting is very important

You need to work with the graphics programmer on your team to get the lighting to look good. The only thing that can make a student game look not like a student game is good lighting. Tell your graphics programmer to work on HDR and other techniques that improve lighting.

This happened: The game team with the most artists at DigiPen this year had no programmers who’d get really excited about graphics. (They made the game in Unity, not their own engine) Despite having the best art, their game looks kinda flat. I blame bad lighting.

3. You’re also a designer

Watch this GDC talk about the art of Diablo 3. A good artist will not just provide art. To be a good artist you will consider which game design role that piece of art has to fulfill. You will know what the tech can do to make your art look better than you thought it could, and you need to know where the tech will make your art look worse than you hoped. And you need to know the limits of what the tech can do. The thing to take away from that talk is that in every single piece of art in Diablo 3 there were many considerations beyond “does it look good?”

This happened: The game team with the second most artists built a spaceship that looked absolutely brilliant. Then they set a multiplayer game in that environment. It was impossible to find other players because the space wasn’t designed well.

4. You don’t know what the limits of the tech are,

and neither do the programmers at first.

This happened: I have seen many student games with very low poly models.

Either the artists or the programmers thought that student games probably have similar limitations as old console games. Except that student games usually don’t have a ton of stuff going on, and today’s hardware is insanely powerful. So you can probably have models with ten times as many triangles as you thought you could. Or maybe you can’t, it depends. You will almost certainly break the limits of the engine in some unexpected way. There is really no way to be protected against this, otherwise it wouldn’t be unexpected. The only piece of advice I have is: Talk to your programmers a lot, and help them figure out the limits. Do not think that your game has to look like a PS2 game because you’re making a student game. The tech limits on a student game are very different than they were on twelve year old hardware.