[quote name='JWalsh' timestamp='1343270851' post='4963161']
But... that doesn't replace the need to fully understand how a graphics pipeline works. There's plenty of good documentation available on the web which details what happens to your 3D vertices/triangles as they're passed through the various stages of the pipeline. This is vital to understand... eventually. For the time-being, it's fine to, once you've been using Unity for a while, to try your luck at writing your own render-loop, that draws your own 3D models to the screen. This not only will require you to learn Graphics Programming fundamentals, but will also exercise your 3D math. As getting a 3D object to show up on a 2D surface is entirely about Linear Algebra and Transformations.

This whole part completely confuses me. I think this is where my knowledge is lacking the most. I'm not exactly sure as to what the graphic "pipeline" even is and I have no idea how I would even go about starting to write my own graphic look. If you agree with Simon's path to take through Unity3D, what path would you say I should follow in order to fully understand what's happening graphically? How does this apply to programs like Unity3D?
[/quote]

This really is a hard question to answer, if you take a good graphics class in college you should get the basics covered anyway so i wouldn't worry about it at this point (Unless you're more interested in graphics than in games, in which case you should skip Unity3D and go with OpenGL or Direct3D, just don't expect to make games quickly that way)

Direct3D is the graphics subset of the DirectX API. (Which also includes DirectSound, DirectInput, etc)
OpenGL and Direct3D are equivalent in terms of features, Direct3D is only for Microsofts platforms (Windows, xbox 360 and Windows Phone, OpenGL is available on all desktop operating systems, They are basically a standardized way to talk to the graphicscard driver. (which allows you to run the same code on AMD and nvidia GPUs for example) All higher level engines and libraries go through either OpenGL or Direct3D (or both)).
Consoles tend to have their own APIs and most smart mobiles(only real exception is Windows Phone) use OpenGL:ES (which is essentially a subset of OpenGL).

As for scripting, with Unity you don't need to worry about that, Unity uses C#, Boo(a variant of python) or UnityScript(a variant of ECMAScript/JavaScript) for scripting support, all languages give you full access to the engine so go with whichever you prefer.

What exactly does a scripting language ....
[/quote]
Strictly speaking there is no difference between a Scripting language and a normal language, its all about how you use them.
If you use a language as a scripting language it will run inside another application and control its behaviour(in other words, you use the language to write scripts rather than applications). (C# is a scripting language when used in Unity3D and you could even use C++ as a scripting language with for example CINT if you if you feel like it (not in Unity though)).

Some languages, such as Lua were designed specifically for this purpose (Allthough Lua has been extended over the years and can be used as a general purpose language aswell), many scripting languages have alot of domain specific functionality built into them aswell, (JavaScript for example makes it really easy to manipulate websites)

I guess I was under the wrong impression with Unity3D. I had wrongly assumed it was an engine only used for 3D games. JWalsh also suggested Lua instead of Python. Why would you suggest Python instead of Lua? I understand each side probably has its pros and cons, but I'm interested in what part about it you like or don't like about Lua in order to make a decision.[/quote]

Unity can be used for either 2D or 3D games. As a side note, as nearly all computers have GPU's these days, all games are inherently 3D. The ones that look 2D do so because they were displayed using pre-transformed triangles sent through the GPU with nothing but sprites as their texture. So they look 2D. This will make more sense later.

As for the scripting language, I personally wouldn't bother with either. Lua is more frequently used in the industry for scripting, but it's easy to pick up when you need it. As for the purpose of a scripting languages in games, there are three reasons.

1. Scripting languages often have easier syntax and/or less restrictive rules than full programming languages. For example, Java is a strongly typed language. Every variable needs to be an integer, a byte, a string, etc... Lua is a loosely typed language, as is JavaScript. When you create variables, you don't have to explicitly state what data type it is, the interpreter will figure it out for you based on the type of data currently stored in the variable. This frees "non-programmers" from having to deal with issues such as what the appropriate data type is for the range of value you're looking for.
   
2. Because scripting languages are hosted by a larger program, the transition between the two gives you a barrier between your code-base and what the user has access to. For example, let's say I have a Character object that has various attributes such as Health, Strength, Inventory, etc... I want the user to be able to read those values, so they can create custom UI's, but I don't want them to be able to set them. I can bind my game-object to a scripting language object that allows them to receive the values, but not set them. Likewise, I may have tons more values on my Character object which isn't exposed to the user through the scripting environment at all.
   
3. Scripting languages in their true sense are processed by an interpreter at run-time in their original form, which is human-readable text. They are never compiled to an intermediate form or into native machine code. This means I can run a script, make a change to it, and immediately run it again with a different effect. In contrast, changes to the game code require a re-compile. So if I write a game engine, and then want the designers to add behaviors to the world, such as enemy spawning points, sound nodes, triggered cinematics, enemy patrol paths, etc... I could either code those up in the game code, but then any changes would require the designer re-compile the game. (Scary), or I can add support within my game for loading and processing scripts. Then the designers modify the scripts to change the game behavior, and neither I nor they have to re-compile.
   

With those three points in mind, do you really need a scripting language for your own games? Likely no. It'll just be you making the game, and even if you work with others, your team and game will be small enough that re-compiling won't be a problem. Also, when using Unity, you're not "scripting" with C#. You're writing code-behind, which is to say, you're adding behaviors to the game objects. Changes to the behaviors WILL require a re-compile. But that's ok. It's quick, painless, and ultimately runs faster than scripted events anyways. If/when you've mastered other stuff and want to learn a scripting language, take your pick. If you do join a game company that uses a scripting language, then learn that one.

Also when moving along with these projects do people generally post links to them in the forums for critique?[/quote] Absolutely! Feel free.

So would you suggest I just skip C and C++ for now and move directly to C#?[/quote] Yes. It'll be an easier transition from Java, and will get you making games right away. Move down to C++ when you feel you've sufficiently mastered C# and are ready for new challenges.

This whole part completely confuses me. I think this is where my knowledge is lacking the most. I'm not exactly sure as to what the graphic "pipeline" even is and I have no idea how I would even go about starting to write my own graphic look[/quote]

Fair enough. But before I go into what a graphics pipeline is, let's really quick talk about what the main game loop is.

Main Game Loop

In a game, there is an infinite loop that repeats over and over again, ideally 60 FPS, or whatever your monitor's sync rate is. This loop involves three steps;

1. Check for input from the player.
   
2. Process input from the player.
   
3. Draw the environment
   

Step 1 generally means checking the keyboard, mouse, touch screen, or game pad to see if any key/button/etc.. was pressed since the last time you checked. If it has, you either set internal game variables to handle those buttons during Step 2, or your partially process them now. For example, if I determine the W key was pressed on my keyboard, I may want to set my character's movement vector to "Forward". This makes it so that in Step 2 I can update the character's position.

Step 2. This means allowing the world to "advance". It means updating animation states, moving objects around the world based on their current velocities, it means checking for collisions to see if anything should stop moving, and it means updating AI game states so enemies know about the changes in the world around them and can plan accordingly.

Step 3. With the world in a new state, we need to let the user know that. This is done by re-drawing the entire state of the world. Or at least, the part that is close enough to the user that they could possibly see it. This is where the graphics pipeline comes in.

Graphics Pipeline
Once you're ready to perform step 3, you now take on the task of drawing your game world. Depending on whether your game is 2D or 3D will have an impact on the complexity of this problem, but the steps are more or less the same. I'll assume we're talking about a 3D game here for completeness, but then explain why it's the same for 2D.

In most 3D games, what you now have after steps 1 and 2 is a collection of game objects, each which are represented by a series of points (vertices). These vertices are used in combination with winding order and indices to identify the surfaces (triangles) of the objects. So when you look at a box, for example, it has 6 sides, each which are made up of two triangles for a total of 12 triangles. However, many of the corners of the box (vertices) are re-used when making the box, so there are only 8 corners (4 on top, 4 on bottom).

Now, our goal is to take this collection of 3D points & surfaces and draw them to a 2D screen. This process is called the graphics pipeline. It was previously done entirely in software. See Doom, Wolfenstien3D, etc... Nowadays, this process is done entirely in hardware. The stages of the pipeline roughly go like this:

1. Take your 3D points and build triangles out of them using indices
   
2. Take your 3D triangles which are currently in model space, and transform them into world space, then into camera space, then into screen space, one vertex at a time
   
3. Perform any per-vertex lighting or texturing calculations that need to be done
   
4. Perform any per-triangle calculations that need to be done
   
5. Take any 3D triangles which are facing away from the screen and cull them (back face culling)
   
6. Take any 3D triangles fully outside of the screen and remove them
   
7. Take any 3D triangles which are partially outside the screen and clip them to the edge, creating new points as necessary
   
8. Interpolate positions, colors, & textures across the pixels of the primitives and project them into homogenous viewport space
   
9. Perform any per-pixel calculations that need to be performed
   
10. Draw the pixels to the frame buffer, blending existing colors in the buffer with new ones as necessary, and checking depth values to determine if new pixels should be drawn
    

Once you've done the above, the frame buffer will hold new color values and the next time your display adapter tries to draw the screen it'll get the new values. Now, if you're making a 2D game, then it's representing by quads instead of boxes. These are just two triangles together that make a square, in which the square is already in screen space. So the first two steps of the pipeline have already been completed. All the other steps occur even in 2D games, because you're running your game on 3D hardware, and it does it either way.

OpenGL and Direct3D are equivalent in terms of features, Direct3D is only for Microsofts platforms (Windows, xbox 360 and Windows Phone, OpenGL is available on all desktop operating systems,[/quote]

This used to be true, but isn't strictly speaking true anymore. Windows 8, which will be released in October, allows the development of Apps in a special App Mode. These Apps are largely portable across Win8 desktops, ARM tablets, and Windows Phone. However, you cannot use OpenGL for these apps. So you can add Windows 8 Apps as one other eco system in which OpenGL doesn't work. Though OpenGL still works on Win8 Desktop Applications.

Unity vs. XNA
Finally, I'd like to make one other suggestion. As described above, the main game loop in a game is where you take and process input (update the game), and then draw the scene. In Unity, the drawing portion is entirely hidden from you, and the update portion is abstracted into behaviors. These are classes/methods you write that allows you to update the state of your actors when Unity says it's time to do so, usually 60 times a second.

In contrast to this, XNA is a slightly lower-level framework (entirely in C#) that provides a Game framework which handles the main game loop, but then gives you the ability to update your game in a single Update callback, as well as draw the game in a single Draw callback. This gets you closer to the main game loop and helps you better understand what's happening under the hood. XNA also has a super easy to understand 2D API that's based on the SpriteBatch class. So if you're just getting into game programming, it might be beneficial to start with XNA making 2D games, and then move to Unity when you feel comfortable enough to make 3D games. This has the added benefit of giving you the best of both worlds, and alleviates you from having to worry about creating/gathering 3D art assets just yet, which includes 3D models, animations for those models, and textures to apply to the models.

Even if you decide to start with Unity making 3D games, it might be beneficial to you to move to XNA at some point, strictly so you're more familiar with the game loop and so you continue your top-down journey. If I had to make suggestions to people on the best way to learn/grow as a programmer/game developer I'd recommend the following order.

1. Make 2D games with XNA in C#
   
2. Make 3D games with Unity (and C#)
   
3. Make 3D games with XNA in C#
   
4. Make 3D games with SharpDX in C# (SharpDX is a very thin managed wrapper around DirectX)
   
5. Make 2D/3D games with DirectX11 using C++
   

By the time you hit #5 you'll be employable by a game company. Note that, most game companies won't hire you until you've hit #5.

Cheers and Good Luck!

So do you think I would not be turned down for a job whether as a programmer or as a future game designer because I haven't learned a scripting language?

Whenever you apply for a job, your skill-set will be matched against the needs of the company. As most programmers aren't expected to do scripting, it's unlikely it would have an impact. On the other hand, if you plan to apply to game companies as a designer, then you likely want to have experience with multiple scripting languages. The best way to figure out which ones is to look on the hiring portals of various game websites and see what languages companies are looking for. The most popular online job portal for games is Gamasutra's Jobs Portal. And of course, you can always look at the "Jobs/Hiring" pages of your favorite game companies.

So if a script was set up for an enemies health, if you found them to be too strong, you could change the script value of 200HP to 150HP without restarting the game and recompiling your code, and see the change in results? If this is the case, what limitations are there for what can be scripted? Or would it just be harder to write a game full of scripts and be close enough to the computer to accomplish what you want?

Scripts are usually put in place to change behaviors, not values, though the principal is much the same. For changing values, such as enemy health, there's usually some kind of editor or database application that shows the health of the monsters. The value would be updated in the application and the level/monster data saved to disk. This data file then gets loaded into the game and the new value would be there.

Scripts are more like making alarms go off or creatures spawn when someone opens a door or moves into a specific area.

This is so out of my league right now. Is this something I will learn as I move forward, because to be honest I understand what you are saying but actually applying that into a real situation would just be me throwing darts with a blindfold on.

It's something you'd learn in a computer graphics class. It is also something you can learn on your own as you advance your studies. If you use Unity, you don't have to worry about it at all. If you use XNA, the steps of the pipeline are handled for you, but you have to provide the Graphics API with the model objects you want it to draw (just a couple lines of code).

Another nice benefit of XNA is you can take baby steps. 1. You can use models and the BasicEffect class, which pretty much does everything for you. 2. You can use models but then write your own effects and Real-Time shaders. This gives you more control over the graphics pipeline and lets you control the vertex and pixel shading parts of the pipeline. That's the per-vertex or per-pixel lighting and texturing steps I outlined above. 3. You can create your own vertex & index buffers and use your own real-time shaders. At this point you've got more or less complete control of the pipeline and can do hardware instancing, advanced shading algorithms, hardware skinning... you name it. But again, don't start there. Just start making simple, manageable 2D games in XNA.

One thing I recommend to people, and the first tutorial series I wrote here on GameDev.net back in the late 90's was "OldGames: Making Games from Old to New". Basically, start by making a pong clone, then move on to Asteroids, Galaga, Tetris, Pac-Man, etc... keep making simple 2D games beginning from the earliest PC games and working your way forward. In that way, your capabilities continue to grow, and your games look and act increasingly more complicated - which is very rewarding! Once you feel you've gotten as far as you can with 2D games, then move on to Unity and 3D games.

Obizues, there are several good tutorials at the Creators Club, as well as sample games, starter kits, demos, etc...Additionally, the XNA documentation is some of the best I've seen for an API. I recommend starting at the XNA Game Studio 4.0 Documentation root, and just drilling down, reading each sub-section of each section and following along with the tutorials and samples. You'll want to pay specific attention to the section on Writing Game Code. When you get to 3D there's plenty of tutorials there as well, and there's also my own blog/tutorial website, GameDevelopedia.com

As for learning C#, just jump in the deep end and starting writing XNA games. It's handy to have a good C# reference with you, and there's no harm in reading a good C# book as you work through the 2D game projects, but there's no reason to wait to start making games until you've "mastered" C#. You'd be waiting forever. And, your background in Java will give you enough information up front you won't be hopelessly lost.

Of course, if you get lost feel free to come on here and ask questions.

So would you suggest I just skip C and C++ for now and move directly to C#?

You cannot skip C/C++ and go to C#, they are different languages with very different runtimes. Kinda like skipping delphi and going straight to python.
C/C++ are the industry standard languages and will be for many (hundreds of?) years to come. Whereas C# really will only ever be an indie language or used by smaller companies or for internal tools etc...

If you already know C, there is no real reason for you to use C# since there many 3D libraries and solutions available for C without needing to be wrapped (by yourself or 3rd party). Also in the long run it will make it much easier to port to different platforms and reuse code. (C# and Java can wrap C libraries, but you will find it very hard to wrap C# from Java and visa-versa).

As for engines, if you can push your C knowledge to OO C++, then I highly recommend Irrlicht. Otherwise using plain OpenGL with C simply isnt that hard anyway so I also recommend this route. This web resource is very good for using modern OpenGL (http://openglbook.com/) if you do decide to go down this path. As for things like model loaders etc... you will find many many more for C/C++ than can ever be supported by things like Unity so you can make choices on exactly what your project requires.