Sign in to follow this  
Followers 0
DF Lee

Art Update #5: World Creation Process

119 posts in this topic

Hey Backers!

As we near the end of the pre-production phase of development on Reds, we wanted to share an example of an internal team workflow document. There are many goals of the pre-production phase, including developing an art style, defining the core gameplay, and creating a high level plan to guide the rest of the game's development.

We also come up with workflows that define exactly HOW we are going to make most of the game's content. A good workflow minimizes bottlenecks, allows for iteration, works within the constraints of the project (time, people, etc) and plays to the strengths of the team itself.

Below is the workflow that we put together for the world art production. Bagel and I tested this workflow when we worked on the pre-viz, which helped us further refine the process. Like all workflows, this one will continue to develop and change as we design more of the game, build new tools, and figure out more efficient ways to approach the work.

Phase 1: High Level Area Design

• Initial design write up should provide a rough map or specify approximate dimensions specified in screens. For example, a clearing in the forest could be described as 2 screens wide x 1 screen high. If the player character can also walk “into an area” this should also be indicated.

• Ideally, the puzzle design for this area should already be worked out, if appropriate. At the very least, game-play critical areas should be identified so that the composition supports those areas.

• Several exploratory concepts of the areas will already be completed by this point, indicating what the overall look and feel should be.

Phase 2: Layout

• The goal for this phase of world creation is to create a very rough layout of the entire area. All elements located on a single game layer should be grouped together. Only enough detail should be created to judge the overall composition. A combination of concepts and rough sketches can be used for these layouts.

• Image size. The Photoshop file should be 2048x1536 for each screen in the area. For example, an area that is defined as 2 screens wide by 1 screen tall should have a layout Photoshop file created at 4096x1536.

• The “HD safe” areas of the image should be considered. These are border areas on the top and bottom of the image where no critical art should be placed, because these areas will not be present on platforms with a 16:9 aspect ratio. A template has been created with these areas marked.

• Player Scale defined. The size of the player character in this area can be indicated by placing and scaling a main character proxy image on a layer in the Photoshop file to the desired size. This will be used as a guide when the area is setup in-game.

• “Ideal Shot” defined. The image should then be drawn around the “ideal shot” for this area. The ideal shot indicates what the area should look like compositionally when the camera is in its default, most important, or most common position. Because the camera in most areas will move, the various planes will scroll, shifting the composition. The ideal shot shows the artists’ intent for the area and the multi-planes should be adjusted to support that composition as much as is possible.

• Lighting layers defined. Lighting layers are textures that replace, add to or multiply with existing layers to simulate changing lighting. They may also be combined with some form of dynamic lighting, although this is still TBD. It’s important to get an early idea of these lighting considerations because it may change the way the layers are separated or the scene is composed.

• Multi-Planes. An area is composed of several “planes”, each at a different Z-depth from the camera. All of the elements that make up any given plane should be grouped together in Photoshop. All groups should be clearly labeled and kept in the correct “sorting order”, with the groups that are closest to the camera kept on top and the layers that are furthest from the camera kept on bottom.

EXAMPLE: This image below represents a rough layout for a 1 screen tall by 1 screen wide area. Notice how no critical art or player path is in the HD safe area. Also note how several of the image elements have been separated into labeled groups in Photoshop, in proper draw order. The layers that are not grouped in the Photoshop file will NOT export, and are kept in the file for reference only.

art5_worldconstruction_02.jpg

Phase 3: Setup

• The goal of this phase is to move the images from the rough layout file into the game, setting up the multi-planes and basic functionality for the area. This setup will inform the final image sizes for each plane and also reveal what other changes are needed before the area can be moved to the paint phase.

• Exporting. The layout Photoshop file is exported to the game. The exporter looks for specifically named groups and exports them into separate files in the appropriate format/directory. Layers that are not in groups will be ignored on export. (Exact group names are TBD, but should probably just be a prefix – something like “Reds_Whatever”. This is important because it is unlikely that we will have a standardized set of planes for every room.)

• Room defined. Using the game engine, the new room is defined in terms of dimensions, player scale, and whatever other initial data needs to be created.

• Camera. A rough game camera will need to be available to test the composition/multi-planes. Probably the simplest solution is to have a “construction camera” (just for moving around and interacting with the scene editor) and also a “game camera/basic navigation” mode. At the minimum, to be able to recreate the “ideal shot”, as defined in the Photoshop file, the camera will need to be able to get into that location.

• Multi-plane setup. Each group of the original source file will be a separate plane at a different Z distance. The standard player path will be at Z=0. At this point, the Z depth of the planes can be adjusted to get the desired parallax effect. As layers are moved in Z depth, they can optionally maintain their “original screen size”. This helps preserve the composition as layers are adjusted for more or less parallax.

• Multi-Plane offset. Elements within a single game plane can be offset from one another, for slight depth variation without creating TONS of layers; however all intractable objects MUST be kept at Z=0 for that particular layer.

• Player Path/Scale Boxes. Additional player pathing can be setup at this stage, including “scale boxes”, which will control how the player character scales down when moving into or out of the Z depth of the area. Knowing this early will help the artist make sure that the environment feels at the correct scale when the player character changes its Z depth.

• Final Layer sizes defined. Now that the layers are setup at the desired Z depth and the camera can move around the area, some layers will need more pixels added onto one or more sides. In addition, it is possible that some layers will need less pixels, because they are far away from the camera and partially obscured by other layers. Ideally we’d have some tool or engine side way to assist in resizing and/or cropping these layers to help prepare for the paint phase. However this data is generated, the layer textures should be increased/decreased to their final sizes and tested in game.

• Components/entities defined. It may be that some elements of the layers will need to be separated into their own, re-usable texture. This will most commonly be used for repeatable elements such as grass tufts or rocks. Separating elements into components not only saves memory and production time, but may be necessary for animated objects or to help with performance (overdraw) issues.

EXAMPLE: This image below shows that after the multi-planes and camera were implemented, several of the planes needed more pixels added to one side. Follow the link below to see a movie of it in action. Also note how when the player ends their movement the scene matches the original “ideal shot” defined in the layout sketch. For this area, this is where the camera will spend most of its time, as the player interacts with the tree.

[vimeo]45609532[/vimeo]

art5_worldconstruction_03.jpg

EXAMPLE: The images below show how some of the planes were extended to have more pixels and also how some of the area elements were “componentized”. Because the trees were in the background, instead of painting a full screen size image containing trees, they were separated out into a few individual tree components. These components can be reused across other forest areas, save on memory & painting time, and reduce potential fill issues. In addition, these tree components can be scaled, flipped or rotated in the area to create variation.

art5_worldconstruction_04.jpg

art5_worldconstruction_05.jpg

EXAMPLE: This movie shows the same area, but with the planes extended to close the gaps and with many of the elements replaced with components instead of unique full-screen layers.

[vimeo]45609533[/vimeo]

Phase 4: Paint

• The goal of this phase is to paint up the rough layout art with nicely painted textures. Since everything is setup and working, this should remove any implementation issues and the artist can just dig in and paint.

• Individual layers. At this point, there is no longer a single Photoshop file containing all of the layers, but rather multiple individual files that are referenced in-game. Each of these layer files should have a source .psd file, where only the groups are exported (similar to the Layout phase).

• Hot reload. As each individual file is painted and saved, it should hot-reload in-game as quickly as possible. This will allow the artist to see how all of their work is looking in-context. This is especially critical because now that the layers have been separated, it will be harder to judge composition, etc.

• Composition Tweaked. The artist can use the in-game camera to fine tune the composition and make sure that there are no bad-tangents and other compositional eye-sores as the camera moves around.

• Componentization Revisit. After the scene has been painted, it may be that elements that were originally made components may not be visually working, and possible made into unique elements. Conversely, elements that were originally thought of as unique may work as components. Because there is an impact on memory and performance, any changes to componentization should be double checked with someone else.

art5_worldconstruction_06.jpg

Paint phase for the dialog tree area, with layers extended and HD safe areas indicated

Phase 5: Polish & Tune

• The goal for this phase is to add additional visual polish to the area through the use of dynamic elements, lighting and atmospherics. In addition, the scene should be optimized for performance and memory.

• Lighting. We will possibly have some form of dynamic lighting in the game. These would be lights that could affect one or more layers (and entities on those layers). Advanced behavior such as turning on/off, changing color, and flickering would also help make the world come alive and potentially be another tool to use with puzzle design and in aiding player navigation.

• Character Lighting. We have prototyped a few different ways that we could potentially light the character, including a fake “irradiance” gradient, a fake “rim light” and some form of shadow blobs. These types of things will probably need some sort of volumes or setup and this is the time in which that would be done.

• Fog. Fog is a color that is added to layers in the distance, in a simple liner fall-off. Fog will probably only be used in scenes where the player can move “into” the Z plane of the game, because otherwise it can simply be painted into the source art. The fog color, density, starting and ending planes should be tweak-able on a per-room basis. In addition, layers should have a “is affected by fog” attribute (default to on). It will be important to disable fog on distant background paintings and self-illuminated/glowing elements.

• Depth of Field. Distant layers, or extremely close layers, will have a slight blur effect applied to them. The blur amount and distance should be tweak-able on a per scene basis.

• Ambient Animation/Effects. Additional non-game-play ambient animations and effects such as smoke billowing in the distance or leaves blowing across the screen would be setup at this point. The implementation path for these types of things has yet to be discussed, but will most likely use the same approach that we are using on the characters.

• Player Path/Scale Box refinement. This should be refined to match the fidelity of the art created in the paint phase.

• Clip Geometry. Some layers or textures may have lots of transparent pixels, which can cause performance issues (overdraw). These layers may need to have custom clip geometry defined for them. If the resolution of the clip geometry is too high then this could potentially cause performance issues as well, so vertices should be used in moderation. Layers that don’t clip well can also be broken up into smaller components that contain less transparent pixels in their border areas. Clip geometry will be defined in the scene editor tool.

• Clean up Alpha. For performance reasons, alpha should be limited as much as possible. Because our game has a painterly style, most layers will need alpha around the perimeter, but we should eliminate any unnecessary alpha in the middle of a layer.

• Clean up the “floating nards”. Each layer should be inspected to ensure that there are no unintended floating pixels in areas that are intended to be totally transparent.

art5_worldconstruction_07.jpg

Polish & Tune phase showing DOF, lighting, navigation & ambient effects setup

EXAMPLE: This image shows a layer that has had custom clip geometry defined for it to reduce the amount of overdraw (due to the large amounts of transparent pixels). The least amount of polygons should be used to remove the biggest chunks of transparency possible.

art5_worldconstruction_08.jpg

EXAMPLE: The images below show the alpha cleanup process where transparent pixels in the middle of what is largely an opaque mass are made opaque to reduce the amount of transparency on the layer. The edges are left alone and retain their painterly, soft edge. The end result barely changes the look and is much better for performance.

art5_worldconstruction_09.jpg

The foreground layer is inspected for excess transparency.

art5_worldconstruction_10.jpg

There are several areas that have transparent pixels that don’t affect the silhouette or are very noticeable in the final scene.

art5_worldconstruction_11.jpg

Those areas are made opaque by filling a color layer behind the transparent areas (in Photoshop) that matches the color of the layers that are behind the foreground layer in game.

art5_worldconstruction_12.jpg

Final product with newly opaque areas looks almost identical to original.

EXAMPLE: It is unfortunately easy for stray pixels, or floating nards as they are now know, to be unintentionally left in the transparent area of a layer. This can potentially cause both memory and performance concerns. Each layer should be inspected for these extra pixels and they should be removed.

art5_worldconstruction_13.jpg

The dialog tree layer is inspected for any floating nards.

art5_worldconstruction_14.jpg

In Photoshop, the magic wand tool with 0 tolerance and no feathering is used to select the transparent areas. Any stray pixels will show up with the “crawling ants” selection. These areas should be erased.

Share this post


Link to post
Share on other sites

Those dang floating nards.

So are the artists constantly painting in Photoshop and then hot-reloading in the game engine, back and forth, until the composition is just right?

Share this post


Link to post
Share on other sites

I think there should be more pixels. Everywhere.

Share this post


Link to post
Share on other sites

These updates are very elucidative for game devs.

A few months ago I was just trying to implement a Parallax component in XNA and for the clipping issue I used an approach of keeping track of when the parallax layer is offscreen to then copy it over to the opposite side of the screen and keep the flow without any glitches (and also so that I can use layers of any width).

It's not perfect because I still have to optimize the algorithm to reduce overhead on the draw calls by calculating the best clipping size, but it was sure fun to work on the solution. I love working with components and code rather than design, so this kind of challenge is always awesome. And it's also very estimulating when I read these programming updates and see that my solution was not so far off from the one given by the pros (for instance, the scaling of the character on the screen to give the illusion of depth [shown in a previous update video] is another component I was working on).

Here's a video showing the test I did with the parallax component. It's totally ugly and such but I had a lot of fun coding and watching the solution actually working. That's the fun of coding for games in contrast to other kinds of applications.

Just in case someone is curious to look into the code (it's not the best C# code because I was using the opportunity to learn C# as well :), but it serves the purpose): https://github.com/hgorni/ParallaXNA

Share this post


Link to post
Share on other sites

Not being in the games industry at all, I find this all really exciting to read and learn about. The more I read, though, the more questions I have! I'm just going to throw a bunch of these out there and hope for some more interesting developer answers:

Is all this emphasis on reducing unnecessary rendering and memory (overdraw, alpha, too many elements/layers, layers too big, etc.) mostly related to the release of this game on mobile OS's or is it just standard game development consideration? That is to say, if you didn't impose restrictions on overdraw and layer size and the like, would my modern PC have any performance issues? What about an iPad 2 or Asus Transformer Prime as opposed to smaller mobile devices? What sort of memory savings come out of making reusable components? How many hours of cleaning and optimizing and composition tweaking are done for each hour of original art creation? Do you/the writers and puzzle designers find the need for interactable objects to be at z=0 to be restrictive? Why can't you have an object at z=-10 that the hipster lumberjack can walk to in the same scene and interact with?

Okay, that's it for now! You guys have created an amazing and unique art style for this game and I can't wait to see more of it.

Share this post


Link to post
Share on other sites

Wow. I knew that this wasn't a simple process but I is amazing all the work that goes into one little part of the game. I can't wait to learn more about the dev process. Also I must learn how to work floating nards into everyday conversation.

Share this post


Link to post
Share on other sites

Wow. That's beautiful.

But I still see some Floating Nards.

Share this post


Link to post
Share on other sites

So...HD-Safe areas mean folks with 16:9 screens will actually see LESS of the game?

Share this post


Link to post
Share on other sites
...

Is all this emphasis on reducing unnecessary rendering and memory (overdraw, alpha, too many elements/layers, layers too big, etc.) mostly related to the release of this game on mobile OS's or is it just standard game development consideration? That is to say, if you didn't impose restrictions on overdraw and layer size and the like, would my modern PC have any performance issues? What about an iPad 2 or Asus Transformer Prime as opposed to smaller mobile devices? What sort of memory savings come out of making reusable components? How many hours of cleaning and optimizing and composition tweaking are done for each hour of original art creation? Do you/the writers and puzzle designers find the need for interactable objects to be at z=0 to be restrictive? Why can't you have an object at z=-10 that the hipster lumberjack can walk to in the same scene and interact with?

That's a lot of questions! Reds team has a build tomorrow, so I'll answer them quicklike

Optimization of this sort is common to all games on all platforms. Of course, less powerful platforms require more optimization work, but it's not just for mobile devices as modern, but less powerful PCs (i.e netbooks or laptop w/ embedded GPUs) have similar performance profiles to a tablet or smartphone.

On all devices, especially tablets and smartphones, the main factors affecting performance are screen resolution, GPU architecture, GPU speed, and CPU speed. A common performance challenge is the relationship between GPU speed and screen resolution. Device manufacturers love to brag about screen resolution but often don't scale their GPUs to match. For example, many games run better at native res on iPhone 3GS than on iPhone 4 because the iPhone 4 has a retina screen (4x the number of pixels of a 3GS) but doesn't have a GPU that is 4x as fast as the 3GS.

Reusable component memory savings is variable, but if you imagine that the layer with all the trees is 4096x2048, that would be 32 MB (uncompressed). One tree might be 512x1024, which is 2 MB (uncompressed). That's a 16:1 difference. Components also help artists work more efficiently, so it's a human time savings, not just a memory savings.

Optimization time depends on game, tools, etc. Lee could provide better answers on that than me. For graphics programmers, though, we generally budget features at 50% implementation, 50% optimization.

There's no technical reason interactive objects have to be at a certain depth, but it helps clarity and is a good standard/baseline.

Share this post


Link to post
Share on other sites

Thanks for the update, Lee. Really cool to see what goes on behind the scenes of something players often take for granted- the game mechanics. I especially liked seeing how the parallax works with the layers.

Share this post


Link to post
Share on other sites

I'm running out of words to describe how these updates are interesting and great to read.

It was a little surprising to see that 4:3 is the standard and there's a 16:9 safe area and not the other way around.

I think the majority of players would play it on a 16:9 monitor so even a choice to have 2 black lines at the top and bottom for 4:3 could have been acceptable. It's true that if you always like to see a full screen of details on both aspect ratios then that's the logical choice (since the player usually move to the edge left or right), but that could still cause some odd things when the player goes down or up. I mean, to create a road that continue at the bottom of the screen to the next screen you'd have to add a very large strip of non-essential art at the top.

Share this post


Link to post
Share on other sites
So...HD-Safe areas mean folks with 16:9 screens will actually see LESS of the game?

I'm also curious about this. I was given the impression that something similar but reversed where the widescreen was given more on the sides than the thin(?) screens but that the sides were meant to NOT hold important stuff. Is that in film?

Is this done to catch a larger population of people with thin screen monitors?

Share this post


Link to post
Share on other sites

Nice update, thanks. It is especially interesting for me as an occasional Photoshop user.

Share this post


Link to post
Share on other sites

Excellent, very informative post!

The choice of cropping the screen for 16:9 is a little unusual for me as well, I would appreciate more info on this.

I think in theory if you would preserve vertical space on all displays, the screens would "just" need less horizontal scrolling to see all content on widescreens, is this the reason behind the cropping choice (it could break composition)?

Thanks!

Share this post


Link to post
Share on other sites

Great post.

I'm having trouble though watching the videos from Germany :( The music content might be cause, it is quite common here to have videos in Youtube and Vimeo not available because of that. Not sure if there is something you can do to solve this on your side

Share this post


Link to post
Share on other sites

Regarding the 16:9 Crop: I think this is due to the Ipad having a 4:3 Screen - and this seems to be the "lowest common denominator" nowadays, to deliver a borderless, full-screen experience to all platforms.

I just hope DF Adventure will also deliver full-screen experience for 16:10 Displays.

Cropping is certainly not the most artistic choice to come up with but, if executed well, i'm usually fine with it - it's quite common in cinema (most of Stanley Kubrick films were 'composed' this way ;) )

Share this post


Link to post
Share on other sites
Regarding the 16:9 Crop: I think this is due to the Ipad having a 4:3 Screen - and this seems to be the "lowest common denominator" nowadays, to deliver a borderless, full-screen experience to all platforms.

I just hope DF Adventure will also deliver full-screen experience for 16:10 Displays.

Cropping is certainly not the most artistic choice to come up with but, if executed well, i'm usually fine with it - it's quite common in cinema (most of Stanley Kubrick films were 'composed' this way ;) )

16:10 would be fine means you have a bit more top and bottom then 16:9 displays.

Share this post


Link to post
Share on other sites
So...HD-Safe areas mean folks with 16:9 screens will actually see LESS of the game?

I'm also curious about this. I was given the impression that something similar but reversed where the widescreen was given more on the sides than the thin(?) screens but that the sides were meant to NOT hold important stuff. Is that in film?

Is this done to catch a larger population of people with thin screen monitors?

This is common use in Game development to adjust different screen aspect ratio.

Only few directors does the same thing for movies. James Cameron shoots like that because he is a perfectionnist and want

a full res version for each screen size. it's called open matte.

The most important is how the screen is composed. Usually it is composed for 16/9 / widescreen, with only the rest of the picture being filled

to avoid black bars.

So yes you get more visual stuff in 4/3, but you usually get better visual composition in 16/9 :)

Share this post


Link to post
Share on other sites

This technical updates are really great, thanks! Can you share how you implement the clip regions on the engine to save on the alpha blending costs? Do you use a non quad polygon to render the texture? Or do you use custom fragment shaders that do the clipping? Or something else entirely? Oh, so many questions...

Share this post


Link to post
Share on other sites
This technical updates are really great, thanks! Can you share how you implement the clip regions on the engine to save on the alpha blending costs? Do you use a non quad polygon to render the texture? Or do you use custom fragment shaders that do the clipping? Or something else entirely? Oh, so many questions...

You are right we will use concave polygons (potentially with holes) to render textures. This means we increase the amount of vertices but gain performance by reducing overdraw.

Share this post


Link to post
Share on other sites

Since Reds will run on many different platforms with many different aspect ratios (in addition to mobile devices computer screens come in all kinds of shapes). In this case it is generally better to author screens with a more square-like aspect ratio rather than picking the rectangular ratio. This is because the gameplay is mostly horizontal which means you really need to be able to see the left and right edges and fitting a rectangular aspect-ratio into a 4:3 screen makes this possible.

Also please bear in mind that we can easily add a option to 'zoom' the game out to fit any aspect ratio.

Share this post


Link to post
Share on other sites

So very interesting to see how art integrates into a 'manufacturing' process. Thanks. Looking more beautiful every post.

Share this post


Link to post
Share on other sites

This was a great post! Thanks so much.

Though I was kind of curious to some things:

Why 4:3 over 16:9?

I don’t know about others, but I’ve kind of grown used to wide-screen. Even on my Ipad, heck evn DoTT and MI 1&2 etc were kind of widescreen, and to me it would also be a better choice for say an iPad. Another thing is that most devices; phones, PCs, TVs etc. have more of a 16:9 layout, and might eventually get a lot higher resolution than the current iPad, cropping will reduce the amount of pixels as well, causing lower fidelity on PC/Mac than it could have been. Not to mention the “zoom effect” if a film is shot in wide and cropped for 4:3 it will not feel like it’s being zoomed in, but if you corp the 4:3 into wide it will feel like it’s scaled up.

Are you not making the artwork in higher resolution than almost today’s highest standards?

I get that storage space and hardware can be a drag, just think about the MBP Retina for example. That display might be unique now, but in a year, when Reds is almost out 2880×1800 resolution or higher won’t be that uncommon. I’m just putting that out there.

On Steam, have you considered releasing the game with resolution DLC?

It might be an issue that not all computers are the best in the world, but take Skyrim as an example; you can download a High Resolution DLC via Steam. If Reds was released in a SD resolution with optional resolution DLC it might be more accessible, some people might really want to have Reds take 20 GB of their HD space, but then they can download that as a pack, ultimately making it more flexible for buyers. Of course the other option is to force one resolution and have it scale up or down in some GPU rendering.

Back to widescreen on the iPad: I think there are a lot of good things with having the bars; you could put information that is not available for a “mouseless” interface there as well; if for instance a cut scene is rolling a common thing to do is to hide the cursor, not only is it more pleasing to watch without a arrow over things, but also it tells us that right now we are watching a cutscene and if we click out mouse it will be skipped. If you had a UI or something in the black bars on the iPad that would fade away during cutscenes that too could have a similar effect.

Again thanks a lot for the post. It’s a very good read :)

Share this post


Link to post
Share on other sites

Also please bear in mind that we can easily add a option to 'zoom' the game out to fit any aspect ratio.

Being that most screens are in the Wide (as I understand it rectangular) shape. wouldn't the zoom out be more suited for the iPad and other more square things out there? I all these owners are used to stuff like pinch to zoom out and slide to pan etc. A static screen like on a laptop, desktop or TV would really not need the option to be zoomed in in the first place, because of the bigger size display, and you wouldn't be able to pan the screen from side to side either, unless the screen panned along the cursor, but that could be very cumbersome based on the fact that all the things you are clicking becomes moving targets.

Thanks.

Share this post


Link to post
Share on other sites
Sign in to follow this  
Followers 0