I put Windhaven on Steam Greenlight : please upvote if you'd like to see the game released on PC. Looks like a huge logjam of games trying to get through the door at the moment though, including a lot of XBLIG titles.
Does anybody have any experience with the unity physics engine? I have a spaceship I'm trying to addtorque to in order to rotate it. It all works fine except addtorque doesn't seem to add a value to the current rotation as the function name implies but rather completely changes it. For example, if the ship is spinning around the y axis, then you addtorque to the z axis to roll it, it doesn't continue on spinning and now rolling as well. Instead it just stops spinning and rolls.
I've found the recent twitter posts about the map engine for your next game quite interesting. I'm poking around with a 2d, tile / sprite based game in my spare time (C++ / DirectX) and am curious what are the kinds of features that end up being really useful.
I put Windhaven on Steam Greenlight : please upvote if you'd like to see the game released on PC. Looks like a huge logjam of games trying to get through the door at the moment though, including a lot of XBLIG titles.
You can have my vote . I didn't realise a fellow DBP developer was on here. I finally got round to submitting mine on the Windows Phone store. Its my first experience with XNA certification on the platform. Looking forward to seeing how it goes. If all goes well, I'll have a play to see how friendly porting to XBLIG's is.
"Oh, well, this would be one of those circumstances that people unfamiliar with the law of large numbers would call a coincidence."
I've found the recent twitter posts about the map engine for your next game quite interesting. I'm poking around with a 2d, tile / sprite based game in my spare time (C++ / DirectX) and am curious what are the kinds of features that end up being really useful.
Well I'll let you know the more I work with the new features in our maps.
Having just toyed with a few concepts in the first map that I finished for Rainslick4 which used a lot of our newer map features, I can say that the most useful things for making maps nicer without breaking my back doing it are having a flexible yet easy-to-use lighting/shadow system, and also a way to have a flexible number of frames and frame-rate set to animated tiles in your maps. The first map in rainslick4 I ended up putting 8 frames of animation for the tiles and certain map objects because I simply decided that I wanted it to look more smoothly animated. (this is a step up from the 2 max frames of animation our previous games let me use in our maps). I'm still thinking that 4 frames is more than sufficient for most maps though, but the flexibility is nice. A quick and painless method for adding lighting/shadows nice for making the maps feel like they have more depth and space to them, and let me add more detail to them as well. Our light/shadow system is really basic (just an alpha-channel layer above the regular map tiles) but being able to adjust the degree and quality of the shadows and lights (glowing edges around torches for example) by using alpha channel is pretty nifty. Overall our map engine's still really basic but we continue to improve it with each game and I continue to get more efficient at doing these types things so eventually I figure we'll have really neat, crazy cool things going on but for now we are learning to walk before we can run.
@Delzhand: Thanks, you got me on the right track. I ended up with this:
rigidbody.AddRelativeTorque(currentAxis + Vector3.forward * Mathf.Abs(roll) * rollSpeed); //currentAxis is the rb's angular velocity before adding torque. rollSpeed is the max amount of torque to apply
I'm sort of embarrassed that I didn't think of this myself, that's basic vector stuff right there. But I guess my issue was that I assumed addtorque would be doing that already, maybe it should be named changetorque instead.
Yeah, there's some stuff like that in Unity that's odd unless you know how it works. Like for gameObject.Transform, you can't edit the rotation, there's a Rotate method, and also a RotateAround method.
It's a little weird, but I don't mind having a layer of abstraction if everything is handled with quaternions and I don't have to mess with it.
That is a seriously awesome solution to collision detection. And the awesome part is, I assume, it works immediately in 2d, and could easily be ported to 3d by using planes instead of axes.
Oh yeah, that's how collision in N and N+ work. They have a really good writeup on their website too. I found it to be a pain in the ass, personally, especially if you don't need more than rectangular collisions.
Oh yeah, that's how collision in N and N+ work. They have a really good writeup on their website too. I found it to be a pain in the ass, personally, especially if you don't need more than rectangular collisions.
What was such a pain about it? The code itself looks really simple. Like, deceptively so.
I implemented the algorithm last night but I haven't actually tested its usage out at all, so if you have any insight into speedbumps I might be getting into I'd appreciate the notice.
Oh yeah, that's how collision in N and N+ work. They have a really good writeup on their website too. I found it to be a pain in the ass, personally, especially if you don't need more than rectangular collisions.
What was such a pain about it? The code itself looks really simple. Like, deceptively so.
I implemented the algorithm last night but I haven't actually tested its usage out at all, so if you have any insight into speedbumps I might be getting into I'd appreciate the notice.
I implemented it a few years ago using the N writeup.
The difficulty is in getting different shapes to properly collide with each other. Triangles were the worst.
Edit: Hurr. mBattle isn't defined when OnSelect is assigned
Maybe someone can help me out with delegates here. I'm trying to build a menu in Unity that mimics the menus from the GameStateManagement sample.
A simple delegate.
public delegate void EventDelegate();
The relevant bits of the MenuEntry class
public class MenuEntry : MonoBehaviour {
public EventDelegate OnSelect;
public virtual void OnSelectEntry(){
if (OnSelect != null) OnSelect();
}
}
The relevant bits of the Menu class
public class Menu : MonoBehaviour {
void Start () {
string[] entries = new string[]{"Move", "Attack", "Item"};
foreach (string s in entries){
GameObject menuEntry = new GameObject(s);
menuEntry.transform.parent = this.transform;
menuEntry.AddComponent("MenuEntry");
menuItems.Add((MenuEntry)menuEntry.GetComponent("MenuEntry"));
menuItems[menuItems.Count-1].Text = s;
menuItems[menuItems.Count-1].OnSelect += mBattle.TestMenuSelectionMove;
}
}
protected virtual void OnSelect(){
if (menuItems[selectedEntry].OnSelect != null) menuItems[selectedEntry].OnSelectEntry();
}
}
mBattle.TestMenuSelectionMove has this signature
public void TestMenuSelectionMove()
I've confirmed that Menu's OnSelect() function is being called, and it's triggering the MenuEntry's OnSelectEntry() function. I've confirmed that the MenuEntry's OnSelect EventDelegate is not null.
The error message I'm seeing is "InvalidProgramException: Invalid IL code in (wrapper delegate-invoke) EventDelegate:invoke_void__this__ (): IL_004a: ldarg.1", which is pretty incomprehensible.
So I'm hearing that XNA is on it's way out, to be replaced with... something Windows 8 centric. Is learning XNA worth bothering with now? If not, what instead? I'm aiming for simple 2D tile based stuff right now, which makes Unity et all a bit... overkill. And clunky as hell.
Even if it's on it's way out you'll still be able to use it, it just won't be updated anymore. So I'd say it's worth it since what you learn with xna you'll be able to apply elsewhere.
So I'm hearing that XNA is on it's way out, to be replaced with... something Windows 8 centric. Is learning XNA worth bothering with now? If not, what instead? I'm aiming for simple 2D tile based stuff right now, which makes Unity et all a bit... overkill. And clunky as hell.
The "something else" isn't windows 8 specific. It's just C++ / DirectX 11. If you want to make a win8 store app or write for the phone you need to do some specific things when your app is setting up (how to create a window, need to respond to events for suspend / resume) but the game and DirectX code will be the same.
Not that this is as good as XNA of course. That was a far superior offering to what they have for win8.
So I'm hearing that XNA is on it's way out, to be replaced with... something Windows 8 centric. Is learning XNA worth bothering with now? If not, what instead? I'm aiming for simple 2D tile based stuff right now, which makes Unity et all a bit... overkill. And clunky as hell.
The "something else" isn't windows 8 specific. It's just C++ / DirectX 11. If you want to make a win8 store app or write for the phone you need to do some specific things when your app is setting up (how to create a window, need to respond to events for suspend / resume) but the game and DirectX code will be the same.
Not that this is as good as XNA of course. That was a far superior offering to what they have for win8.
I believe they're still using it for Xbox 360 and any 7.x targeted XNA apps will also run on WP8, but as you say, they're moving onto C++/DX11.
"Oh, well, this would be one of those circumstances that people unfamiliar with the law of large numbers would call a coincidence."
So I'm hearing that XNA is on it's way out, to be replaced with... something Windows 8 centric. Is learning XNA worth bothering with now? If not, what instead? I'm aiming for simple 2D tile based stuff right now, which makes Unity et all a bit... overkill. And clunky as hell.
The "something else" isn't windows 8 specific. It's just C++ / DirectX 11. If you want to make a win8 store app or write for the phone you need to do some specific things when your app is setting up (how to create a window, need to respond to events for suspend / resume) but the game and DirectX code will be the same.
Not that this is as good as XNA of course. That was a far superior offering to what they have for win8.
I believe they're still using it for Xbox 360 and any 7.x targeted XNA apps will also run on WP8, but as you say, they're moving onto C++/DX11.
That certainly does seem logical. I mean, someone asked me about my XNA project today, and I told them XNA's only real benefit over something like Unity is that you get very fine-grained control over everything, but this ultimately lead to reinventing the wheel a lot. The only people who would need or want that kind of control are the kind of people who are probably more hard-core programmers, who might prefer C++ to C#.
oh yeah XNA will run on win8, and xbox 360 and pretty sure on win8 but you will not be able to create an app for the Win8 store using XNA.
Aha! I didn't realise that one small (but very important caveat). Its strange. I would have thought it would have been a good idea to integrate XNA to the Windows 8 ecosystem proper. I haven't even looked at the Win 8 dev infrastructure, may taker a closer inspection closer to when my XNA license expires.
"Oh, well, this would be one of those circumstances that people unfamiliar with the law of large numbers would call a coincidence."
Yeah, I don't quite understand why they're dropping XNA completely, but then again, they appear to be anticipating quite a bit of pushback on Win8's Metro BS, so, who knows?
Has anyone had an experience doing 2D stuff in Unity? My friends say it's quite possible, but I've never been able to even get started.
oh yeah XNA will run on win8, and xbox 360 and pretty sure on win8 but you will not be able to create an app for the Win8 store using XNA.
Aha! I didn't realise that one small (but very important caveat). Its strange. I would have thought it would have been a good idea to integrate XNA to the Windows 8 ecosystem proper. I haven't even looked at the Win 8 dev infrastructure, may taker a closer inspection closer to when my XNA license expires.
It's because XNA is very tied to DirectX9 specificially. That's getting pretty old now.
Of course MS definetly has the resources to make a new XNA from scratch on top of DX11. But it would need to be from scratch.
So, for instance, a year from now an XNA release would still be a thing?
A year from now you could release an XNA game on PC, xbox 360 and Windows Phone 7 (probably) yes. What you wouldn't be able to do is release for the Win8 app store for PC (this is a new thing with win8, which comes out next month) or for Win8 Phones (pretty sure)
You can write XNA apps and sell them for Windows Phone 8. However, you will not be able to use any of the new featues from WP8. You are just writing a Windows Phone 7 game and WP8 happens to be backwards compatable with those.
There is also monogame, which is an open source framework designed to provide a C# api very much like XNA. This is being actively devved at this point and several Microsoft blogs have strongly hinted that this is the (pathetic) replacement going forward.
You can write XNA apps and sell them for Windows Phone 8. However, you will not be able to use any of the new featues from WP8. You are just writing a Windows Phone 7 game and WP8 happens to be backwards compatable with those.
Yeah, I just submitted an WP7 app for certification last week and it automatically added WP8 as a compatible platform. So it makes sense that you can write for both, but only code for what the lower OS (i.e. WP7 supports) and I assume that will remain the case in a year's time.
"Oh, well, this would be one of those circumstances that people unfamiliar with the law of large numbers would call a coincidence."
Yeah, I don't quite understand why they're dropping XNA completely, but then again, they appear to be anticipating quite a bit of pushback on Win8's Metro BS, so, who knows?
Has anyone had an experience doing 2D stuff in Unity? My friends say it's quite possible, but I've never been able to even get started.
I haven't done anything 2d in unity, but you could just set up an orthographic camera and then lock everything to 1 plane.
I think if I can somehow figure out how to dynamically control the points of two triangles and the UV coordinates they map to in Unity, I could pretty much do anything I was going to do in XNA in Unity.
My favorite musical instrument is the air-raid siren.
Yeah, I don't quite understand why they're dropping XNA completely, but then again, they appear to be anticipating quite a bit of pushback on Win8's Metro BS, so, who knows?
Has anyone had an experience doing 2D stuff in Unity? My friends say it's quite possible, but I've never been able to even get started.
I haven't done anything 2d in unity, but you could just set up an orthographic camera and then lock everything to 1 plane.
That's what someone suggested, basically just lock the camera straight down and set everything on one plane, maybe use alpha plus a bit of Z axis movement to handle layers and parallax scrolling et all. It still seemed extremely obtuse.
I've been working on a design doc for a new game for a while now. Think of it as a weather simulator/world builder/resource collector/craftalike/monster-killing/Tower Defense game.
Think it's a good one? I certainly do, but I'm leery of how oversaturated the indie Tower Defense genre is, and how much more it will be by the time I'm done with this game.
Where can I learn about shaders top to bottom? I really don't know where they belong in the production pipeline. Should they only be used in code? Should they be attached to textures? Should artists/animators even deal with them directly?
I'm trying to get Blender as our animation tool, but the other guys are worried that it won't support our HLSL shaders and will make animation harder. They want to use shaders for simple flashing effects and want that baked into the animation.
So, any info can help me out, especially stuff on the do's and dont's of shaders.
Shaders are basically code that runs on visual output, and it doesn't matter what you use for your modeling or animation pipeline. Flashing effects are a textbook example of something that should DEFINITELY be handled with shaders, and definitely not baked into animations. I'll see if I can write something a bit more detailed later tonight.
Just for the mental exercise, I'm going to braindump the admittedly little I know about shaders. Delzhand will probably one-up me, but hopefully I'll make a worthy opening act.
With basically all modern graphics hardware, you as the programmer hand the graphics card a bunch of data that represents what you want it to draw. It's not always the same data, but typically you'll be giving it a set of vertices to produce polygons and a bitmap to draw on the polygon. A shader is another piece of data that the graphics card accepts, but it's actually code. In my experience, the shader runs once for every output pixel, but don't take that as gospel-- I'm sure there are some wacky optimization tricks done to make it super blazingly fast. But conceptually, a shader is a program that runs across each pixel and puts out a color value for that pixel.
Where shaders get interesting is that they have the ability to store their own variables locally. For instance, the amount of flash to apply to the object you're drawing. So, you can tell the graphics card "here, draw this sprite over here, using this as the shader code, and by the way, set the shader's flash value to .5". Or, if you want to get really fancy, you can provide a whole second bitmap to inform the change in picture color. The technique called "bump mapping" uses one bitmap to provide color (what you'd normally think of as the polygon's "texture"), and then a second bitmap to represent the normal to the surface at the corresponding position. This helps create the sort of fine-grained bumpiness inherent to things like bricks without using nine thousand times the polygons.
As programs, shaders are written in a dedicated programming language such as HLSL or GLSL. These are fairly well-known specifications, and pretty much any graphics hardware should be able to run a shader in one of the more standard languages.
So, to recap: on any given render: give graphics card your shader -> give graphics card vertex and texture info -> set shader variables -> pixel color in -> your shader function here -> pixel color out.
... all right, have at it, Delzhand.
My favorite musical instrument is the air-raid siren.
I am by no means an expert on writing shaders or HLSL, but I have a pretty good idea what they can do. Essentially, like I said before, they work on the output you give them. Whatever happens in your draw call, that's what gets sent to your graphics hardware. Shaders tell the hardware what to do with that data. It doesn't matter if it's a cube modeled in Blender or a fully skinned model from Maya.
There are 2 main parts to a shader - manipulation of vertexes, and manipulation of pixels. Using vertex manipulation, you could do something like give a model an outline - you'd just take every vertex of a model, scale it along its normal, invert it, and set its color to black. Vertex shaders are actually how 3d animations work to begin with. The animation is just data that says "vector 823 is moved from its default position by (1.2, 3.4, 5.6) when it is 7 seconds into animation X".
Using a pixel shader, you could do something like create a blur effect by iterating over every pixel, getting the value of its neighboring pixels, and blending the RGB values.
When you combine the two, you can do some amazing stuff. There may be better ways to do this, but consider this:
You render your entire scene to a rendertarget, and it gets drawn without any special shaders. Then you draw just your main character on a white background to a separate rendertarget, using a pixel shader that changes all white pixels to transparent and everything else to 50% yellow.
Then you draw the scene rendertarget, and the main character rendertarget on top of it. Your character is now tinted yellow.
You can expand on this pretty easily. In your pixel shader, you could create a second "pass" that would convert all transparent pixels that border a yellow pixel to be some fraction of yellow that decreases with distance - now your character glows. You could draw the original scene without the character, and instead of setting the character pixels to yellow, you just half their opacity - now your character is half invisible.
Aside from shaders that handle 3d animation, you don't usually need them to make a game. But they're the fastest, easiest way to add polish, visual effects, etc. if you're willing to spend some time with them. I picked up what I know over the course of a week - it looks intimidating if you're unfamiliar with it, but it's really not too bad.
Posts
Similarly, Influx!
I've found the recent twitter posts about the map engine for your next game quite interesting. I'm poking around with a 2d, tile / sprite based game in my spare time (C++ / DirectX) and am curious what are the kinds of features that end up being really useful.
You can have my vote
Well I'll let you know the more I work with the new features in our maps.
Having just toyed with a few concepts in the first map that I finished for Rainslick4 which used a lot of our newer map features, I can say that the most useful things for making maps nicer without breaking my back doing it are having a flexible yet easy-to-use lighting/shadow system, and also a way to have a flexible number of frames and frame-rate set to animated tiles in your maps. The first map in rainslick4 I ended up putting 8 frames of animation for the tiles and certain map objects because I simply decided that I wanted it to look more smoothly animated. (this is a step up from the 2 max frames of animation our previous games let me use in our maps). I'm still thinking that 4 frames is more than sufficient for most maps though, but the flexibility is nice. A quick and painless method for adding lighting/shadows nice for making the maps feel like they have more depth and space to them, and let me add more detail to them as well. Our light/shadow system is really basic (just an alpha-channel layer above the regular map tiles) but being able to adjust the degree and quality of the shadows and lights (glowing edges around torches for example) by using alpha channel is pretty nifty. Overall our map engine's still really basic but we continue to improve it with each game and I continue to get more efficient at doing these types things so eventually I figure we'll have really neat, crazy cool things going on but for now we are learning to walk before we can run.
Steam ID: slashx000______Twitter: @bill_at_zeboyd______ Facebook: Zeboyd Games
It's a little weird, but I don't mind having a layer of abstraction if everything is handled with quaternions and I don't have to mess with it.
I don't know if any of you guys read Notch's twitter, but he just linked this:
http://www.codezealot.org/archives/55
That is a seriously awesome solution to collision detection. And the awesome part is, I assume, it works immediately in 2d, and could easily be ported to 3d by using planes instead of axes.
What was such a pain about it? The code itself looks really simple. Like, deceptively so.
I implemented the algorithm last night but I haven't actually tested its usage out at all, so if you have any insight into speedbumps I might be getting into I'd appreciate the notice.
I implemented it a few years ago using the N writeup.
The difficulty is in getting different shapes to properly collide with each other. Triangles were the worst.
A simple delegate.
The relevant bits of the MenuEntry class
public class MenuEntry : MonoBehaviour { public EventDelegate OnSelect; public virtual void OnSelectEntry(){ if (OnSelect != null) OnSelect(); } }The relevant bits of the Menu class
public class Menu : MonoBehaviour { void Start () { string[] entries = new string[]{"Move", "Attack", "Item"}; foreach (string s in entries){ GameObject menuEntry = new GameObject(s); menuEntry.transform.parent = this.transform; menuEntry.AddComponent("MenuEntry"); menuItems.Add((MenuEntry)menuEntry.GetComponent("MenuEntry")); menuItems[menuItems.Count-1].Text = s; menuItems[menuItems.Count-1].OnSelect += mBattle.TestMenuSelectionMove; } } protected virtual void OnSelect(){ if (menuItems[selectedEntry].OnSelect != null) menuItems[selectedEntry].OnSelectEntry(); } }mBattle.TestMenuSelectionMove has this signature
I've confirmed that Menu's OnSelect() function is being called, and it's triggering the MenuEntry's OnSelectEntry() function. I've confirmed that the MenuEntry's OnSelect EventDelegate is not null.
The error message I'm seeing is "InvalidProgramException: Invalid IL code in (wrapper delegate-invoke) EventDelegate:invoke_void__this__ (): IL_004a: ldarg.1", which is pretty incomprehensible.
The "something else" isn't windows 8 specific. It's just C++ / DirectX 11. If you want to make a win8 store app or write for the phone you need to do some specific things when your app is setting up (how to create a window, need to respond to events for suspend / resume) but the game and DirectX code will be the same.
Not that this is as good as XNA of course. That was a far superior offering to what they have for win8.
I believe they're still using it for Xbox 360 and any 7.x targeted XNA apps will also run on WP8, but as you say, they're moving onto C++/DX11.
That certainly does seem logical. I mean, someone asked me about my XNA project today, and I told them XNA's only real benefit over something like Unity is that you get very fine-grained control over everything, but this ultimately lead to reinventing the wheel a lot. The only people who would need or want that kind of control are the kind of people who are probably more hard-core programmers, who might prefer C++ to C#.
Aha! I didn't realise that one small (but very important caveat). Its strange. I would have thought it would have been a good idea to integrate XNA to the Windows 8 ecosystem proper. I haven't even looked at the Win 8 dev infrastructure, may taker a closer inspection closer to when my XNA license expires.
Has anyone had an experience doing 2D stuff in Unity? My friends say it's quite possible, but I've never been able to even get started.
It's because XNA is very tied to DirectX9 specificially. That's getting pretty old now.
Of course MS definetly has the resources to make a new XNA from scratch on top of DX11. But it would need to be from scratch.
And does that mean that I need to learn directX at some point?
There isn't a "transition" in the usual sense. Everywhere you can currently use XNA you will still be able to use XNA.
You would need to learn C++/DirectX if you wanted to use the new Windows 8 Marketplace though.
http://msdn.microsoft.com/en-us/library/windows/apps/hh465149.aspx
So, for instance, a year from now an XNA release would still be a thing?
A year from now you could release an XNA game on PC, xbox 360 and Windows Phone 7 (probably) yes. What you wouldn't be able to do is release for the Win8 app store for PC (this is a new thing with win8, which comes out next month) or for Win8 Phones (pretty sure)
You can write XNA apps and sell them for Windows Phone 8. However, you will not be able to use any of the new featues from WP8. You are just writing a Windows Phone 7 game and WP8 happens to be backwards compatable with those.
Yeah, I just submitted an WP7 app for certification last week and it automatically added WP8 as a compatible platform. So it makes sense that you can write for both, but only code for what the lower OS (i.e. WP7 supports) and I assume that will remain the case in a year's time.
I haven't done anything 2d in unity, but you could just set up an orthographic camera and then lock everything to 1 plane.
That's what someone suggested, basically just lock the camera straight down and set everything on one plane, maybe use alpha plus a bit of Z axis movement to handle layers and parallax scrolling et all. It still seemed extremely obtuse.
Idea: http://www.apathyworks.com/blog/critique-my-game-idea/
Think it's a good one? I certainly do, but I'm leery of how oversaturated the indie Tower Defense genre is, and how much more it will be by the time I'm done with this game.
I'm trying to get Blender as our animation tool, but the other guys are worried that it won't support our HLSL shaders and will make animation harder. They want to use shaders for simple flashing effects and want that baked into the animation.
So, any info can help me out, especially stuff on the do's and dont's of shaders.
With basically all modern graphics hardware, you as the programmer hand the graphics card a bunch of data that represents what you want it to draw. It's not always the same data, but typically you'll be giving it a set of vertices to produce polygons and a bitmap to draw on the polygon. A shader is another piece of data that the graphics card accepts, but it's actually code. In my experience, the shader runs once for every output pixel, but don't take that as gospel-- I'm sure there are some wacky optimization tricks done to make it super blazingly fast. But conceptually, a shader is a program that runs across each pixel and puts out a color value for that pixel.
Where shaders get interesting is that they have the ability to store their own variables locally. For instance, the amount of flash to apply to the object you're drawing. So, you can tell the graphics card "here, draw this sprite over here, using this as the shader code, and by the way, set the shader's flash value to .5". Or, if you want to get really fancy, you can provide a whole second bitmap to inform the change in picture color. The technique called "bump mapping" uses one bitmap to provide color (what you'd normally think of as the polygon's "texture"), and then a second bitmap to represent the normal to the surface at the corresponding position. This helps create the sort of fine-grained bumpiness inherent to things like bricks without using nine thousand times the polygons.
As programs, shaders are written in a dedicated programming language such as HLSL or GLSL. These are fairly well-known specifications, and pretty much any graphics hardware should be able to run a shader in one of the more standard languages.
So, to recap: on any given render: give graphics card your shader -> give graphics card vertex and texture info -> set shader variables -> pixel color in -> your shader function here -> pixel color out.
... all right, have at it, Delzhand.
There are 2 main parts to a shader - manipulation of vertexes, and manipulation of pixels. Using vertex manipulation, you could do something like give a model an outline - you'd just take every vertex of a model, scale it along its normal, invert it, and set its color to black. Vertex shaders are actually how 3d animations work to begin with. The animation is just data that says "vector 823 is moved from its default position by (1.2, 3.4, 5.6) when it is 7 seconds into animation X".
Using a pixel shader, you could do something like create a blur effect by iterating over every pixel, getting the value of its neighboring pixels, and blending the RGB values.
When you combine the two, you can do some amazing stuff. There may be better ways to do this, but consider this:
You render your entire scene to a rendertarget, and it gets drawn without any special shaders. Then you draw just your main character on a white background to a separate rendertarget, using a pixel shader that changes all white pixels to transparent and everything else to 50% yellow.
Then you draw the scene rendertarget, and the main character rendertarget on top of it. Your character is now tinted yellow.
You can expand on this pretty easily. In your pixel shader, you could create a second "pass" that would convert all transparent pixels that border a yellow pixel to be some fraction of yellow that decreases with distance - now your character glows. You could draw the original scene without the character, and instead of setting the character pixels to yellow, you just half their opacity - now your character is half invisible.
Aside from shaders that handle 3d animation, you don't usually need them to make a game. But they're the fastest, easiest way to add polish, visual effects, etc. if you're willing to spend some time with them. I picked up what I know over the course of a week - it looks intimidating if you're unfamiliar with it, but it's really not too bad.