Thursday, August 29, 2013
Personal Update #1 Brainstorming Narrative and Gameplay
Hey Readers (or anyone really)
I wanted to give a bit of an update on myself, what I am doing, and where my brain is. Recently most of what I have been posting has been paintings. I will be continuing this into the future, but I have also been preparing for work on some form of interactive side project.
Recently I have been talking with friend of mine about narrative and gameplay, and how they should interact. Here are some thoughts on what has been going through my brain.
We have been talking, specifically, about the idea that gameplay and narrative can be developed, but only in 3 broad ways. The first, is that both are 100% separate. No interaction at all. This is obviously the easiest solution where a mechanic can have nothing to do with the world or story trying to be told. The second, is that the gameplay comes directly from the narrative. A good example would be super powers in the Infamous games, where the powers in the game tie directly into the universe the game is set in, because the story and universe is about super powers. This is ideal because when the player "plays" the game, they are reinforcing the overall immersion of the experience.
Unfortunately, the drawbacks come in the form of restrictions. Usually choosing this option means you have to sacrifice more and more of the environment and narrative to make things make sense, or alternatively sacrificing gameplay to fit into your world. Finally the third option, is one of the opposite of the previous, where narrative is formed around gameplay. A cool mechanic (like surfing dreams for example) is a neat idea, and a story could be written to form around that basic idea, rather than vice versa. The downside of this technique means you usually very limited in the types of narrative you want to do.
Over the last few days, I have been thinking lots about the various blends between these ideas as we (me and my friend) have been trying to find a mechanic that really fits our narrative (which we have a pretty solid idea of). On one hand, the easy solution is the reason we see so many disconnected puzzle exploration games, where the "game" part sits separately from the "narrative" part. Once you decide that you want the mechanics in your game to really tie into narrative, it becomes a creative quest to try things out and push out from there.
Anyway, just some brain blots as I continue forward. I should be starting a new weekly render analysis to break down some visuals from well known stories, and will also be posting some more technical work as I move forward.
Thanks for reading,
Alex
I wanted to give a bit of an update on myself, what I am doing, and where my brain is. Recently most of what I have been posting has been paintings. I will be continuing this into the future, but I have also been preparing for work on some form of interactive side project.
Recently I have been talking with friend of mine about narrative and gameplay, and how they should interact. Here are some thoughts on what has been going through my brain.
We have been talking, specifically, about the idea that gameplay and narrative can be developed, but only in 3 broad ways. The first, is that both are 100% separate. No interaction at all. This is obviously the easiest solution where a mechanic can have nothing to do with the world or story trying to be told. The second, is that the gameplay comes directly from the narrative. A good example would be super powers in the Infamous games, where the powers in the game tie directly into the universe the game is set in, because the story and universe is about super powers. This is ideal because when the player "plays" the game, they are reinforcing the overall immersion of the experience.
Unfortunately, the drawbacks come in the form of restrictions. Usually choosing this option means you have to sacrifice more and more of the environment and narrative to make things make sense, or alternatively sacrificing gameplay to fit into your world. Finally the third option, is one of the opposite of the previous, where narrative is formed around gameplay. A cool mechanic (like surfing dreams for example) is a neat idea, and a story could be written to form around that basic idea, rather than vice versa. The downside of this technique means you usually very limited in the types of narrative you want to do.
Over the last few days, I have been thinking lots about the various blends between these ideas as we (me and my friend) have been trying to find a mechanic that really fits our narrative (which we have a pretty solid idea of). On one hand, the easy solution is the reason we see so many disconnected puzzle exploration games, where the "game" part sits separately from the "narrative" part. Once you decide that you want the mechanics in your game to really tie into narrative, it becomes a creative quest to try things out and push out from there.
Anyway, just some brain blots as I continue forward. I should be starting a new weekly render analysis to break down some visuals from well known stories, and will also be posting some more technical work as I move forward.
Thanks for reading,
Alex
Wednesday, August 28, 2013
Tuesday, August 27, 2013
Sunday, August 25, 2013
Wednesday, August 21, 2013
Tuesday, August 20, 2013
Sunday, August 18, 2013
Thursday, August 15, 2013
Wednesday, August 14, 2013
Tuesday, August 13, 2013
Monday, August 12, 2013
Some Lighting Paint Overs
A few weeks back I was helping my friend with some personal art he was doing, specifically helping him tune in some materials, as well as giving him some pointers with lighting in an effort to add a bit of mood and narrative. Here are the paint overs:
Edit* The original had no paint, only hte center cable, and only one light source from the right. While the image came out bloomy (my bad) the extra darks and lights added contrast to the scene that wasn't there before, both drawing the eye to the areas where the darks and the lights met, as well as giving more complimentary colors to a more desaturated style.
Edit* The original had no paint, only hte center cable, and only one light source from the right. While the image came out bloomy (my bad) the extra darks and lights added contrast to the scene that wasn't there before, both drawing the eye to the areas where the darks and the lights met, as well as giving more complimentary colors to a more desaturated style.
Sunday, August 11, 2013
Blend shaders within the UDK
Quick post here, just wanted to talk about some shader work I've been doing within the UDK. Recently I finished up a multimaterial blend shader that support 3 full materials, each with Normal, Spec, Diffuse. The 3 materials are painted with the R and G channels of vert colors for meshes, and blend based off of height maps.
While I was doing this shader (for a friend) I wanted to push the tech even farther. I optimized texture usage by storing Gloss and Height within the Diffuse and Spec, and added support for ambient spec and diffuse through the emissive channel. Recently I figured out how to blur cube maps within the UDK based on Gloss, and I used the surface gloss values to define the sharpness of the ambient spec. I also used the lowest level of the mip chain of the environment cube map for the ambient spec. All of this is entirely artist controlled.
Another feature I chose to include was a puddle that blended off of the Blue vert color. All the vert blending was set up on a tier of priority, with puddles at the top, allowing artists to paint whatever material they want, then have puddles on top. The puddles darken the diffuse, have optional ripples, and have their own spec and gloss values. The puddles also dampen the normals of the underlying material, but even that can be controlled allowing artists to create the illusion of both wet, or full puddles.
For a last trick I used the same blurring technique for the cube maps to blur any of the hightmaps from the other materials and the puddles. This was a super effective technique, since some height maps can come across super harsh, and blurring them adds realization. It also allows for texture re-use to save on memory.
The biggest problem I ran into executing this last trick was the same problem I ran into blurring the cubemaps: To go down a mip chain on a texture in UDK, you have to use a custom HLSL node and the tex2dBias intrinsic function (or texCubeBias for the environment map). The catch is the input for those commands are a texture sample, which is not accessible by placing a texture node in the UDK. However, if you connect a texture node up to a chain (and have it impact nothing, ie multiplying it by 0 then adding it back into the chain) you can pull up the source code, and track down the procedural tex2d Sample that the UDK generates, then use that for the actual tex2dbias command. It is a bit of a hack, but it works very well.
For performance, the final texture count was relatively low. The packing the gloss and height, meant that for 3 materials, only 3 textures were needed for each, bringing the total to 9, plus 1 texture twice for the ripples, and 1 for the environment map. The instruction count came in at 160, which is a bit on the high side, but can be lowered by turning off the ripples. I also made a lower instruction count version that only supports the puddle painting, which came in at 100. Not a bad price for something that supports ambient lighting but still works well with UDK's lightmass.
Overall it was a great experiment and will be useful in the weeks to come :)
While I was doing this shader (for a friend) I wanted to push the tech even farther. I optimized texture usage by storing Gloss and Height within the Diffuse and Spec, and added support for ambient spec and diffuse through the emissive channel. Recently I figured out how to blur cube maps within the UDK based on Gloss, and I used the surface gloss values to define the sharpness of the ambient spec. I also used the lowest level of the mip chain of the environment cube map for the ambient spec. All of this is entirely artist controlled.
Another feature I chose to include was a puddle that blended off of the Blue vert color. All the vert blending was set up on a tier of priority, with puddles at the top, allowing artists to paint whatever material they want, then have puddles on top. The puddles darken the diffuse, have optional ripples, and have their own spec and gloss values. The puddles also dampen the normals of the underlying material, but even that can be controlled allowing artists to create the illusion of both wet, or full puddles.
For a last trick I used the same blurring technique for the cube maps to blur any of the hightmaps from the other materials and the puddles. This was a super effective technique, since some height maps can come across super harsh, and blurring them adds realization. It also allows for texture re-use to save on memory.
The biggest problem I ran into executing this last trick was the same problem I ran into blurring the cubemaps: To go down a mip chain on a texture in UDK, you have to use a custom HLSL node and the tex2dBias intrinsic function (or texCubeBias for the environment map). The catch is the input for those commands are a texture sample, which is not accessible by placing a texture node in the UDK. However, if you connect a texture node up to a chain (and have it impact nothing, ie multiplying it by 0 then adding it back into the chain) you can pull up the source code, and track down the procedural tex2d Sample that the UDK generates, then use that for the actual tex2dbias command. It is a bit of a hack, but it works very well.
For performance, the final texture count was relatively low. The packing the gloss and height, meant that for 3 materials, only 3 textures were needed for each, bringing the total to 9, plus 1 texture twice for the ripples, and 1 for the environment map. The instruction count came in at 160, which is a bit on the high side, but can be lowered by turning off the ripples. I also made a lower instruction count version that only supports the puddle painting, which came in at 100. Not a bad price for something that supports ambient lighting but still works well with UDK's lightmass.
Overall it was a great experiment and will be useful in the weeks to come :)
Thursday, August 8, 2013
Wednesday, August 7, 2013
Tuesday, August 6, 2013
Why I paint every day
I get asked this a bit and the answer is pretty simple. I am not looking to become a master painter or amazing concept artist or anything like that. Currently I paint every day to learn enough that it can be my tool of choice when visually communicating things like composition, shape, color, or visual narrative.
Where I stand in my skill set right now, I communicate the best through 3D environments, however making said environments, even in a basic form (and then iterating on them) is not always a fast process. Painting to me, is great because its fast and simple. So for right now, that is why I practice. I also feel it is similar to cheating at art because for 40 minutes a day, I get to practice lighting, composition, painting, and narrative all with one simple set of exercises. It also acts as a personal creativity dump where every day I get to stretch those muscles in my brain that don't get used at work (where I work on an established franchise with others). It feels great to tell 3-10 little stories every night and know they are my own.
Where I stand in my skill set right now, I communicate the best through 3D environments, however making said environments, even in a basic form (and then iterating on them) is not always a fast process. Painting to me, is great because its fast and simple. So for right now, that is why I practice. I also feel it is similar to cheating at art because for 40 minutes a day, I get to practice lighting, composition, painting, and narrative all with one simple set of exercises. It also acts as a personal creativity dump where every day I get to stretch those muscles in my brain that don't get used at work (where I work on an established franchise with others). It feels great to tell 3-10 little stories every night and know they are my own.
Subscribe to:
Posts (Atom)