In Game Development
How often do you hear the phrase "We have to do it immediately in final quality, because then we won't have time to go back to that content". T
Management
There is some truth in this, but let's look at the other point of view. You may not agree with it, but reading this text will broaden your horizons, which is never a waste.
Let's start with the simplest iteration - the structural one. You make a plan, you do it, you get the final product.
Common sense tells us that it is not that simple. At the very least, for the final result to be of any interest to anyone, there needs to be a quality guarantee. Which means that before we give the product to the public it must be playtested, the results of the playtest must be processed, changes must be tested and so on. Let's call this iteration quality.
It would seem that this is the ideal way to create good quality games. But there is just one catch with them: when developing in this way the project's release date will be "when it's done". It's good to do this when you're immortal and have an endless supply of money. But in the real world, you need to be able to achieve quality within a given time frame. Which means you have to build a process that optimises iterations to get the best possible quality by the given deadline.
An example of the result of such a process is Skyrim. Anyone who has played this game knows how much content it has - a huge open world, five large cities, over 300 dungeons, over 140 points of interest, 37 settlements. At the same time, only seven level designers worked on the game. Producers reading this should be drooling at this point.
Of course, not everyone can just work with such efficiency. Joel points out three differences from other studios that helped achieve such results:
By then Bethesda was an established studio, with established teams, pipeline for code and art, and numerous toolkits.
Minimal turnover allowed for the team's capabilities to be calculated at the beginning of the project. We had as many designers at the beginning as there would be at the end. No "we will hire 100 more people and they will do everything for us" plans.
High quality of life. No crunches. Obviously, this is a moot point. How is it gamedev and no crunches? But Joel is convinced that realistic planning ahead can keep you from suddenly working in overtime.
Usually, when we want to make a level, we break down the creation process into stages. First we write the design, then we sketch out a rough draft, then we get it to a decent state and then we clean up the bugs. We build a level by going from one stage to the next. Call this approach sequential iterations.
And if the game should have multiple levels, we do each level in sequence as well. This month we focus on developing level A, then next month on level B, and then on level C.
Except Bethesda has a different approach.
The focus of development can go not on levels, but on their stages. First the first stage is done for all levels and until it's completed, no level will go into the second stage.
The special magic of this approach is that some time passes between subsequent phases of one level while the designer works on phases of other levels. During this time, the designer learns a lot about his level and has much more useful information at the beginning of the next phase than if he had started the phase immediately after the previous one.
During the time between phases, the designer has time to gain experience working on other levels, gather feedback from playtests, and get a report from the QA team. If there were no pauses, the feedback from the previous phase would come in the middle of working on the current phase and confuse the plans.
Also, these pauses allow the designer to take a break from the level and return to it with fresh eyes.
Also, this approach allows you to cope with the growth of the project. And this is a very important point. After all, there is always an element of chaos in development, when it turns out that something needs to be done that was not originally planned. The more daring the game you make, the more surprises you will have. Which means that there will be times when it will be discovered that the level designer needs something from the programmers or artists to keep working on a level. Creating code and art also takes time. And it's a good thing that with this approach to iteration, the designer already has time planned for the wait.
That would be the end of it. This information is enough to increase productivity, raise quality and still stay within the time and money plan. It is like with the example of having to write the line "1 A I 2 B II 3 C III 4 D IV 5 D V 6 E VI 7 Ye VII 8 G VIII 9 Z IX" sequentially, symbol by symbol, and in turn, first all the Arabic numerals, then all the letters, then all the Roman numbers. You can see from his example that it is better to finish all tasks of one type first, before switching to another type of task.
We have talked about planning the development of levels. But is this the only responsibility of the level designer? For example, at Bethesda the level designer also writes books, dialogs, contributes to system designs such as crafting, combat or balance, prototypes features in an internal scripting language, works with programmers on internal tools, and does various other tasks that come up as the project progresses.
Secondly, it allows the level-designer to remain productive throughout the development. After all, at the beginning of a project, a level-designer doesn't have much to work with. There is no code, no art. So he can handle other tasks. And towards the end of the project most of the systems are ready, but there's an incredible amount of work for the level designer.
If we were talking about a team of highly specialized professionals, we would have to hire level designers during the development of the project, because there would be nothing for them to do at the beginning of development. Conversely, other specialists would have had to be downsized.
Bethesda calls this approach "Opportunity Time". When at any given moment, the designer has a number of opportunities to improve the game. The question is what he chooses to do in order to make the most of that time. To do this, we need to understand what time is now on the project. To do this, think of development as a set of stages. Sort of like the example of breaking down level development into components, only on a project-wide scale.
Stage zero - concept
This is the planning stage. There's no game yet. No code or art to work with. But you can work on a list. A list of all locations and events. It's like a slot machine with the architectural setting on one reel, gameplay type on another, location on the global map on the third, and so on. You pull the knob and you get a new item for the list of locations.
So the level-designer gets a short assignment to make a location Windy Peak: size is large, uses a set of Nordic ruins and is populated by draughtsmen. This is usually all the information the leveldesigner has. Only occasionally, when a location is made for a quest, additional details will appear.
The first step for the level-designer is to describe on the wiki (or where you keep your documentation) what he would like to do in the location. Keep it short and succinct, in one or three paragraphs. Brevity is required on purpose, so as not to blur the focus and focus on the things that will make the location stand out from the rest.
The focus is also on the story at this stage. It is not necessarily the story that will be presented to the player through dialogue and text. It is the story of the location that the level-designer needs, primarily for internal development needs. It answers the questions: what is this structure, why was it built and by whom? What happened here in the past? What happened just before the player arrived? Even if this information is not given directly to the player, it is needed to maintain consistency and to understand what assets will be needed to tell this story through the environment (environmental storytelling).
Speaking of the list of assets. For one thing, don't go to extremes and write down every wall or floor variation. And instead focus only on the objects that make up the uniqueness of a given location.
On the other hand, the list of assets should not be too abstract. For example, if you have an idea for a puzzle in which the player needs to ring a few bells, you shouldn't write "puzzle with bells" briefly in the asset list. After all, several kinds of bells will be needed, they need to be animated and voiced - all this needs to be spelled out in advance to understand the amount of work and which experts will be required.
It is worth mentioning not only what should be done at this stage, but also what should not be done. How can you call effective the work that will have to be redone from scratch? For example, if you have a minimum of objects, you start putting them in place, filling in the level, then when new objects appear, you will have to remove at least some of the work you have done.
So, at stage zero, the designer does not run the editor. Even if there are few assets to work with. Because that would be wasted time.
Also at this stage, a general map of the location is created, without detail. The focus is on what entities will be on the map and how they relate to each other.
Also at this stage it is not necessary to get carried away with the bloatware. Like for example a twelve page document describing half an hour of gameplay. Part of which consists of little backstories, like the story of the feud between the brothers who produce the fuel used by the hovercraft, which only appears for a second in a certain scene of enemies appearing. That sort of thing is good for flavor, but not at this stage. If you can't keep your documentation to a minimum, then you don't understand the stage. The fact that you like to spell out such details is your own business, not the team's or the player's.
The zero stage is repeated over and over again until all the intended content is covered. This takes a few weeks. Meanwhile, the rest of the team is also busy, which means that by the time the level designers have finished their work, the state of the project will already be different.
The first stage is the layout
At Bethesda, the term Kit (kit, constructor) is a set of elements from one setting that are used to assemble a location in a given setting.
At the zero stage environmental artists, working closely with level designers, create blanks for the kit. First of all, they are required to observe dimensions and pivot points, so that where the level-designer put the object, it will remain there when it turns from a blank in the final model.
At the first stage, the task of level-designers is to assemble all the locations from those designers that are available. At this stage levels will look boring, empty, without lighting and details. But there will already be an understanding of rhythm and flow that sets the space. And beauty comes later, at later stages.
And that's the test of the designer in action. Artists get their first feedback, both technically and in terms of whether the elements are sufficient. It's better to spend time now on adding new elements than suffer later on trying to fit a new element into an already assembled location. Of course, waiting for new constructor elements slows down the level-designer, giving him time for other activities.
This is the stage level-designers at Bethesda use to write books that the user can find in the game. Since this activity is optional, only for those players who want to dig into the history of the game world, it will be impossible to do at a later stage, when the deadline is very high.
Also at this stage, the entities that normally do not change during development are put in order. For example, names, map locations, marker placement, location settings.
During this stage there are also a number of things that level-designers do not consciously do. For example, optimization. Yes, the engine is demanding for leveldesigners, who have to arrange different optimization things on their levels. But this should not be done before level-designer will get feedback during this phase that the location is integrated and will not require more changes.
For the same reason that a location may be rebuilt several times based on feedback at this stage, the Navigation Mesh needed for AI to navigate the level is not created. As a consequence, there are no enemies or other NPCs in the levels. Unless there may be a few single pieces for debugging. But that's the game designers and programmers' kitchen, the leveldesigner now does not need to put things on the level that do not work, and therefore can not be tested by the playtest.
For the same reasons, level-designers don't do the lighting and arranging of small objects. Instead, level-designers deal with art-hacks, using existing assemblies to create the illusion of new assemblies that are not in the constructor. For example, when a bridge is needed, the designer takes a wall and rotates it. Or, for example, makes a table out of a cupboard.
This approach allows for more variety with a limited number of assets. And, as you can see from the screenshot, many of these solutions survive to release. Of course, you shouldn't get carried away with such hacks at this stage, because this stage isn't about beauty, it's about testing the designers. So if a designer has decided he needs a table and has tested this idea with a cabinet, he shouldn't leave things as they are. At this point, he should go to the artists and let them know that he needs a table, and he is firmly convinced of this because he has tested the idea in the game.
The second stage is gameplay
The work at this stage is something like Vertical Slice. In the sense that by the end of it, the game will look relatively complete. At this stage, work on cor mechanics is accelerated, as there is an opportunity to test them in different locations, encounters and weapon types. As during VS, the knowledge and experience gained from working on some levels helps later on in other levels.
The main focus of this stage is battles with enemies (encounters). Primarily to get a feel for the pace of the game. How many opponents do you need, what type, in what quantities, how often? It's also a good time to think about loot (loot, the term for trophies found by player characters on the bodies of slain monsters - ed.). Where the player will find health-restoring potions, where they will discover a secret path to treasure, and where they will stumble upon a chest guarded by a boss.
The designers are also working on scripted scenes at this stage. From dialogue that the player can overhear, to enemies running out into the corridor as the player approaches.
In order to work with the encounters, a navmesh must be created. It will need to be maintained throughout the subsequent stages, so it's best to make it good enough now to save time maintaining it later.
As said before, there is enough time between subsequent stages of one level to gather feedback. Having received feedback from the first stage, the level designer processes it in the second stage. This means making edits to the layout of the basic elements of the level. So it's important not to mess up the sequence of actions, creating navmesh where everything will be redone later.
Speaking of gameplay, you need to understand that it's not just about poking people with the pointy end of a weapon. If you have a plan for non-combat action, like puzzles or dialogues, then it's time to do them at least on a dummy level to test your idea in gameplay and find out its effect on the pace of the game.
Oddly enough, at this stage level designers are engaged in optimization. It would seem, why? After all, the rooms on the levels are still empty and the optimization problems are unnoticeable. And if you can see them, it's because the code is at the early stages. So what's the point in wasting time on optimization work? And the point is that once the designer has finished changing the arrangement of large elements on his level, then he can get on with optimizing their visibility.
The optimization work is pretty tedious, but it has to be done one way or another. So it's better to do it early on, to free up time in the later stages for tasks that make the game better, rather than just cramming it under the required FPS.
There are a few things to avoid at this stage. Firstly, you need to suppress the urge to delete a level and redo it from scratch. Sure, enough time has passed and new assets have appeared, and your head is full of new ideas that seem easier to make from scratch than to try to insert into an existing level. But this is just a conditioned reflex, the result of which will simply be another level that won't necessarily be better than the previous one. It will simply be different. And so this kind of redesign is just a waste of time, a useless job.
Also, the work of careful scripting is avoided at this stage. As written above, a rough quality will suffice for gameplay testing. But if you take the time and carefully script everything, chances are that after playtesting you'll get feedback on the irrelevance of the puzzle and the need to throw out all the work you've done.
The level designer will get a lot of feedback at this stage. Artists at his locations will be reviewing their designs. Game designers and programmers will test their features by running through his levels. There may be level demonstrations on a projector, with a whole group of individuals giving verbal commentary. It will also be mandatory for the level to be reviewed by the lead level designer and artist.
The key to dealing with feedback is not to react to it. At least don't do it immediately. After all, it's so easy to get distracted by a good suggestion, which is really just another "how to do it differently" rather than "how to do it better". So all feedback should be recorded, catalogued, but only responded to after enough time to accumulate comments, prioritise and determine how to handle which points.
Stage three - all content is ready
At this stage, the task of the level-designer is to ensure that there is nothing missing, temporary, broken and unaccounted for at his level. Of course, the level-designer can't be responsible for producing the art, and therefore it's not up to him to draw a texture or update a model. His job is to keep a record of whatever is missing for his level. And if it turns out that there's some content missing from the artists' schedule, start addressing the issue as early as possible.
Of course, the schedule isn't rubber-stamped, so you'll have to cut something off or find an alternative solution. The longer such solutions are delayed, the more they will come out sideways.
By this point, the level-designer has gameplay compiled in outline and feedback received after the second stage. It's a good time to process the feedback and bring the gameplay to a finished look. Also in stage three, the system designs have been gameplay-tested. Now it's not a bunch of floating ideas, but quite concrete mechanics. Which means that along with them comes an understanding of how best to use them in your levels. It's better to integrate them into your levels now than to try to insert them at later stages.
Each level in the third stage has its own particularity. Somewhere the level designer needs to devote more time to scripting than to everything else. Somewhere the focus will be on combat. And somewhere it's the environment. This is where the level-designer needs to understand what is most important at his level in order to prioritise his time.
img
Strangely enough, no time is spent on optimisation at this stage. This seems strange, as it was given so much attention in the previous stage. The thing is that at the third stage the optimization work will be preventive in nature and will not yield much results.
Here we should confess that actually in Bethesda the third stage is not called Content Complete, but Ship With Shame. Because if anything, at the end of this stage the game can be unloaded into shops. The content is there, the features are there, which means everything is technically in place.
Of course, finished content doesn't mean a high quality game. Stage three isn't mainly about quality, it's about confidence. Confidence that all levels will be ready as planned. And, more importantly, the certainty that you can improve the level of quality in the time that passes between the end of stage three and the actual release. As opposed to sequential development, where some of the levels won't even exist as a design on paper by that point.
Stage three is still a springboard into "opportunity time". It's a good time to see what can be fixed in the game. If some mechanics aren't working well enough, we need to think about how to give them a second chance. Bethesda doesn't like to throw away work, so they plan ahead for so-called mulligan passes - opportunities to redo the necessary element again.
No one likes to have their levels cut out of the game. But sometimes you have to take such measures. Because if you have to choose between spending effort on bringing a good level up to a great level or pulling a bad level down to average, then of course the first option is the choice. Having excellent levels is more useful in the long run than having average levels.
Another tool available is Strike Teams. This kind of practice is used by many studios. This is when a team of multidisciplinary specialists focuses on solving a particular problem. For example, the "Strike Team" takes a feature that has been neglected and brings it to a state where it can be used and tested. Or to "polish" content that is in a prominent place. Also, a 'strike team' can gather around a designer to help him or her tackle a complex or ambitious task.
Of course, the easiest way to solve problems is to add working hours, the crunch. But as stated before, Bethesda doesn't like crunches and considers them a last resort. Imagine your content wants to be cut. You go to your lead and say you can solve the problem by working overtime. But how will the lead believe you if you already work six days a week and stay late in the evenings? What extra hours?
Besides, even if you allow such overtime, there is a great risk of mental disruption, reduced productivity, poor decision-making and more bugs being produced. So the benefit of such crunches is questionable.
Of course, if you work a reasonable number of hours, a short crunch can be a tool for patching up holes. But it's a very blunt tool, applying it won't impress anyone.
Bonus stage - the beauty stage
Once the third stage is over, comes the bonus stage of putting things in order and beauty. The team of artists goes from creating new content to improving the existing content. Optimisation comes to the fore. Designers and artists must do everything necessary on their part. So that if a level shows a performance slump, the programmers know it's something in the code, not because new content was poured into the level last night.
At this point, artists work on the level, adding small environment objects, effects, and adjusting lighting. And the sound engineer does his own walkthrough of the level. The level designer keeps his hands off his level at this stage. The artists will do the design work faster and better, freeing up the level-designer for other tasks.
The main task of the level-designer is not to keep his hands too far away. It is necessary to be in contact with artists and help them if there are difficulties. This includes not treating artists as cleaners, who clean up after the level-designer the mess he left them.
While the beauty phase is going on, the level-designers are preparing for the next phase.
The final stage
The final stage comes when the game is in full swing towards release. It's a chance to make sure the game is released with as much quality content as the team is capable of making. So the goal of this stage is pretty obvious - to "water down" everything.
This phase is about focusing on all the good stuff in the level and removing or correcting all the bad stuff. A chance to pay more attention to the later part of the game. And if there's an interesting combination of enemies and weapons you haven't seen yet, it's time to put it into the level you're about to "polish".
Feedback from the team will come in waves throughout the stage. Each time letting the level designer know how the players see his level, what stands out and where to focus his efforts.
This stage requires tidying up the whole internal kitchen that the player can't see, but which is important to the game. This includes optimisation, final tweaks to the navmesh, the right settings in the location properties, and everything else that's required to be fully functional at the level.
Another small confession. This stage isn't called stage four because stage four isn't necessarily the final stage. There are playtests at this stage to decide whether to leave the level for further refinement or whether it has passed the stage. Thus, some levels remain unchanged until release immediately after the fourth stage, and some levels go to the fifth, sixth, seventh stages, and so on. Sometimes because the content does not meet expectations, but more often because the potential for improvement is seen.
Thus, the first stages of concept, planning, gameplay and content readiness are structural iterations. During them, what needs to be done one way or another is done. None of the steps in this stage can be skipped. That said, testing and "polishing" are not required at this stage - there are next steps for them, which are qualitative iterations.
This is the main idea behind the process. "Opportunity time" at which the game can be qualitatively improved comes late in the project, so you need to free up time in these stages by moving some of the work to the early stages.
Perspectives
A little thought on perspective. It's pretty easy to get carried away with something specific when working on a game, and not notice how a large chunk of the game is left low quality. Processes like this, where the designer is responsible for many aspects of the game, constantly switching between them and being involved step by step in moving the development forward, allow the designer to keep the elements of the game equal in their eyes.
Every game developer must remember that there is no such thing as a completely finished game. There's no such thing as a developer who, after release, won't say that there's still room for improvement or fixes in the game.
When you're working on games, especially big ones that take three or four years to develop, you don't have to be a genius to estimate how many of them you can make in your lifetime. Perspective gives you an idea of how best to allocate your health, so you don't waste it on one or two games, but make them over the course of your life.