I've been following GameDev for more than 6 years now, lurking through the shadows and leeching on all the good and useful data that gets posted daily around here. Only recently have I decided to actually try to give back to the community... And I think I have found a way. Looking back, in all these years on GameDev, there hasn't been a day that gleefully passed by without someone starting a thread on the topic which language to use, which is "better"... Or the classic, what is DirectX or OpenGL questions... Or the common "I have an idea for a game, but I've never written a line of code or manipulated a vertex in a 3D package, but my idea is the best ever, which program should I use to make a game?". The last one has been covered by Mr. Sloper on his Sloperama website and by individual repetition here on GameDev a huge number of times. However, although Mr. Sloper's approach is honest and precise, it was more of an answer which dictates a "no" in sort of a dream crushing, harsh way without no directive on how to start.
With this topic, I'd like to address this issue and give newcomers to the world of game development some specific guidance on how to begin on all the aspects that bother them the most, at least from what I've gathered in my few years of observation. So, if you are a newcomer intrigued by the title of this topic, chances are you might find your answer here and save everyone from repeating themselves to death. Also, I've also found that people enjoy to water down plain text with some pretty pictures, so I've mashed up some stuff to aid your digestion process. I will attempt to make it as concise and to the point as possible. With the introduction out of the way, let us begin!
[heading]Absolute beginners[/heading][/font]
[font="Verdana"]
[/font]
[font="Verdana"]
So, you want to make games? Join the club... Oh, wait... Let me rephrase that, welcome to the club! Like most of us here on GameDev, you love playing games. Who doesn't? But do you have what it takes to make games? Many people come here with the assumption that making games is as fun as playing them. No, it's not. Making games is a relatively fun process, but it's downright naive to believe it's like playing games. However, many would argue that it's even more interesting than playing games when you capture the basics, which is understandable, considering that you actually create virtual, breathing worlds. However, in order to make games, you do need to put in a lot of work, break a lot of walls with your head and gain an understanding of a huge range of computer science topics. And most of all, you need to reevaluate your goals, because you are not going to make the next big thing right of the bat. But if you persist in your passion, you can get anywhere. With that said, for now... Forget GTA, forget Elder Scrolls, forget Fallout and what have you in that ambitious head of yours. Think small, think text-based RPGs, Tetris, Ping, Pong, Jing, Jang, grapefruit. Scratch that.[/font]
[font="Verdana"]Think about, for a second, how the loading of your operating system works... Does it simply burst into flames of victory and pops up ready to empower the user? No, there's a lot of small, baby steps which take place before that. Take the bootloader for example, a small program which can be stored in a compact area of memory easily executable at startup which enables the computer to interact with nonvolatile memory, usually a hard disk which contains a few files which will direct the computer on how to properly prepare the operating system to bring more complex code for execution.[/font]
[font="Verdana"]Do you see how crucial that small and seemingly insignificant bootloader is? Most newcomers are like computers without a bootloader, they'll never startup no matter how much they tried, simply because they refuse to start small and grow from there. Don't be like that![/font]
[font="Verdana"][heading]Alright, tell me more! (Programming languages) [/heading]
[/font]
[font="Verdana"]That's the spirit! Now, here's the gist of it: If you want to make games, you've got to learn a programming language. Although this statement is not entirely true, suppose for a moment that it is ( I'll elaborate on the alternatives later and why I presented it like this here ). Most indie game developers work alone and as such, it is recommended to hone skills in at least one programming language. The bottom line is, games are run on computers and computers crunch numbers. You are probably aware that games are pieces of very complex software which include a lot of mathematics, especially linear algebra ( the very least you should study ). With mathematics, physics is also a factor in portraying virtual worlds, but not so crucial. And now we come to the point of this paragraph... A mathematical equation won't create an image on the display of your computer, we need something dynamic, conditional, something that is written in a form that the computer can understand through the help of compilers and interpreters since we do not walk around throwing ones and zeroes around... Although, I've heard John Carmack does this from time to time. But, back on topic... So, what is that awesome thing that will enable us to talk with the computer about our ideas, how to portray them and how to react towards input? A programming language. There's a bunch of different languages available to a modern game developer, all of which can be used to talk with the computer in front of you. There are languages like C and C++ which are compiled (right down to object code which contains optimized low level instructions), there are languages like Python which is a pure interpreted language. Simply put, such a language is interpreted and executed line for line by an interpreter. Obviously, this is slower than a native language like C or C++ which get broken down to a very low level. And as an example of hybrids, we'll take C# and Java which are a combination of compilation and interpretation.[/font]
[font="Verdana"]In the example of Java, this combination works very well. First the code gets thrown into a compiler which generates bytecode and then that bytecode can be executed on any platform, provided there is a Java Virtual Machine present on the given platform. Why would people go through such trouble, you ask? Well, when you compile something, you implicitly compile it for a given computer architecture. This is a problem for a developer who is targeting multiple platforms which differ in hardware. Of course, you could go ahead and study each platform in detail and recompile your code for each of them. That would be efficient in runtime, but inefficient in development time. When performance is not crucial, you can delegate such issues to virtual machines like Java's which does all the dirty work for you. You only write code once and it works everywhere. Well, everywhere where a virtual machine exists.[/font]
[font="Verdana"]In the example of C# or any other .NET language... Well, there's not the obvious multiplatform benefit, but Microsoft does something else... They've developed a common software framework around which all of their managed languages revolve around. When you decide to compile C# code (or any other code written in a .NET language), it gets dissected just like Java's code into an intermediate format which can then be used interchangeably between different .NET languages. The .NET thanks this functionality to the Common Language Runtime. This comes with a price, you have to torture the user usually with bunch of side-effect files which enable the .NET framework to do its thing. So, you basically get accelerated GUI application development, a C++ biased Java-similar language and the opportunity to use stuff written in different languages without a worry in the world. Sounds nice, right? However, everything's pretty in theory. And yeah, all Microsoft's hardware has some sort of .NET functionality, so does the Xbox 360 and with the XNA framework, you can actually get to develop indie games for a recognized console for reasonable fees.[/font]
[font="Verdana"]So, we've just skimmed over some of the languages that are available, although there are literally tonnes of them, but these are the ones you are going to probably capture and work with... With, perhaps, the addition of Objective-C because it's the Mac/iOS's language of choice. The AppStore today is considered a gold mine for indie developers. Although, I've seen so much paid crap there it sickens me. Oh, I'm ranting again, sorry about that.[/font]
[font="Verdana"]To summarize everything, C++ is the game industry's choice. It's native, rich in features, object-oriented, quite fast for its design which incorporates an awesome mix between high-level and low-level stuff. Languages like C#, Java, Python and others are popular, but are unlikely to be used outside the indie developer range as the primary language for a game. EVE Online, for example, incorporates most gameplay mechanics in Python, over 600 thousand lines of code, but the base is still C/C++. So, obviously, those are not children's toys, they are great tools in your shed. Use them. On a side note, Minecraft was written in Java. There is no such thing as a better or worse language, they are just different. Always remember and cherish that fact if you wish to have a nice life as an aspiring game developer![/font]
[font="Verdana"]Okay, how can I get started working with these languages?[/font]
[font="Verdana"]
[/font]
[font="Verdana"]Visual Studio is the IDE of choice for everyone who is interested in C++ (on Windows, of course, where it's called Visual C++) or any of the .NET languages. I'd strongly advise you not to choose Dev-C++ because it's outdated. But if your choice is C++ and you don't wish to entangle Microsoft's products for some reason, then go for Code::Blocks, it's a really solid IDE, cross-platform... All that good stuff. In my experience, the Express Editions of various language IDEs will be more than adequate for every beginner's needs... Even surpass them. But it's your choice, really... [/font]
[font="Verdana"]For Python, check this website out. Don't underestimate Python, awesome stuff can be created with it if you have the imagination. Imagination is the fuel of life, my friends. Just don't allow it to mutate into a feature creep. We'll talk about that some other time. If you wish to enlist Java as your weapon of digital choice, acquire Eclipse, because thee is for ye.[/font]
[font="Verdana"]When you acquire your goods, you can start learning these languages, get really intimate with your choice before proceeding onwards. Patience, young samurai, your time will come. Google is your best friend, click here if you want some C++ learning resources.[/font]
I won't lie to you people, before you lies a huge journey. But you've got nothing to lose and so much to gain! Get on it!
[heading]Getting to the good stuff...[/heading]
[color="#1c2837"]OpenGL is, in contrast to DirectX, "just" a graphics library... It best relates to the Direct3D API from the DirectX SDK. The question which one is better is just silly, both are heavily represented on graphics hardware and both have a similar feature set, none leaps ahead too much in front of the other. It's just a matter of personal preference and project needs, since the fact stands that DirectX locks you to Microsoft platforms (most likely Windows) and OpenGL powers many operating systems, both mobile (iOS, Android) and desktop. Knowledge of both is preferable.
[color="#1c2837"]XNA and SDL are basically frameworks/libraries which are based on DirectX and OpenGL respectively and their goal is to reduce the amount of boilerplate code, help manage some trivial stuff which drags you away from developing actual games/applications. Both are on a higher abstraction level than their underlying API, which means you have a bit less control. So, it's a trade off, again, a decision which your preferences and aspirations will dictate.
[color="#1c2837"]Today, the fixed function pipeline is a thing of the past, even on mobile devices, everything is shader oriented. Wait, wait, what is the fixed function pipeline? Simply put, it's an old, predefined, locked path which dictates how 3D points in virtual space are interpreted and displayed on the screen. Logically, the less control you have over it, the less visual appeal the scene will have. In order to orchestrate more control, we've been given several new shading languages, but most notably HLSL (D3D) and GLSL (OGL). Through them, you gain access to the vertex, pixel and geometry shader stages. With Direct3D11, you also gain access to an optional tessellation step which is implemented in three stages ( free dynamic LoD, everybody! ).
[color="#1c2837"]Anyways, this is a lot of stuff to digest for the first post, I'll definitely keep this thread up to date, if the community approves of this effort. Hopefully, someone will find this useful and will defer him from creating a new topic for a common answer. Hope it helps! I would love to expand upon "game ideas", engines and all sorts of stuff whilst keeping it relatively easy to read later if this proves actually useful. What do you guys think?
.
