Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Resident Evil 4
View All     RSS
April 19, 2018
arrowPress Releases
April 19, 2018
Games Press
View All     RSS






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: Resident Evil 4


June 26, 2013 Article Start Previous Page 3 of 4 Next
 

What Went Wrong

1. Freshen Up

The goal of any game's storyline is to expand the depth and perception of that game's universe, as well as to inform players of what they are to do. In Resident Evil 4, the storyline was primarily conveyed through our real-time movies. We had a hard time achieving our concept of combining gameplay with the necessary story elements that could evoke a feeling of believability within the in-game movies.

Games are a visual medium, and throughout the series, it wasn't always easy to create fresh concepts. It was even more difficult to develop visuals that would continue to advance the series. This is why we thought of a new direction for Resident Evil 4's development, which we call "complete concept changes." That is to say, we examined all the previous gameplay features and notions of fear and broke them down to change the entire concept for the game.

2. Data Constraints

Because this version of Resident Evil was far more action-based, we often needed to display a very large number of characters at once (see Cutscene Images A–D). As a result, we needed to carefully apply model textures for these types of scenes. Normally, an enemy character in the game has about 3,000 polygons and is about 400K of data space. There are some scenes in the game, though, that had up to 25 characters on screen simultaneously. We weren't able to adjust all the memory and image storage to the level that would be required for us to keep those 3,000 polygon models intact.

In order to address this issue, we decided to adjust the amount of data per model in each scene, and even in cuts within the scene. First, we would implement the model that required the most data (usually the closest to the camera). Then we adapted it by deciding how it would be drawn and processed, based on memory levels. Limiting the amount of data on all the models would result in poor quality, so we prioritized the portions of the models that would require the best modeling. We came up with three different scenarios for how to distribute the data for texturing the models, which could then be used in various situations by combining them.

A normal high resolution model for a Ganado, a generic enemy in the game, consisted of approximately 3,500 polygons. Normally, it would be difficult for us to render several high resolution Ganados on screen simultaneously. Therefore, we created two additional variations of the model: mid-resolution Ganado, which are approximately 2,000 polygons, and a lowresolution model with about 1,000 polygons. These three models would switch depending on the situation. Textures were treated in the same way. High-resolution textures were 512x512 pixels, mid-resolution textures were 256x256 pixels, and low-resolution textures were 128x128 pixels.

As mentioned, these models could be switched depending on the situation, according to two conditions: how many models the scene required, and how much data was available for the given scene. We always attempted to be efficient with our data sizes, so we would reduce the model and texture data by taking into account the camera and lighting used for certain scenes.

3. Texture vs. Light

In addition to the models, we also adjusted textures for each scene. We sometimes faced problems with how to adjust the way that characters looked when different lights hit them. This happened especially when we used a lot of penetrating or spot lights. We solved this problem by creating textures for each scene or each cut.

Not only was this used for something as detailed as eyes (Figure 7), but was used widely, anywhere from the characters' bodies, to background objects. This texture adjustment was also useful in addressing problems with dynamic lighting situations, such as when dented objects were being lit too brightly. In cases when a model would only be seen from a distance and required little to no shading information, we reduced the data amount because the dimensions visually do not stand out very well, and the difference would not be noticeable. In another case, when a character's shadow would stand out due to the camera's position, we wouldn't use the low-resolution model, as it would not be capable of properly rendering the delicate lighting details. Instead we would use a high-resolution model with low-resolution textures, still keeping data use down.


Article Start Previous Page 3 of 4 Next

Related Jobs

Abrakam SA
Abrakam SA — Li├Ęge, Belgium
[04.19.18]

Game Designer
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[04.17.18]

Senior Mission Designer
Dischan Media Inc.
Dischan Media Inc. — Coquitlam, British Columbia, Canada
[04.17.18]

3D Modeler/Game Designer (NOC 5223)
Magic Leap
Magic Leap — Plantation , Florida, United States
[04.16.18]

Game Designer





Loading Comments

loader image