Hi Lijok, welcome to the forum, and to the world of gamedev! I'll take a stab at answering some of your questions.
Lijok, on 31 December 2012 - 07:24 AM, said:
Some artist may prefer Mudbox over Rhino, or some other modeling program. Some programmer may know C++, but not some other programming language, or vice versa. So do all those different art programs for instance give the same end result that can be implemented within any game programming? Does any programming language suitable for gaming can be made to cooperate with another programming language? (so 2 programmers with knowledge of 2 different languages can work together). Or do certain projects use only certain programming language? And certain art tools?
A studio will typically standardize on the programming language(s) to be used. Most commonly, this will be C++ for the innards of the engine; there is often also a scripting language embedded in the engine, which designers can use to create missions and suchlike without the assistance of programmers. A variety of languages (including custom languages invented by the studio) can be used for this purpose. Finally, tools (e.g. level editors/compilers) might be written in C# or another "managed" language, although C++ is popular for this purpose as well.
Similarly, art tools are going to be standardized across the studio. Artists of different specializations use different tools - Maya/Max, Photoshop, ZBrush/Mudbox, custom level editors, etc., but everyone in the studio will be using the same tools for the same purpose. It'd be chaos otherwise - if everyone just picked their own tools, then Jane wouldn't be able to open Bob's files and vice versa.
Yes, different people may have different personal preferences for which language or tools they like to work with best, but when you work for a company you have to use what everyone else uses. But learning different languages or tools is no more than a temporary inconvenience for a professional game developer. All good programmers know multiple languages and can pick up a new language quickly. Likewise, all good artists know multiple tools and can pick up a new tool quickly.
Lijok, on 31 December 2012 - 07:24 AM, said:
2) How do game engines work? What do they do?
A game engine is an application that provides basic systems and services for making a game, such as: graphics rendering, physics simulation, animation playback, sound and music playback, scripting language support, input handling, networking, level loading, savegames, low-level AI tools such as pathfinding, raycasts and queries, memory and performance profiling, and in-game developer tools for debugging and editing. At its core it is a frame loop: a loop that does everything required to generate the next frame of the game - which can include contributions from any or all of the aforementioned systems - then displays the frame on screen, and repeats. Pro game engines will almost always be implemented in C++ and can easily run over a million lines of code.
Some game engines are custom-built for a specific project; others are designed to be general-purpose engines adaptable to a wide variety of projects, and the company that makes the engine sells it to studios to make their games with. Engines you may have heard of, like Unreal, Crytek or Unity, are the latter kind. Even when using one of these engines, though, there is often a lot of code customized for the specific project.
Lijok, on 31 December 2012 - 07:24 AM, said:
3) What's opengl for instance?
OpenGL and Direct3D are graphics APIs. They provide a standardized interface for application programmers to talk to the graphics hardware (GPU), regardless of which company made the GPU or what its particular features might be. The ideal with these APIs is that the programmer doesn't have to know or care about differences between hardware (in practice, we still have to worry about it a little bit). An engine programmer writes code to command the GPU what to do to render their game, by calling OpenGL or Direct3D.
Lijok, on 31 December 2012 - 07:24 AM, said:
4) In game files, you see .dll, .cfg, etc. But you rarely see any in game art work as view-able picture within game files. How are those artworks stored in those different format files? Are they converted to some sort of code?
Game art assets like models, textures and so forth are usually stored in a container file of some sort - a big file that includes the data for many art assets packed together. This is primarily to help loading time - it's much faster for the hard drive to load one big file than many small ones. Additionally, the data will usually be compressed into a custom format that matches exactly what the game engine needs, so the engine can just slurp the whole thing into memory and not have to do any processing. So it's not going to be in a standard format you can open in Photoshop or similar.
The fact that it makes it slightly more difficult for people to extract or hack your art assets is only a side benefit. Serious hackers won't be stopped by pack files; it's not that difficult to reverse-engineer these kinds of formats. It does discourage casual hacking, though.
Lijok, on 31 December 2012 - 07:24 AM, said:
6) What languages are best learned for game programming in general?
I recommend people to start with Python, because it's easier and clearer to get the general concepts. C++ is a more powerful language, but also more difficult, and has lots of fiddly details that aren't very friendly to a beginner, so save that one for your second language. BTW, time spent learning Python is not wasted, since it is a quite useful scripting language in its own right. Note that the general concepts of programming are largely common to all languages. Once you've learned one, it's much easier to pick up a second, third, fourth, etc. Professional programmers pick up new languages on an as-needed basis.
Lijok, on 31 December 2012 - 07:24 AM, said:
7) Why are there so many different languages? How is one language superior to another?
There are many trade-offs in language design and different languages make those trade-offs in different ways. There are systems languages like C and C++, which are used for low-level stuff like interfacing with hardware, or for performance-sensitive tasks. There are scripting languages like Python, Javascript, and Lua, which are used when the ability to rapidly write and modify code and easily "get stuff done" is more important than execution speed or safety. There are managed languages like Java and C#, which are a bit of a middle ground - faster and safer than script and usable for large applications, but allowing more rapid development than raw C/C++. Each language has a different design point that makes it suitable for different situations.
0
unless your some kind of genius.
