Saturday, August 23, 2014
A Site For Sore Eyes
Get it? Well anyway, I've finally created a site that will contain my blog posts from now on along with games I make and other things. This will also be a place I can sell games and maybe even some custom vinyl toys. All good things. The new site is http://www.dougmakesgames.com/
Monday, August 4, 2014
ThumbderDome Alpha
One Thing Missing
So I have the first build of the game and everything is working great. I don't have any audio yet but I've been looking into sound effects and the various licenses I need to obtain for certain things. Further info is being collected but I haven't implemented anything for that yet. I also didn't quite make it all the way to my alpha goal. The game is playable from beginning to end but it's missing the taunt scene in between the match and the continue screen. this scene is cosmetic and has not input from the player so I'm lumping it into my beta deadline next Sunday. So let's take a look at some things That have changed.
Conclusion
So there is still plenty of work to do to reach beta. I need music and sound effects along with a bunch of other things on my list. I need to make the taunt screen I mentioned a polish some animations. I started looking into selling the game for a really small amount and still haven't worked out all of the logistics there. We'll see where I land once this things is done. I also still need to make a simple animation of a ui element telling the player to wiggle the joystick when they get pinned. I'll post another update soon.
So I have the first build of the game and everything is working great. I don't have any audio yet but I've been looking into sound effects and the various licenses I need to obtain for certain things. Further info is being collected but I haven't implemented anything for that yet. I also didn't quite make it all the way to my alpha goal. The game is playable from beginning to end but it's missing the taunt scene in between the match and the continue screen. this scene is cosmetic and has not input from the player so I'm lumping it into my beta deadline next Sunday. So let's take a look at some things That have changed.
Character Selection Animations
Characters now play a selection animation when you select them. If you move to another selection they return to their idle thumbs up animation. This animation is re used when the player wins the match and also when they continue at the continue screen. A bunch of refactoring went in to support this because before I wasn't expecting to have anything play when character is selected.
Split Screen Adjustments and Struggle Meter
I change the orientation of the split screen margin. It used to be diagonal but it was weird for one player to have a different view space than the other. I also change the second player cam to more closely reflect the first player camera on the left. They still aren't 1:1 but I will sort that out in the beta build. Additionally I added a struggle meter at the top. When a player is pinned they wiggle the joystick and the meter will push in the other players direction until filled and they escape the pin. Before I was just incrementing a counter and didn't have any ui to support this. I also added some code that would allow the player that is pinning to fight back against the struggle meter to force the pin down. This is commented out as I can't really test it on myself because my brain is always letting the other half win. The idea is that the pinned player will have a max value to achieve that is multiplied by the number of times they have been pinned in a round. The player that is pinning has a static value for which to fight back so the more times a player is pinned the harder it will be to win against the pinning player. At least in theory. Again I haven't tested it yet so it's commented out in code and I'll test it with some players. I also changed the "Pinned!" ui text to be on top of the player that gets pinned instead of showing up in the middle.
The idea I went with for character select scene.
Another example of some grids leading off into the distance.
Player Specific Win Animations and New Look
As I mentioned before animations are being used for each winning character. For Grave Digger I googled "Relgious hand gestures" and found one that I hope isn't offensive. The other are ones that I just came up with. This also required some hefty refactoring to support the changes. You'll also notice the neon grid in these scenes. Let's just throw this out there. I like 80's pop culture art and misc. I don't know why exactly. Maybe just something fun to look back on. Maybe it's the super simplicity of it. Maybe it reminds me of being a kid. I just like the way technology and the future were represented in the 80's. In any case after making the start screen I realized there was a visual inconsistency through the scenes. I decided to create something simple but still appealed to my direction of wrestling's golden age in the 80's. I looked at some images for inspiration and added some of them below to look at. My characters don;t really have any specific 80's look to them they just represent a theme that a wrestler might have taken on and represented to such an extreme. Plus they're floating hands sooooooo you know.
Continue Screen
I added a continue screen where a countdown begins. If the player doesn't press their respective trigger then the game ends and it returns to the title screen. If they continue then it returns to the character select screen. This was all done on Saturday night. I looked at the clock when I called it done and realized it was 5:00 am. I have to stop doing that. (Don't look at the timestamp on this post.) The 80's neon grid is in view here as well. I made a shader that would falloff to black so it would look like the grid fades into the darkness. Also made some trigger icons that follow the theme of the font I'm using.Conclusion
So there is still plenty of work to do to reach beta. I need music and sound effects along with a bunch of other things on my list. I need to make the taunt screen I mentioned a polish some animations. I started looking into selling the game for a really small amount and still haven't worked out all of the logistics there. We'll see where I land once this things is done. I also still need to make a simple animation of a ui element telling the player to wiggle the joystick when they get pinned. I'll post another update soon.
Saturday, August 2, 2014
Title Change
Welcome to Thumbderdome
So I decided to change the title. I went through a couple variations. One was a play on WTF Wrestling Thumb Federation but it still lacked something cool and there is already some web series called TWF Thumb Wrestling Federation. Mine was way too close to that. I also just didn't like "Thumb At Me Bro!". It was just a little off and didn't sound right to my ear. After writing down all of the things that came to mind when I thought about wrestling entertainment from way back I knew I wanted to have some kind of imagery to capture the golden age of wrestling. I also think constantly about the cage matches and the whole "Two men enter. One man leaves." So with that, I landed on ThumbderDome Wrestling. The other cool thing about this name is the "bd" consonant paring. In the font I was able to adjust it to somewhat resemble two thumbs facing each other. I made some other updates in code unrelated to this but I just wanted to make a quick post to put up the start screen art.
So I decided to change the title. I went through a couple variations. One was a play on WTF Wrestling Thumb Federation but it still lacked something cool and there is already some web series called TWF Thumb Wrestling Federation. Mine was way too close to that. I also just didn't like "Thumb At Me Bro!". It was just a little off and didn't sound right to my ear. After writing down all of the things that came to mind when I thought about wrestling entertainment from way back I knew I wanted to have some kind of imagery to capture the golden age of wrestling. I also think constantly about the cage matches and the whole "Two men enter. One man leaves." So with that, I landed on ThumbderDome Wrestling. The other cool thing about this name is the "bd" consonant paring. In the font I was able to adjust it to somewhat resemble two thumbs facing each other. I made some other updates in code unrelated to this but I just wanted to make a quick post to put up the start screen art.
Friday, August 1, 2014
Thumb At Me Bro!
This is the title I'm going with for my thumb wrestling game. I have made a ton of progress and I've only really been working on it for two weeks but it feels really good to see it come together. Since the scope of this game is so small I'm free to play in between the lines. It's in that spirit that I've added 4 skins for the hands which are acting as characters. I'm really drawing inspiration from the feeling of pro wrestling entertainment I watched as a kid and the personalities each wrestler had. They always seemed to embody some kind of specific gimmick and go way over the top with it. The other fun thing is that since it's so easy to just make skins for the characters I can make a bunch if I want. So now I have a character Select screen that fades into the main event scene where the match happens.
This is the title I'm going with for my thumb wrestling game. I have made a ton of progress and I've only really been working on it for two weeks but it feels really good to see it come together. Since the scope of this game is so small I'm free to play in between the lines. It's in that spirit that I've added 4 skins for the hands which are acting as characters. I'm really drawing inspiration from the feeling of pro wrestling entertainment I watched as a kid and the personalities each wrestler had. They always seemed to embody some kind of specific gimmick and go way over the top with it. The other fun thing is that since it's so easy to just make skins for the characters I can make a bunch if I want. So now I have a character Select screen that fades into the main event scene where the match happens.
I also changed the way pinning works. Before I was checking for some ranges where the pin could be in a pinnable state and then you had to click the trigger to invoke a pin. this caused a lot of fatigue on the players hand so now you can use the trigger on your side of the controller. Additionally you can invoke a pin with this button even if you're not holding up. Each time you miss though there is a moment of vulnerability whch makes the game more exciting. I also added some effects when you miss a pin so you can read it very easily as a miss and it's way over the top. Obviously.
If a player lands a pin each character has a unique effect that happens. Moscow Mule has something that looks like a hammer hitting hot steel. Grave Digger has one that looks like a lightning bolt strike.
I will be working on the character select screen this weekend some more on top of creating an intro screen, a start screen, a player lose screen where the winning player says a winning taunt and a continue screen with a countdown. If the losing player hits the trigger during the countdown it will start the character select screen. Currently I only have a simple rematch choice on a black screen for continuing. I am giving myself until Monday to have the game in an Alpha state. Playable from beginning to end and then I will have the game in Beta by next Sunday. I still have to work out music and sound effects which I really want to be awesome so we'll see how the heck I pull that off.
What Am I Doing?
Making the game has been a lot of fun and I have had several people tell me to try and sell it for at least $0.99 or something. That sounds great. Problem is I don't know how the hell to sell a game. This is going to be my biggest hurdle. How do I copyright the game? What kind of thing will this do to my taxes? Do I have to register an LLC? It's a lot to think about. I've been very careful to make sure I'm not using any assets or resources that may be under a freeware license that denies commercial use. My only concern about an asset right now is the text font. I got it from 1001 free fonts and I read it up and down and it said it's available for commercial use. I even tried to look for the author to contact but could't track down a contact. Anyway we'll see. Changing fonts is the lest of my concerns.
Friday, July 25, 2014
What Have I Been Up To?
Making Games
What have I been up to? That's a very good question voice from the void. Judging by my blog it would appear as though I've been doing nothing. I assure you I've been very busy. Since my transition into design I've focused mostly on that exactly. Design. But in my personal time I've actually begun work on a couple of games in Unity. These are my own personal endeavors and began originally as a reason to dig into Unity and C#. Just like everything I try to take on I dream way too big and refuse to quit. Every time I have an idea for a game I write it down no matter how absurd. Some of them have sounded pretty cool and others just ridiculous, ranging from "A game where you play as a kid who falls asleep at their desk and dreams of fighting creatures inside their desk on a quest to liberate the desk people from the oppressing Eraser of Existence." to "A cosmonaut that fights bears in space". You see what I mean.
1980 Something
One I began work on is title "1980 Something". You play as a cop in the 80's on a path of revenge. I really love 80's action movies like Cobra and Lethal Weapon and wanted to make a 2d game with side scrolling platforming and shooting and brawling. It's super ambitious but I'm doing my best to see it through. I've made some good progress thus far and have hit a few snags and limitations but I have some decent melee in the game already and some good platforming stuff. I'm not a great artist so it's tough to create the characters and what not but progress is being made and I look forward to showing something in the future.
Thumb Wars
About a week ago I started work on another smaller game that I'm just calling "Thumb Wars" right now. It's a 3d thumb wrestling game. Initial prototypes are pretty solid and a lot of fun. Two people use one controller to thumb wrestle and I have high hopes for creating different "Hands" to choose from as characters and any other ridiculous ideas I can come up with. I plan on updating my blog with progress on both of these games.
What have I been up to? That's a very good question voice from the void. Judging by my blog it would appear as though I've been doing nothing. I assure you I've been very busy. Since my transition into design I've focused mostly on that exactly. Design. But in my personal time I've actually begun work on a couple of games in Unity. These are my own personal endeavors and began originally as a reason to dig into Unity and C#. Just like everything I try to take on I dream way too big and refuse to quit. Every time I have an idea for a game I write it down no matter how absurd. Some of them have sounded pretty cool and others just ridiculous, ranging from "A game where you play as a kid who falls asleep at their desk and dreams of fighting creatures inside their desk on a quest to liberate the desk people from the oppressing Eraser of Existence." to "A cosmonaut that fights bears in space". You see what I mean.
1980 Something
One I began work on is title "1980 Something". You play as a cop in the 80's on a path of revenge. I really love 80's action movies like Cobra and Lethal Weapon and wanted to make a 2d game with side scrolling platforming and shooting and brawling. It's super ambitious but I'm doing my best to see it through. I've made some good progress thus far and have hit a few snags and limitations but I have some decent melee in the game already and some good platforming stuff. I'm not a great artist so it's tough to create the characters and what not but progress is being made and I look forward to showing something in the future.
Thumb Wars
About a week ago I started work on another smaller game that I'm just calling "Thumb Wars" right now. It's a 3d thumb wrestling game. Initial prototypes are pretty solid and a lot of fun. Two people use one controller to thumb wrestle and I have high hopes for creating different "Hands" to choose from as characters and any other ridiculous ideas I can come up with. I plan on updating my blog with progress on both of these games.
Thursday, April 10, 2014
Progression
During the development of The Last of Us I began to ask myself where I saw myself in the future. Did I have that hover board I so dearly wanted? Probably not. More specifically where did I see myself in my career. I love visual effects. Always have and always will. The problems I've had the opportunity to solve through visual effects have always proven equally complicated and exciting. I'm always trying to challenge myself. If I get too comfortable doing something then I need to push myself. If I'm scared then I know I'm on the right track. It's in the spirit of challenge that I began pursuing a shift in career direction. One that also felt like a natural progression. This is how I ended up here. Where is here? I'm being too cryptic. Plainly, here is the discipline of game design. I've always been fascinated with game design and the intricacies within. The problems to solve are vast and meticulous and require many many loops of iteration. On top of this it calls upon your collective experience in life and academics. The great thing is that each of us have unique experience to call from giving us our own special ways to pose problems and solve them. Game design is one of the most challenging and unique disciplines I've encountered and I'm very fortunate to work with some of the best game designers in the industry. This is something I have put a lot of effort and though into. After shipping The Last of Us I knew I wanted to make the shift if the opportunity were presented to me. This brings us to now. As of this post I am now working primarily in game design. I'm always a little unsure of myself but it's always been a motivational factor to prove to myself that I can do it. I look forward to creating interesting and exciting experiences for players and benefiting from the immense talent that resides in our design department. I wouldn't be where I am if it weren't for the people I look to for inspiration and support. It's because of these people that I've come this far. I'm also super freaking lucky to work in a studio that has provided me with the opportunity for such growth. My blog will naturally reflect my current work and interests and while visual effects is not my primary focus now it will always be one of my biggest interests.
I also want to mention that my wife has always been my biggest supporter and without her I'd be lost.
I also want to mention that my wife has always been my biggest supporter and without her I'd be lost.
Monday, November 4, 2013
Molotovs in The Last Of Us
Molotovs In The Last Of Us: Part I
One of the more interesting effects I worked on in this project were the Molotovs. In action it's just some fire effects and who hasn't see that before. What I find particularly interesting is what it took to bring it all together. There are many components to the Molotovs and while working on them I learned a ton about our scripting engine and how powerful it can be. But the point of this post isn't to talk up our scripting engine, rather to walk you through how we put it together in hopes of broadening your perception on what it takes to put something like this in the game.
Rootvars and Particler:
So, jumping right into it. Particler is our in house particle authoring tool. During production our dedicated fx programmer Marshall Robin added some new, really cool functionality to how we interact with our particles at runtime. Using a system referred to as rootvars, we were able to create variables in our expressions during the authoring stage that we could set the value for at runtime and update as well.
Using these I was able to make a single effect and manipulate attributes of the effect based on conditions I set in script. An example is demonstrated in the video below. The player can obtain upgrades by reading manuals that will increase the effectiveness of Molotovs the player creates. For instance the damage radius is increased with each upgrade. Rather than create an entirely new effect based on the upgrade, I've passed the upgrade level as an int and, based on that number, at creation I set conditions so I can set values in my single effect to represent the upgrade like sprite size and emitter radius among other visual aspects.
One of the more interesting effects I worked on in this project were the Molotovs. In action it's just some fire effects and who hasn't see that before. What I find particularly interesting is what it took to bring it all together. There are many components to the Molotovs and while working on them I learned a ton about our scripting engine and how powerful it can be. But the point of this post isn't to talk up our scripting engine, rather to walk you through how we put it together in hopes of broadening your perception on what it takes to put something like this in the game.
Rootvars and Particler:
So, jumping right into it. Particler is our in house particle authoring tool. During production our dedicated fx programmer Marshall Robin added some new, really cool functionality to how we interact with our particles at runtime. Using a system referred to as rootvars, we were able to create variables in our expressions during the authoring stage that we could set the value for at runtime and update as well.
the rootvar __root.alpha here is being used as a float to modulate the opacity value of the particles
Using these I was able to make a single effect and manipulate attributes of the effect based on conditions I set in script. An example is demonstrated in the video below. The player can obtain upgrades by reading manuals that will increase the effectiveness of Molotovs the player creates. For instance the damage radius is increased with each upgrade. Rather than create an entirely new effect based on the upgrade, I've passed the upgrade level as an int and, based on that number, at creation I set conditions so I can set values in my single effect to represent the upgrade like sprite size and emitter radius among other visual aspects.
The concept for the Molotov and its need for flexibility:
The easy way for the Molotov to work would have been the old method. In a specific file, we can define what effects to spawn specific to certain weapon types and explosions. This is an oversimplification of how that all works. For example, in this specific file there would be some definition for the general gameplay behavior of the Molotov and in this location there would be a space where we can define what single particle effect we would like to play when the Molotov explosion is triggered in gameplay. Molotov goes boom, spawn some effect. The simple way to create the Molotov would have been to simply say spawn my Molotov effect when this explosion happens. The Molotov however needed to be flexible. For instance after watching a lot of reference I noticed that the way it spawns differs greatly depending on the angle of the surface it explodes on. So we had four possible explosions that could be defined. One for the floor, one for walls, one for ceilings, and one for impacting characters directly.
Floor Impact Molotov
Ceiling Impact Molotov
Direct Hit on Enemy Impact Molotov
The fiery bits spit out by a Molotov would need to react based on the angle of the surface it impacted and take into account other information and conditions. On top of this the player would be able to upgrade the Molotov damage radius so the effects would have to reflect these upgrades. This all would have meant we would need to author a new effect for every upgrade possible for all four effects if we stuck with the traditional method. So I went with a more technical setup but far more flexible.
State Scripts:
State scripts are built using our internal scripting language. The syntax is based on lisp. You can think of it like Unreal Script and LUA. A state script is very flexible and can be used for a number of tasks, ranging from controlling how objects behave when attacked to setting up logic for combat. I had used state scripts loosely on Uncharted 3 and had continued to become familiar with them as I saw a lot of potential for setting up effects using them. We also have a large number of user and programmer created functions that support them. When spawning an effect in particler we can send collision events that carry information that can be used by state scripts. So I'll detail the information I used to interpret the behavior for Molotovs.
State Script Example
Collision events and the state scripts for Molotovs:
So the most flexible way I could think to setup the Molotovs was to instead have a state script spawned in place of a particle effect and that state script would spawn the particle effect and control all the aspects of its behavior. So this is how It all went down.
- Lead Programmer Travis Mcintosh setup the lower level code to spawn the state script and pass the script a world space position and a quat that I could use when spawning the effects. He also sent an event to the script so that I could have all the variables setup before spawning the effects. This created a one frame delay but you don't really notice it.
- I created an effect for each of the 4 types of Molotov bursts that contained fiery particles that fly out and collide with surfaces. Each time a particle collides with some geo it sends out a collision event.
- The script listens for these events and using the information contained within the event sets up some conditions to further control how the Molotov behaves.
- All 4 effects spawn the same effects when they collide with geo but each script determines how those parts behave differently.
- There are 3 parts that result from the collision of the Molotovs components. The small fire bits. The large fire bits. And the smoke, light, and scorch all in one effect.
- Using functions inside our scripting language I was able to check for the level upgrade set on the player at the time the Molotov script spawns.
- I set rootvars for scale and rate along with the speed at which components flew away from the center of the Molotov.
- Additionally I check the y component of the normal that the collision takes place at. If the value is greater than 0.8 I don't spawn the normal fire bit and instead spawn another effect to creates some simple spreading. This spreading is purely a visual thing and does not contribute to gameplay but it was a nice touch.
- I also check the surface type of the collision. If it's water I don't spawn the fire. If it's deep snow I spawn a different scorch mark entirely. So it would look like the snow was melting.
Here is a quick run through of the Molotov being used in gameplay. I have character invincibility on and I also have some infinite ammo set so I can just demonstrate how all of this looks in execution.
Gameplay Demonstration: Molotov
Conclusion:
The Molotov was a huge learning experience for me and allowed to explore all of my options for implementation. In retrospect there are some things I wish I could have done early on knowing what I know now. As with all things, I learned a lot about our scripting engine and continue to use it to implement some crazy effects. There is no greater feeling than setting up a bunch of conditions and then watching it all work and happen right in front of you. Seeing people lob these bad boys at each other and just imagining all the crazy crap going on under the hood, it's great. In part 2, I'll go over how I used some of the same techniques to control how fire spreads in infected as they walk through fire elements of the Molotov.
Friday, August 16, 2013
VFX of The Last of Us: Lakeside
SPOILERS
This post will reveal game footage and details that will spoil the game if you haven't played it.
Winter
The winter section of the game we referred to as "Lakeside". The level posed some familiar challenges for snow based effects and some new ones. This snow had to feel hold and packed with fresh snow coming in and we also needed to reflect some changing weather patters as the level progressed. We wanted to reflect some old snow with the sun peeking through the clouds and hitting the surface. Giving off some warmth. Moving into an on coming storm and in the end a full fledged blizzard with low visibility. I spent a great deal of time on just the footprints which I detailed in a previous post so I won't elaborate on that here. Check out the video below to see some of the effects in action
Warm Calm
In the beginning of the level I wanted to convey a lot of random wind patterns as the wind moves throughout the trees and wooded area. I created some random gusts of loose snow clouds that get kicked up and flurries that blow out from small bushes. This helped to create a sense of movement while not being too heavy handed. I also created some loose snow effect that fall from branches as you move through the forest. One of the biggest issues for this area was due to the fact that once you shot the deer it would leave blood trails so you could track it. Each blood drop was ticking away at our particle memory in a significant way and at times players could use up all of the memory and the blood would stop spawning. There was no fancy trick for fixing this issue I simply had to scale back the number of effects being spawned and make the blood less frequent and larger. You might be asking yourself "Why is that deer bleeding so much?", well that's why.
This post will reveal game footage and details that will spoil the game if you haven't played it.
Winter
The winter section of the game we referred to as "Lakeside". The level posed some familiar challenges for snow based effects and some new ones. This snow had to feel hold and packed with fresh snow coming in and we also needed to reflect some changing weather patters as the level progressed. We wanted to reflect some old snow with the sun peeking through the clouds and hitting the surface. Giving off some warmth. Moving into an on coming storm and in the end a full fledged blizzard with low visibility. I spent a great deal of time on just the footprints which I detailed in a previous post so I won't elaborate on that here. Check out the video below to see some of the effects in action
In the beginning of the level I wanted to convey a lot of random wind patterns as the wind moves throughout the trees and wooded area. I created some random gusts of loose snow clouds that get kicked up and flurries that blow out from small bushes. This helped to create a sense of movement while not being too heavy handed. I also created some loose snow effect that fall from branches as you move through the forest. One of the biggest issues for this area was due to the fact that once you shot the deer it would leave blood trails so you could track it. Each blood drop was ticking away at our particle memory in a significant way and at times players could use up all of the memory and the blood would stop spawning. There was no fancy trick for fixing this issue I simply had to scale back the number of effects being spawned and make the blood less frequent and larger. You might be asking yourself "Why is that deer bleeding so much?", well that's why.
Storm Chasing
For the white out blizzard I had some fun with implementation here. The biggest issue was that we needed reduced visibility and using particle for this is always a bad idea because of overdraw issues. Rather than placing a bazillion emitters and only placed a few in key places and instead attached an emitter to the player camera with the emitter oriented in world space. The emitter will update it's position with the camera but will not rotate with it. I setup a state script (ref to our internal scripting engine) that would control the whole camera parented effect. The reason for ding this was because you obviously don't want the emitter on while you are indoors. So I setup regions for the interiors and when the player walks into them I send events to the script and the script lerps values on the effect up and down respectively. this utilized some new tech we got from our dedicated effect programmer Marshall Robin. He exposed to us root data on our particle systems and in script we can set those values as long as we retain a handle to the effect in our script. Pretty cool. The issue was still that some of the larger gusts of cloud particles would still draw indoors. The solution for this wasn't perfect but worked well enough. For the shader I utilized a buffer we use for occluding rain so that rain doesn't draw indoors and under hanging objects that write to that buffer. I modulated the world space position of each pixel by this buffer which is also in world space and this prevented those pixel from drawing inside. It created a harsh edge so I had to do 4 taps to make a super super super cheap blur. Calling it a bur is almost offensive to blurring pixels because my samples are so low but the shader was getting too expensive so I tried to offset this restriction by adding some distortion to the edge as well. Again, it's not perfect but works well enough.
The Roof Is On Fire
This was another area where I employed some heavy scripting for the effects. Once David comes in and knocks over the candles this resulted in a small fire spreading. In script I set this up in stages that way the fire wouldn't progress to the next stage until the player had stabbed David once and so on. I juggled the particle effects, spawning sounds, lights, material blending, and animated curtains as they burned as well. On top of this I also kept track of where the player stabbed David. On easy you can throw a brick at David and while he is stunned stab in from the front. I spawned blood effects on his clothes based on where he was stabbed so if for some reason you turned off the PS3 while in the middle of the fight and picked it up in the second stage he would still have blood where you last stabbed him. I don't think anyone will notice that. All sorts of fun keeping track of these variables and every time you think you have accounted for all of them you've undone something else. Honestly thought I really enjoy this aspect of things. I'm not sure why but it just feels that much more gratifying when you solve it but equally as stressful when you're getting close to ship and people are still finding bugs in your code.
Conclusion
So this level was a roller coaster down to the wire. This camera parented emitter thing, while saving me time in propagation, cost some some nights while I scripted its behavior. This level also taught me to let go. To not attach myself to certain aspects of what I'm trying to achieve at the cost of shipping something half finished or buggy. I also learned not to try to script one thing that could control a lot of things. Smaller script for specific goals is easier to manage and easier for others to parse when you need help.
Tuesday, July 30, 2013
VFX of The Last of Us: Bills Town
Subtlety
This is a difficult thing to convey when working with visual effects. You want to create some movement and visible interest but it also needs to feel appropriate given the context of the environment. In The Last of Us this was particularly difficult because the weather wasn't always in some extreme state. For the most part things needed to feel calm and peaceful while being juxtaposed with horrific realities happening around you. I think it's because of this setting and tone that fools you into thinking you're safe but you know better. This brings me to Lincoln or as we referred to it, Bills Town.
Life Goes On
In Bill's Town there's only Bill, and of course the infected wandering around. No electricity, no human life. This was a constant theme throughout the game and it required us to explore other ways to create movement and life. We did this though things that weren't as obvious as animals and things of that nature. We used small swarms of flies and gnats that you end up walking through, grasshoppers that jump back and forth and loose pieces of paper trash that fly around in the wind to name a few. I personally had to really think about how to create the movement without it being intrusive or out of place. I borrowed a technique from one of our lead effects artist Eben Cook where I would take a still from the level with no effects in it yet and do some paint overs to try to imagine what effects would look good in areas. This helped a ton to see what worked and what didn't. I wanted to describe this because I think it's important to explain that visual effects in a game are not something that just get plopped down without any forethought. There are some effects that you have on hand and you know they will work well in many areas but before we lay them down we put a deal of thought into how it all fits together. This game was a great practice in restraint as well. An effects artist we could put any number of things into a scene to convey movement and so forth but you also need to be able to look at something and say "It only needs this one thing." and be alright with that. Just because we can doesn't mean we should.
Wind Effects
We have a wind system in the game that controls how things like trees and other geo behave to simulate the appearance of wind. In previous games we have created effects that best match what this looks like to us, but we were always just eyeballing it. We had to orient our emitters in the direction of what we perceived the wind to be and while this was fine it could be a little slow at times and they didn't always remain consistent. In this game we decided to ask for the ability to fetch the wind direction and strength from our global wind system so that we could use those values to control some of the behavior in our effects. I created a simple script that grabbed the wind direction and intensity and passed it to one of our global wind fields we exported from Maya. This allowed us to put things like leaves falling from trees and any other particles we wanted to have flowing in the wind wherever we wanted without having to worry about emitter orientation. So in Bills town I created a number of effects to take advantage of this, like grass and dusty dirt that gets kicked up randomly.
I created the video below to demonstrate some of these concepts at play. Ranging from subtle wind effects to in you face decapitation effects for the infected. There are spoilers so be warned if you haven't played the game yet.
Tuesday, July 9, 2013
Deep Snow Prints
Spoiler Warning!!!!!!!!!!!!!!!!!!
Be aware that the video below shows some footage that would be a spoiler for someone who hasn't played the game yet. I apologize for that.
Splash!
Long ago in the before time we didn't have a way to artistically control the footprints characters could leave on surfaces. The footprints in Uncharted 2 were smaller in scope and artists were limited in what they could do with them. Since then we have had some considerable support in a system that allows us to spawn effects based on collision data from objects in the game. Using joints in the game we can cast rays from joints that probe surfaces and use that information to test some conditions to spawn effects once those conditions are satisfied. We call this system the Splasher System. Originally it was just for creating splash effects for characters in water but it's a lot more intricate now. The splashers are something I'd like to go into more detail on at a later point if I'm allowed to. It's a great system but on the PS3 it became quite expensive and we had to scale back how many characters and objects used this system.
Projected Particles
One of the greatest things we have is the ability to project materials onto objects using our particle systems to generate the projections. This sounds like a decal system and in it's most basic description, it is. Our Dedicated effects programmer Marshall Robin, during uncharted 3 developed for us the ability to spawn projected particle cubes that utilize a number of parameters to project materials that we author onto surfaces. For example we can use this system to write directly to our destination normal buffer. This buffer takes the normal value of every pixel in screen space and writes to this buffer. Out projected particles directly perturb this buffer. Our lead effects artist Keith Guerrette, used this technique when creating the sand footprints in Uncharted 3. They can animate and do all sorts of great stuff. We can also draw these projected particles to the same buffers we draw all of our other particles to. So we can draw projected color based materials onto surfaces which is very much like the decals you are used to seeing. There is a lot of overdraw cost in these projected cubes so we don't like to use them all over the place just where it will have the greatest impact visually and where surfaces tend to have a lot of deformation. In the video I put together you'll see the outline of some cubes and those are the projected particles.
The Materials
We are lucky enough to have our own node based shader authoring tool. If you've ever used UDK's material editor it's a lot like that. Knowing we can only project a flag image onto the surface I used a technique that in UDK is referred to as bump offsetting. The idea is that you can use the camera direction to bias your original uv values modulated by some constants to create the illusion of parallax. The camera direction vector is a unit vector that ranges from -1 to 1. This is ideal because uv coordinates are commonly in tangent space which typically range from -1 to 1 as well. Of course you can push the values to whatever ranges you want but you would soon find the problem with that. The camera direction is a vec3 and I really only need 2 of the components from the camera direction. The x component and the y component. So I separate all three and recombine x and y back into another vector that is only x and y.
Using these vectors I multiplied them by a texture of a deep simple impression I made in Maya. The texture is the equivalent of a displacement map. By multiplying the camera direction vectors by the texture I create a more complicated and interesting shape of parallax per pixel. Now, what to use these crazy uv's on? I used the displacement map texture to create the illusion of shadowing inside the pit of the print. One of the unique things about our shader authoring tool is that we can define how our alpha is applied. This is similar to Photoshop layer stylings. You know things like multiplicative and additive and so on. The difference being that our options don't have those kinds of presets so we need to know how that alpha blending works. The simple version of what we have to work with is the source pixel (the pixel we are trying to draw) and the destination pixel (the pixel that is already there). Then we define some arithmetic on each of those alpha blending attributes and then by default the result of those two get added together. The majority of our materials multiply the source pixel by 1 so the alpha we are trying to draw just remains as is and then we multiply the destination pixel by one minus the source alpha. So the inverse of our alpha we are drawing. I didn't want to try to create any color of the footprints beyond what was already being drawn there. So the only color in my material is the shadow for the deeper parts of the print to make it look darker. For the alpha blending I set my source alpha to be multiplied by the destination pixels color. So now my alpha has within it the color value of the pixel that is already there. Then my destination alpha is multiplied by 1 minus the source alpha. Since my source alpha has within it the color of the destination pixel I don't want twice the color value when the two values are added together. That's a little complicated I know but totally worth it.
In Conclusion
There are some other things I did to create the prints but the bulk is being done in that one material with the fake parallax. The video will quickly demonstrate how the material is being modulated by a float to control how deep the parallax goes. These prints were important because we couldn't create any dynamic displacement of the geo and the player needed to have something to clearly track the deer. I'm proud of how these prints turned out. We tried to create prints like this for Ellie and I spent a good deal of time on them but it was difficult to make it look like she was leaving long trails and tracks in the snow. So I opted for the prints that write to the destination normal buffer to make it look like long streaks in the snow. Anyway, enjoy the video.
Be aware that the video below shows some footage that would be a spoiler for someone who hasn't played the game yet. I apologize for that.
Splash!
Long ago in the before time we didn't have a way to artistically control the footprints characters could leave on surfaces. The footprints in Uncharted 2 were smaller in scope and artists were limited in what they could do with them. Since then we have had some considerable support in a system that allows us to spawn effects based on collision data from objects in the game. Using joints in the game we can cast rays from joints that probe surfaces and use that information to test some conditions to spawn effects once those conditions are satisfied. We call this system the Splasher System. Originally it was just for creating splash effects for characters in water but it's a lot more intricate now. The splashers are something I'd like to go into more detail on at a later point if I'm allowed to. It's a great system but on the PS3 it became quite expensive and we had to scale back how many characters and objects used this system.
Projected Particles
One of the greatest things we have is the ability to project materials onto objects using our particle systems to generate the projections. This sounds like a decal system and in it's most basic description, it is. Our Dedicated effects programmer Marshall Robin, during uncharted 3 developed for us the ability to spawn projected particle cubes that utilize a number of parameters to project materials that we author onto surfaces. For example we can use this system to write directly to our destination normal buffer. This buffer takes the normal value of every pixel in screen space and writes to this buffer. Out projected particles directly perturb this buffer. Our lead effects artist Keith Guerrette, used this technique when creating the sand footprints in Uncharted 3. They can animate and do all sorts of great stuff. We can also draw these projected particles to the same buffers we draw all of our other particles to. So we can draw projected color based materials onto surfaces which is very much like the decals you are used to seeing. There is a lot of overdraw cost in these projected cubes so we don't like to use them all over the place just where it will have the greatest impact visually and where surfaces tend to have a lot of deformation. In the video I put together you'll see the outline of some cubes and those are the projected particles.
The Materials
We are lucky enough to have our own node based shader authoring tool. If you've ever used UDK's material editor it's a lot like that. Knowing we can only project a flag image onto the surface I used a technique that in UDK is referred to as bump offsetting. The idea is that you can use the camera direction to bias your original uv values modulated by some constants to create the illusion of parallax. The camera direction vector is a unit vector that ranges from -1 to 1. This is ideal because uv coordinates are commonly in tangent space which typically range from -1 to 1 as well. Of course you can push the values to whatever ranges you want but you would soon find the problem with that. The camera direction is a vec3 and I really only need 2 of the components from the camera direction. The x component and the y component. So I separate all three and recombine x and y back into another vector that is only x and y.
Using these vectors I multiplied them by a texture of a deep simple impression I made in Maya. The texture is the equivalent of a displacement map. By multiplying the camera direction vectors by the texture I create a more complicated and interesting shape of parallax per pixel. Now, what to use these crazy uv's on? I used the displacement map texture to create the illusion of shadowing inside the pit of the print. One of the unique things about our shader authoring tool is that we can define how our alpha is applied. This is similar to Photoshop layer stylings. You know things like multiplicative and additive and so on. The difference being that our options don't have those kinds of presets so we need to know how that alpha blending works. The simple version of what we have to work with is the source pixel (the pixel we are trying to draw) and the destination pixel (the pixel that is already there). Then we define some arithmetic on each of those alpha blending attributes and then by default the result of those two get added together. The majority of our materials multiply the source pixel by 1 so the alpha we are trying to draw just remains as is and then we multiply the destination pixel by one minus the source alpha. So the inverse of our alpha we are drawing. I didn't want to try to create any color of the footprints beyond what was already being drawn there. So the only color in my material is the shadow for the deeper parts of the print to make it look darker. For the alpha blending I set my source alpha to be multiplied by the destination pixels color. So now my alpha has within it the color value of the pixel that is already there. Then my destination alpha is multiplied by 1 minus the source alpha. Since my source alpha has within it the color of the destination pixel I don't want twice the color value when the two values are added together. That's a little complicated I know but totally worth it.
In Conclusion
There are some other things I did to create the prints but the bulk is being done in that one material with the fake parallax. The video will quickly demonstrate how the material is being modulated by a float to control how deep the parallax goes. These prints were important because we couldn't create any dynamic displacement of the geo and the player needed to have something to clearly track the deer. I'm proud of how these prints turned out. We tried to create prints like this for Ellie and I spent a good deal of time on them but it was difficult to make it look like she was leaving long trails and tracks in the snow. So I opted for the prints that write to the destination normal buffer to make it look like long streaks in the snow. Anyway, enjoy the video.
Saturday, June 29, 2013
Cockroaches in The Last of Us
Spoiler Free I promise
(Unless you count the roaches as a spoiler)
These little guys might go unnoticed in the game but I am particularly proud of them. This was a tag team effort between Eben Cook and I. With a shout out to Nick Lance and Kurt Margenau a couple of awesome designers I work with. Sometimes our effects team might conceptualize an idea but we don't always have the means to create what we want as it requires support from programmers and it's hard to justify pulling a programmer on to something that most likely is not worth their time. I had been exploring our scripting engine in more depth since the end of Uncharted 3 where I had begun using it quite extensively. It's a very flexible scripting engine similar to Unreal Script and LUA based on LISP. I like it. Let me just put that out there. I love things like this because it allows me to think in ways I may not have before. I always like when there is this complex problem to solve and when I come up with a solution I like to admire it's intricacy. Our dedicated effects programmer Marshall Robin, shortly after Uncharted 3, had given us the ability to declare variables in the root data of our particle systems. These variables could be used in our expression when authoring our effects and we could set the values of these variables at runtime. What all this means is we could change the way our particles behaved on the fly. Muahaha. So with all of this in mind Eben and I thought "You know we could totally make some cockroaches that scurry away in some fashion." So Eben setup the cockroaches. They are aligned with their velocity and while they are not being affected by anything they are just randomly moving about based on some expressions Eben setup in the effect. This is where the root data variables (Rootvars as we refer to them) come into play. We basically have this boolean value in the expression that while set to 0 will have them acting normally just moving about and then when it gets flipped to 1 it triggers a condition in the expression to make them scurry in a direction along the z axis of the particle spawner. We simply add some spawners using our level propagation tool and face their z axes in the direction we want them to scurry in.
The next stage is where I had some fun. So I have all the pieces of the puzzle in front of me. I have a set of functions our designers use for other gameplay purposes but I know they will be what I need to get these roaches working. Additionally I didn't want the script I made to be something we could only use once. I wanted it to be something that any other effects artist could just throw into a level and it would do all the work. To do this I needed to be able to let the artist specify the name of the spawners in the level to perform operations on and I had to allow for any number of spawners. I did set a limit of 100 spawners in the script but if we ever had that many in a level it would be insane. I think the most we ever got up to was 8 or 10. The script spawner allows for a user to specify data directly on the spawner in our propagation tool. So the artist just enters the names of all the spawners for the roaches on the script spawner. For the artist that's it. That's all they have to do. The script itself contains two sections. The first creates a symbol array that we refer to as a group. So the script checks the data on the spawner I mentioned and if that data is specified it adds that roach spawner symbol name to the group. The function that does most of the work here is basically a while loop with a counter. The next section is where the real work is being done. Now that I have a group of symbols I use some functions to create some conditions for the script to check on those symbols every frame. I check the distance between the player and the roach spawner. I check to see if the roach spawner is within a specified radius from the center of the screen. and I check to see if the flashlight state is on. If all three conditions are satisfied it sets the boolean switch (Rootvar) on the roach spawner that has met all of the conditions to 1 and the roaches go scurrying away. The first time I saw it working I pooped a little.
So that's how all that works. It might sound expensive but it was all actually relatively cheap to run because it wasn't all that complex on the runtime side. Of course the more spawners we iterate over the more expensive it would become but it never got to that point and we were always mindful of that. The reason why I loved this whole setup so much was because of what it represents. It represents how flexible our tools have become to allow us to fully realize an effect without having to request any tool support. All the pieces to solve the puzzle and many others like it are at our disposal. While the end result is just some roaches, the concepts we learned and put into practice here have larger applications across other areas when creating effects and completing effects related tasks. This level of creative problem solving takes shape when the tools expose more access to the inner workings of the effects to the artist. I will say that we are super freaking lucky to have the support we do because if it weren't for Marshall exposing the root data to us we couldn't do this and a lot of other things. Also big thanks to Kurt and Nick for showing me cleaner and smarter ways to write the code for the scripts.
(Unless you count the roaches as a spoiler)
These little guys might go unnoticed in the game but I am particularly proud of them. This was a tag team effort between Eben Cook and I. With a shout out to Nick Lance and Kurt Margenau a couple of awesome designers I work with. Sometimes our effects team might conceptualize an idea but we don't always have the means to create what we want as it requires support from programmers and it's hard to justify pulling a programmer on to something that most likely is not worth their time. I had been exploring our scripting engine in more depth since the end of Uncharted 3 where I had begun using it quite extensively. It's a very flexible scripting engine similar to Unreal Script and LUA based on LISP. I like it. Let me just put that out there. I love things like this because it allows me to think in ways I may not have before. I always like when there is this complex problem to solve and when I come up with a solution I like to admire it's intricacy. Our dedicated effects programmer Marshall Robin, shortly after Uncharted 3, had given us the ability to declare variables in the root data of our particle systems. These variables could be used in our expression when authoring our effects and we could set the values of these variables at runtime. What all this means is we could change the way our particles behaved on the fly. Muahaha. So with all of this in mind Eben and I thought "You know we could totally make some cockroaches that scurry away in some fashion." So Eben setup the cockroaches. They are aligned with their velocity and while they are not being affected by anything they are just randomly moving about based on some expressions Eben setup in the effect. This is where the root data variables (Rootvars as we refer to them) come into play. We basically have this boolean value in the expression that while set to 0 will have them acting normally just moving about and then when it gets flipped to 1 it triggers a condition in the expression to make them scurry in a direction along the z axis of the particle spawner. We simply add some spawners using our level propagation tool and face their z axes in the direction we want them to scurry in.
The next stage is where I had some fun. So I have all the pieces of the puzzle in front of me. I have a set of functions our designers use for other gameplay purposes but I know they will be what I need to get these roaches working. Additionally I didn't want the script I made to be something we could only use once. I wanted it to be something that any other effects artist could just throw into a level and it would do all the work. To do this I needed to be able to let the artist specify the name of the spawners in the level to perform operations on and I had to allow for any number of spawners. I did set a limit of 100 spawners in the script but if we ever had that many in a level it would be insane. I think the most we ever got up to was 8 or 10. The script spawner allows for a user to specify data directly on the spawner in our propagation tool. So the artist just enters the names of all the spawners for the roaches on the script spawner. For the artist that's it. That's all they have to do. The script itself contains two sections. The first creates a symbol array that we refer to as a group. So the script checks the data on the spawner I mentioned and if that data is specified it adds that roach spawner symbol name to the group. The function that does most of the work here is basically a while loop with a counter. The next section is where the real work is being done. Now that I have a group of symbols I use some functions to create some conditions for the script to check on those symbols every frame. I check the distance between the player and the roach spawner. I check to see if the roach spawner is within a specified radius from the center of the screen. and I check to see if the flashlight state is on. If all three conditions are satisfied it sets the boolean switch (Rootvar) on the roach spawner that has met all of the conditions to 1 and the roaches go scurrying away. The first time I saw it working I pooped a little.
So that's how all that works. It might sound expensive but it was all actually relatively cheap to run because it wasn't all that complex on the runtime side. Of course the more spawners we iterate over the more expensive it would become but it never got to that point and we were always mindful of that. The reason why I loved this whole setup so much was because of what it represents. It represents how flexible our tools have become to allow us to fully realize an effect without having to request any tool support. All the pieces to solve the puzzle and many others like it are at our disposal. While the end result is just some roaches, the concepts we learned and put into practice here have larger applications across other areas when creating effects and completing effects related tasks. This level of creative problem solving takes shape when the tools expose more access to the inner workings of the effects to the artist. I will say that we are super freaking lucky to have the support we do because if it weren't for Marshall exposing the root data to us we couldn't do this and a lot of other things. Also big thanks to Kurt and Nick for showing me cleaner and smarter ways to write the code for the scripts.
Wednesday, June 26, 2013
Visual Effects in The Last of Us: Hometown
VFX TLoU
Spoiler alert!!!!!
The visual effects in The Last of Us consisted of a wide variety of things ranging from subtle ambient wind effects and insects to in your face molotov explosions. Each artist typically will own a handful of levels and will be responsible for creating the effects needed for that level. Additionally we have to create gamewide effects such as weapon effects and melee effects based on animations that happen all over the game. So just like I did with Uncharted 3 when we finished I'm making some videos and posts detailing what we worked on in the levels we were responsible for but I will also be going more in depth in later posts on some gamewide things that I thought were interesting struggles and the solutions we came up with to make it all work. I really want to shed some light on how we go about creating the effects we do and talk up my teammates because they are amazing. So in short I'm going to be creating a series of videos I'm just gonna call "The Visual Effects of The Last of Us".
Hometown
Originally when I was told how this level would play out I thought "That's cool I can handle this.". Wrong. But I'm super lucky to have the people I do to work with. Keith Guerrette really stepped up and helped to get this level done. The effects in this level were much more chaotic compared to other areas of the game. This is where the "Uncharted" in me went wild with explosions and sparking wires. I know a downed power line wouldn't spark like that but just go with it.
Joel's House
The first thing I worked on was the burning house on the side of the road and the barn. I used this area to prototype the fires I would use in other areas of the level. I used a lot of those concepts I worked out there for the burning buildings in the town. From there I created the explosions seen upstairs in Joel's room and the fire effects in the video with the reporter on screen. It's funny because I spent a good amount of time on that even though I knew it was going to end up on a small screen in the game. It's also worth pointing out that one of our rendering programmers Ke Xu worked out a way to increase the resolution of the runtime reflections without increasing the cost to render them. So the smaller the object with a reflective material the higher the resolution of the reflection. I constantly would joke with him saying "Reddit will love you for this." Keith stepped up to handle all of the other effects for the downstairs area of Joel's house and the effects for the drive into town. He also made the lens flares for the tops of the cop cars which was really cool. I used those lens flares on the helicopters flying around. We worked together to create some scripts to control the dirt kicked up by the car as it drives so that when the car would brake the smoke would look like it was being lit by the tail lights of the car.
In Town
With Keith's help on the other areas I was able to focus on the chaos going on in the town. It starts with their car being hit by a truck and I must have changed those glass particles like 30 times. The final result came out good though. I created a script to handle all of the events in the town that needed effects. For example the glass as Joel kicks it to each new horrible thing that happens as you move through the town. The gas station explosion had some amazing concept art to go on and I made a material that I thought worked fairly well for gas that shoots out during an explosion and then that gas ignites in mid air. This all happens really fast but it created a nice result. As you approach the end of the street near the theater there's a car that goes rolling by on fire and then explodes. I have the car leaving a trail of gas fire behind it as it rolls but like a lot of things in the level you can't take your time and look around less ye be attacked. As you run out the back of the bar I made some lingering dirt dust where the ambulance went off the road. These kinds of effects are subtle but add a lot of atmosphere to the environment.
The Sad Ending
When we work on cutscenes we have to watch them over and over again typically frame by frame. We don't hear any dialogue or anything but after enough viewings and having seen the mocap from the stage capture you know whats going on. I worked on the typical stuff like blood when the soldier is shot in the head by Tommy and dust as Joel rolls down the hill and scrambles towards Sarah. One of the interesting things I was able to work on was the tears on the characters. I created a hacked together kind of tool that allowed our animators to animate tears running down characters faces and we also used it to apply bloody hand prints from Sarah onto Joel's shirts where she grabs him on the shoulders. This cutscene is very emotional and the tears did a good job conveying that sadness. I'm glad we spent the time on that. Of course The scene wouldn't be what it is without Troy Baker and Hana Hayes. They did such an amazing job portraying those characters. I'll be adding more posts in the coming weeks.
Friday, June 14, 2013
The Last of Us Is Out!
The day has finally arrived. The game is out and we had an amazing turn out at the midnight releases. I will be updating this area with things I worked on in the game and other game vfx related stuff. If you haven't picked up a copy yet I highly recommend it. Not because I am personally invested in it but because I enjoy the shit out of good games and this is a great one. In the meantime checkout the trailer for the making of the game. The making of video is really awesome.
Monday, December 10, 2012
Last of Us Story Trailer
Sticking with the tradition of me only posting what I can when I have time to, here is the latest trailer we have released for the game. We worked on the trailer while simultaneously working on the game obviously. This essentially meant we didn't want to create anything for the trailer that wasn't in the game. You also want to make sure everything that goes into the trailer is as polished as can be. This is good because if you finished for the trailer you finished for the game. Burt being the perfectionists that we are I can personally say I will continue to polish until my eyes bleed. Enjoy!
Wednesday, September 5, 2012
Last of Us Extended Gameplay Demo
This is a video from PAX which was also the behind closed doors theater demo at E3 for our current project The Last of Us. We worked hard to get all sorts of minutia in the details. Things like the molotov and how it functions, blood fx on the characters faces and how blood hits the environment, ambient fx like dust and falling leaves that float on the water as they impact it, weapon fx, and even dust that is kicked up by enemies when they shuffle their feet during combat. There are numerous things that our team additionally crafted that I can't wait for people to see and experience. Enjoy the video.
Monday, July 30, 2012
Infected Munny
This weekend I decided to finally start on my infected munny inspired by The Last of Us. I'd created a Joel and Ellie munny previously and was relatively happy with the result. This one I knew would require a little more detail and I wanted to try a couple new techniques. On my previous toys I made the mistake of using a paint marker for some details and it never really dries. This time I attempted to add all of my detail with my finer brushes. It only got difficult in a couple of areas but overall I liked it much better. I used sculpey for the jaw, face fungus, arms and the few protrusions on the torso. I also messed around with some gradation on the clothing. On my next one I'm sure it will be better but I am pretty happy with how this one turned out. I also used some sea sponges for the fungus areas. It gave it a really nice texture. Below are a few progress images. I should have taken more but ah well. Next time.
Monday, July 23, 2012
Siggraph: Real Time Live
Iki Ikram and I will be presenting some of the real time visual effects work created in Uncharted 3. The real time live event consists of short 7-8 minute presentations in real time.This could be anything from video games to medical tools that allow someone to examine a 3 dimensional x-ray taken of a patient. They only need be presented in real time. While the presentation will be short, Iki and I will demonstrate and explain some techniques that were used to create real time visual effect elements in the game. While we won't go into great detail, there will be some cool examples of our techniques. If you're going to Siggraph this year check out the Real Time Live presentations on August 8th at 5:30pm. There's going to be some really awesome stuff demonstrated as well. Star Wars 1313 and The elemental Hero for the Unreal Engine 4 Showcase.
Tuesday, June 5, 2012
E3 Sony Press Conference
During the E3 Sony press conference, Bruce Straley demonstrated some gameplay from our new project "The Last of Us". I'm super proud of how well it turned out. Everyone worked really hard to get everything in place for the demo. From molotov effects to blood effects and ambient effects to bring the world to life. Big shout out to Mike and Eben. Late nights. Very worth it. Oh and to Bruce, looking really freaking epic playing the game on stage. Like a boss.
Tuesday, May 15, 2012
The Ambush
New trailer just released for The Last of Us. Eben and Mike did an awesome job on this cutscene and I added a couple small things in there. Enjoy
Thursday, March 15, 2012
Math:Dot Product
Once I got into fx for games I found myself using a ton more math when creating shaders for our particle effects. This gave me a renewed love for all things mathematical as well as a practical application for mathematics I've learned over the course of time. It also gave me a reason to expand on that knowledge and push it further to allow me to create better shaders. It's incredibly rewarding. That said, I've decided to make some videos demonstrating some general and not so general mathematics used in creating shaders. The principles and operations are not limited to an engine as the math behind how the shaders work is universal. Such is math. I will preface this first video by saying I am not that great of an instructor and I sometimes find it difficult coming up with the right examples to explain things. Because of this I have asked Eben Cook to preview my work and make sure it's understandable and correct. I have jumped into the deep end here with the first video by explaining the "dot product" of two vectors. If it's a little too advanced then don't worry I'll be starting on some more basic concepts in my forthcoming videos. I'll be using UDK to demonstrate these examples since the material editor has a good preview system for visualizing the math. Enjoy.
Subscribe to:
Posts (Atom)
























