UPDATE: I will be giving a live demo of Love and Tools on Friday the 27th at 4:00PM on the third floor of the West Hall of Moscone Center in San Francisco. Look for me by the tables as you get off the escalator. I dont think you will need a GDC badge to get in.
This is a longer version of my GDC talk 2009 that will be given on Tuesday 4:45 in room 131.
While the Love project is a lot about making a great game is also about finding a way to become so much more efective that you can make a game like this with a very small team. If i can make a graphically impressive game alone i would surely prove that my ideas can work. In the past hardware was so limited that we had to focus most of our energy to make it draw pixels and polygons, now however we can draw so much that the problem has shifted to being able to produce the polygons and pixels to draw. Moore law states that we can draw twice as much content every 1.5 years. So I'm suggesting a "Eskils law of game development" if you will, stating: if you cant double the amount of content per man hour you produce every 1.5 years the way you are working is unsustainable. Today's we have teams of up to 200 people, if we imagine that the next console generation will be 8 times as powerful, does that mean that we need teams of 1600 people? Even a doubling of the team size is quite unsustainable.
This is not a question of just money. This is about making good games. Good games comes from being able to iterate, make changes and having time to do so.
The tool that more then any has influenced my view of what a tools should be was seeing a Flame for the first time. Back in the 90s the Flame was a hugely expensive SGI compositing and finishing system that dominated the market. It would let a commercial director come in spend a few hours with a highly trained operator who, often while the director was watching could make a 30 second spot look great by adding titles, color correcting, tracking, stabilizing, compositing and retouching it. As a Flame was so expensive, if was designed to be effective to use for a trained operator rather then easy to learn, and it was not just about what you could do with it, it was about what you could do with it in a very short time. If you want a flying saucer in your shot, a Flame artist could in a few minutes mate a 2D image of a flying saucer, warp and light it, and then composit in to the shot. Could you make it rotate in 3D? No, it was flat. Could you model animate and shade it like in a 3D package? No, but it could be done in minutes not days.
In the past tool development has been focused on solving the hard problems, like cloth, hair, and fluids, but I think we need to focus on the simple things like making polygons and pixels, because that's what we spend most of our time doing. It is no longer about what we can do, its about what we can get done. When we design tools and our pipeline we need to be constantly conscious of the time it takes to complete each task. If you say that creating a character can take no longer then 2 days, an engine developer cant ask the artist to produce more detail or additional data like specular maps, without first automating or simplifying another aspect of character creation in order to give the artist time to preform the new tasks. The development of technology must be take even steps with the development of techniques to create the content that feeds it.
Internal development of tools should be a bigger effort then engine and game programming. Tools have a longer lifespan then engines, reduce art costs, and is therefor a way better investment then art assets or engines. My opinion is that you also need to release your tools outside your studio. It stops you from making quick and dirty hacks because "No one will see it anyway", it forces you to document, you can hire people who can use your tools, but most of all, if you make a tool that isn't specifically designed for your engine/team/problem you will make it more flexible, a flexibility that will eventually be paying you back by letting you discover new things you didn't think you wanted to do. Releasing the tools, especially if you do it commercially, gives weight to the tool development as an important part of what you do. If the tool development brings in money by itself it becomes harder to question its existence. Some people think that releasing your tools is to release your competitive advantage, but you will always have the advantage by having access to the developers of the tools and the latest version.
Industrial Light and Magic is constantly pushing the envelope of graphics technology and have probably some of the most talented people in the field, but during the making of Episode one they realized that they had an incredibly hard time making space fights. This was a bit surprising given that space is about the easiest thing to do in CG, but ILMs pipeline was designed to have so many steps to do complicated tasks like mussels, cloth and hair, that it became very unwieldy to use for something as simple ans a chunk of metal in space. This focus on the cutting edge has been a constant problem for ILM, because one year they may be the only place in the world that can make water on the scale needed for Pirates of the Caribbean, but a few years later polished, of the self, tools with nice interfaces can do that and more, while ILM is still using the comandline tools hardwired to do only what they needed for Pirates. Unless you constantly update your tools for a wider use then your own you wont be able too keep the edge you worked so hard to get.
Lets have a look at the stages of the pipeline and see what we can do.
Design is the first and the most expensive stage in game development. You have 199 people trying to cut down the ToDo list and one person trying to make it longer. My first advice to anyone who is trying to cut costs is to fire your designer. To have a person who cant produce art or code, be in charge of deciding what art and code you produce is madness. Design is not as many think about ideas, it is about choice, and unless you know what it takes to make things you shouldn't make decisions about it. A Designer who don't know production will ask for that flying saucer to rotate. To me its like hiring a personal shopper with the greatest fashion sense but no comprehension of the value of money. If you give them a budget and ask them to get you an outfit, don't be surprised if they blow it all on a pair of socks. People think the industry needs designers to generate ideas, but programmers and artists have all the ideas we need. Ask yourself this, what is the problem during crunch: is it that everyone is just sitting around with no idea what to do, or that you have so many ideas you have no chance of implementing them all? Right now the game industry is the opposite of a meritocracy where people without the ability to do things tell the people who do what to do. This needs to change.
Concept art stems from the idea that you need to quickly pre-visualize your game before you get to the expensive task of actually making it. Our goal should be to cut the cost of making the content so much that Concept art is no longer needed. What you want is to only take decisions about what your game should look like, and automate everything else. In away you can say that rather then removing the Concept art stage that is the only thing you should do. All tools should be built so that the only thing the artist need to input is design.
Modeling is so important that I have developed my own modeling tool Loq Airou. I use subdivision surfaces (Low poly modeling -> high poly output) with a reduction algorithm that lets me only add smoothness to a model where needed. The entire design of Loq Airou is based around the idea of making a sketch tool that is creative and that you can use as a concept design tool, with the only difference being that once the design is done, so is the model. One way that I use to make the most of the modeling i do is to make several different blend shapes of each model so that i can generate different versions of the object. Combine this with different materials, placement and textures and you can create a vast amount of content with very little work.
Uv mapping is perhaps the most tedious part of the pipeline, and it have no creative impact what so ever, and that is why i spent two weeks earlier this month writing a 100% automatic UV generator, specialized on low poly game assets. These two man weeks have completely removed me from ever having to do any manual UV mapping ever again. Start to see the usefulness of developing tools yet?
Texturing is perhaps the most time consuming part of game development, and that is why i simply decided not to make a texture mapped game. Yes, you can make decisions to simply remove something time consuming from your pipeline. Any one who says that a game has to have texturing is part of the problem. I want my game to pass the "flick test", where you can flick through a gaming magazine and instantly recognize a screen shot belonging to my game. Most games have detailed surfaces, but sharp edges, so my goal became to make flat surfaces but have organic edges. This was done by using edge polygons with alpha tested textures.
My next project will surely be to develop new texturing tools that combine procedurally generated textures with art direction. There are a vast number of Siggraph papers dealing with texture generation, fitting, and shape detection that has yet to be made in to tools that game developers can use. My feeling is that we should move towards a material based approach where textures are generated form rules. A tool that can generate a textures where rust has gathered in cavities, and simulate the running of rusty water, find edges where the paint has been chipped off, and emit particles that simulate dirt.
Animation is another great place to apply procedural content. Ask your self why you are hand animating or using expensive motion capture when any one who bought Spore can get the creatures, they spent a fraction of time creating, animated for free?
I like to divide the making of levels in to two different parts, one being the making of the basic layout of the level and the second one being populating it with detail, graphics and textures. The later part is the part where you can really make use of procedural algorithms. The best way of using procedural generation in my mind is not to try to generate everything but rather make the procedural algorithm assemble big complicated thing from small hand made peaces. This means that you have control over the big picture, and can art direct the details, while still not having to create big data sets.
The level layout can be either done by hand or generated. While generated data doesn't give you the same control, while working on Love I have discovered that generated levels can have some unexpected benefits. A generated level often feels more organic and less like something that has been prepared just for you. By generating data you can create the complexity that lets players improvise and discover the uses of the environment. While in a handmade game you may have a mission where you have to steal some keys to a building to use it as advantage point for a ambush, in a procedurally generated game every building can have an electrical system you can manipulate, every guard can have keys that give access to their locker, room or home, and every building can be entered and used as a vantage point. Chris Delay at introversion has been working on some very interesting stuff in this area.
The pipeline itself
I obviously use Verse as the back bone of my pipeline. Verse is a network protocol that gives all tools and the game engine itself real time access to all assets. If a change is made in a tool by one user all other users will see the change in real time in all tools including the game itself. It completely removes the need for files and everything is WYSIWYG. An awful lot of problems associated with asset management simply never occurs.
One very powerful feature of verse is that it has a universal data format that is not directed towards any particular engine or usage. If the artist creates a object with a material he/she can control its shape and its surface properties, then the export code that loads the data in to the game will convert the shapes to polygons and the properties to shader code. If you want more or less polygons you simply tweak the export code, you don't tell your artists to re do their work. If you have a new lighting model, you don't have to ask your artists to use it, you simply make the exporter include it when it generates the shaders.
In designing a workflow for game development a major goal has been to remove the need for much of the in-studio communication, especially between programmers and artists. Lets say you are making a game with a tank. You need a model for the tank and on for the turret. Normally a programmer would have to request the graphics from the artist, then agree on its naming, make sure it has the right orientation and size, then wait for the artist to make at least some mockup graphics before the programmer can start working. A better solution is to have a API that the programmer can use in the code to request an object called "tank", that is roughly a green 5 by 3 by 1.5 meter box. The APIi will then look for the geometry, and if it isn't found, it will create the stand-in box instead. This way the programmer can get to work immediately. Next time the artist looks in the verse server he/she will find the geometry, with naming, and rough proportions already there ready to be refined in to a proper tank model. The request in the API is turned in to a request in the asset management system. If the tank or any other asset would ever be lost or deleted the engine will always be provided with stand-in data so that it doesn't disrupt the work of others. This system is also used to store game play data. If a AI programmer needs a setting for a character, say how many health points they have, they simply request a tag value, set a default value, and then the tag will appear in the interface of to tools.
Tags are also used to keep track of the progress of development. In my asset management tool Co On you can configure the 3D display to color code, draw text or icons on different objects depending on their tags. You may make objects that are critical red, or you may make objects assigned to you as blue. This system can also be configured depending on you task, a modeler may see a completed model as green, while a texture artist sees it as red indicating that it needs texturing. There is no paper work, no internal web forms, everything is right there in the 3D view of the tool.
The engine it self can also be geared towards productivity. Imagine a normal grid height field engine, now let each block store all 4 corner values independently, so that you can make cliffs. Then with a Boolean ad the ability to make a cave, by adding 4 floor values and 4 ceiling values. Finally you add a integer value to the top and floor surface that indicates the type of surface, depending on the type of surface you can replace the quad with a hand modeled object that has a square bottom, like a tree. This is the basic geometry in Love. It is so simple that i can generate landscapes, buildings, even cities, I can let players modify the environment and I can even make it destructible. Yes it is not as flexible as a polygon soup but i can do so much more, and with polygon replacement I can dress it up with hand modeled geometry.
I have here presented a number of ways to improve the productivity of game development, but the most important one is to keep innovating in the area of production. Depending on what kind of game you are making and the people you have you need to find your own best practices, the only thing you cant do is assume that working the way you used to will always be sustainable.