Welcome to A Premortem: Lessons Learned So Far. For those of you who are just joining us, this is part 2 of a series I began writing last week where I discuss some of the lessons we think we’ve learned during the development of Hegemony, and how we’ll probably do certain things differently on the next project. Since we haven’t actually released Hegemony yet, I can’t say with utmost authority that these are all good ideas, but they seem like good ideas with the current – albeit partial – hindsight that we have today.
This week I’ll be talking mostly about the art side of things; not just how our artists will change things up, but also how our next game could benefit from better programming and planning. That brings me to the first lesson.Plan the Art
This may shock anybody familiar with the way large studios work, but we never went through a concept art phase. Philippe had played around with some different looks near the start of the project, but it seemed unnecessary to do much more than that.
And you know what? At the time it was unnecessary. Back then, Philippe was the sole artist on the project, and any “concept art” we had was all in his head. That was perfectly fine when at the time, but to date we’ve had three different artists contribute to the project, and it would have been nice to have some concept art to refer to.
I’m not saying that the concept art would be set in stone. As an independent studio, we have the freedom to make changes to our concepts further down the line if we think it will make a better game, but it would have been nice to have a guide to work from, not just when trying to keep a consistent look between different artists, but to keep a consistent look with the earlier parts of the project.
Reusing Assets
This is an idea we’re still sorting out. We already reuse some assets – for instance, it often makes sense to reuse the same texture in multiple places – but there’s some other things we can reuse.
The prime candidate at this point is animations. Most units in Hegemony have their own unique skeletons. We initially did this to help make the different animations more unique, but there were still some animations that we wanted to look similar to each other. For instance, when a unit in Hegemony surrenders, they drop to their knees. This is a simple action, so matter how much time you spend on this animation, they’re going to look nearly identical. In many ways, we want them to look nearly identical. And if they look identical, you may as well copy/paste instead of creating them both from scratch. This takes planning, because you need to make sure all of your characters use a compatible skeleton, but in the end it frees you up to spend more time on other parts of the game.
The trick here is deciding which parts of the game you’re willing to copy/paste; we don’t want to make a game where it looks like everything has been cloned instead of creating unique content. For instance, Philippe put a lot of effort into making the walk cycles for each unit distinctive, and the game would have lost something otherwise. Still, if you needed to animate the hoplite’s walk cycle, it would be much more efficient to start with a copy of the peltast’s walk cycle and modify it as necessary than to start from scratch each time; that way the game ends up with lots of subtle differences, but the artists have saved themselves some time that they can spend on something else, and the more time-saving techniques you can find, the more detail you can add to the game as a whole.
Better Tools
Ask any artist in the game industry what would make their job easier, and ‘better tools’ will always be near the top of the list. The tools that artists and designers work with in the game industry are often pretty poor, because it’s usually more efficient to tell an artist how to work around a bug than to spend time fixing it; there’s always a trade off between how much time it will take a programmer to implement a feature and how much time it will save the artists. In this regard, we’re no exception.
Simply exporting a model for use currently involves opening the model in Lightwave, clicking through a few dialogs, editing a text file, and finally compiling these files into a form that the game prefers. If you want to see the way the model looks inside the game, you need to shut down and restart the game each time you make a change.
There’s some obvious changes we could make to streamline this process. We could add a feature to the game to reload a model without restarting or compiling any files, and that would certainly help a lot. To reduce the number of dialogs that our artists have to click through and eliminate the need for editing any text files, all we need to do is store a settings file for each model in the game. These features would have been trivial to implement if we had planned for them from the beginning, but we simply didn’t think of at the time. These are the sort of things where you have no choice but to shrug your shoulders and respond “Live and learn.”
Another source of wasted time for our artists has been re-exporting their assets. Every now and then, it’s been necessary to modify the file format that we use to store our art, and that means that our artists have to repeat the above process for every model and every animation in the whole game. The solution to this problem is to write a tool that can automatically export multiple models or animations in one big batch. This is a tougher problem to solve, because our exporters have been written as plug-ins for Lightwave, and we’re at the mercy of what Lightwave allows us to do. Still, I’m confident that we can find a solution, and it will definitely be worth spending some time on this problem when we write new tools. We’re also strongly considering changing from Lightwave to 3D Studio Max for our next project, which is more powerful and easier to use when it comes to writing plug-ins.
Focus on Art, Not Technology
When the decision was made to make Hegemony as a 3D game, most of the art was in the form of low-poly models. This was largely due to Philippe’s experience on Tread Marks, back when 3D hardware was still pretty primitive. Back then, the most-detailed model in a game still had less polygons than the least-detailed model in many games released today. Because of that, there were lots of tricks an artist was expected to know to hide the low polygon counts, and it was very difficult to simply take a high-poly model (say, something that was suitable for a pre-rendered cutscene) and reduce its detail to the level needed without simply starting from scratch. Nowadays, the bar for polygon counts is high enough that starting from scratch is no longer necessary.
So we had this large collection of low-poly models, and at some point in development we decided that we wanted to be able to zoom in closer. That, in itself, was very simple to implement, but with modern video cards we’ve come to expect a lot more detail, and when you zoomed in our low-poly models looked unimpressive, to say the least.
So Philippe started from scratch to create new high-polygon models for every character in the game. This obviously wasn’t the most economical method of art production. For the next project, we’ll try to start out with models that are higher detail than anything we can foresee needing, because we can always reduce detail if we need to, but it’s a lot more work to add detail later down the road.
Ultimately, it would be nice if we could just tell our artists not to worry about the technical limits of the game and focus on making their art look the way they want it to look. Currently, we’re not able to say that without adding some footnotes (e.g. “Don’t worry about the technical limits. Oh, but make sure you use no more than 12 bones in your animations. Oh, and be sure not to re-use the same parts of a UV map. Oh, and…”). It will be a long time before we can remove all of these exceptions, but I think we can safely add polygon count to the list of things artists don’t need to worry about anymore. Of course, they still need to prepare multiple LODs, but that comes at the end of the process, not the start.
Focus on Technology, Not Art
While all of this was happening in the art department, we in the programming department found ourselves spending too much time on visual effects, like rendering pretty water and making the grass fold under the feet of our brigades (a feature which we spent a lot of time on and which, ultimately, we decided to cut from the final version of the game).
This is something which largely falls under the “Vertical Slice” lesson I talked about last week, but we fell in this trap often enough that it’s worth going into deeper detail about how this trap works:
First, you start writing your game engine. While you’re working on the core parts of the engine – stuff which is really important to get the gameplay working, but which can be boring to work on sometimes – you take a break and implement a neat graphical effect. It’s only a short distraction, and you quickly get back to working on the important stuff.
Next, you show the game to somebody. There’s not much gameplay to show yet, but somebody notices your neat graphical effect. You get compliments about it, and you feel good about yourself. Sometimes it might even come from somebody important, somebody who might be able to offer funding for your project if you manage to impress them.
Now you find yourself trying to impress as many people as possible, and the quickest way to do that is to spend more time focusing on graphics, while you leave the core of your game to languish.
This is particularly dangerous, because when you get back to working on the core, you might be forced to rewrite those graphics effects from scratch, or you may want to rewrite them to take advantage of the latest graphics hardware. Either way, you have to throw away some code, any any time you do that, it means you’ve wasted precious time.
Be mindful of this trap, because it’s insidious.
Same Longbow Time, Same Longbow Channel
That’s it for part 2. My list of lessons has been pared down, but I still have more than enough for another full post, so come back next week for the third and final instalment.