If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Getting Started in Game Development (Programmer)

Getting Started with Game DevelopmentIntroduction

Okay, so I'm going to have a couple sections in here, for the various stages of people who'd like to do games programming, but don't know how (again, at various levels of knowledge). I'll try to be as concise as possible. Basically, the four stages I'll talk about are beginner, console, pre-graphical and graphical. I'll outline them shortly here:

Beginner: You've never programmed before.

Console: You've done hello world, maybe a bit of string manipulation, some arithmetic, used variables, and done a few loops; you can compile a basic program and run it. Probably where people who've taken a single basic C++/Java class should be.

Pre-Graphical: You essentially know to work with a programming language, but you've never done any sort of graphics, just console stuff, maybe you've opened a socket or two, spawned a thread, or written a text-based game, but you definitely know what classes are, what a virtual function is. Probably where people who've taken that second C++/Java class should be.

Graphical: You're able to make 2D/3D applications, and are wondering where to go from here. This'll be less like a tutorial, and more just suggestions of interesting topics, though obviously there's a massive diversity in ways you can specialize here (graphics, networking, asset management, tools, etc..)

I'll be adding to this info over time, so it may change/expand/shrink without warning. At the top of each section, I'll post a TL;DR version, which'll basically just be a bunch of links with a couple of words of context. After that, I'll fill in the larger section of the post with more stuff that'll probably help move you along and motivate. Also, please keep in mind that these posts are written with a main focus on C++; if you're slightly more experienced than the pre-graphical section, the language shouldn't matter too much for you, so you'll still be able to get something out of the post.

Also, please note this constitutes only my highly biased advice. There are plenty of ways to go about getting ready to program a game; this is only one of many.

Beginner----------------------------------------------------------------------------------Objective: To get you to the point where you can compile a simple C++ program, and output simple phrases and numbers to the console.TL;DR: Download this, install it, if necessary, follow this for help. Read this, up until about lesson 11, and do the examples. Congratulations! You're at console level!----------------------------------------------------------------------------------

Okay, so you're interested in doing a bit of game programming, but know nothing about programming. That's OK! It's never too late or too early to start to learn to program, though you should probably know at least basic algebra (Grade 7 stuff).

Before we get started, I'm just going to give you a basic little overview of how computers work. I know, it may be a little boring, but I'll try and keep it as short as possible.

Computers are basically machines that do exactly what you tell them to do. If you can imagine doing something, logically, step by step, chances are, a computer can do it. All programs on a computer, whether they're written in C++, Java, C#, Ruby, Perl, whatever, at a basic level boil down to a computer doing one of a small amount of things one at a time, very fast. Everything runs in a sequence; a computer doesn't do two things at once (this is an extreme oversimplifcation, as today we have multiple cores, instruction pipelining, etc.., but accept this as fact for now). So you should think about programming, basically, as a long laundry list of instructions that you're giving the computer, which it will do, regardless of whether or not they make sense (this is the cause of bugs; the computer just checks to see it can read your instructions, not whether they make logical sense).

Now, your first question probably is, what exactly do I need to write instructions for my computer? The answer is, you don't need anything fancy (well, it IS fancy, it just doesn't look it), you just need what's called a compiler. A compiler basically takes simple text files, (like a .txt) and turns them into instructions the computer can read (.exe files). That's really all you need at the most basic level. However, while you can program with that, and notepad, it's generally better to get what's called an IDE (an integrated development environment), which gives you a bit more stuff than just the compiler; it'll color text, and format things in such a way that it's a lot easier on the eyes, and give you a whole bunch of extra useful features which I won't go into right now.

So, what you should be doing is downloading this (codeblocks-12.11mingw-setup.exe), and installing it, and using following this for help, if you need it. Code::Blocks is a solid cross-platform IDE (will work on linux, mac, or windows), that'll let you easily work with and make small programs.

Once you've installed it, you should be ready to go. The whole process will take care of installing your compiler (g++/mingw), a debugger (gdb), useful for getting rid of bugs (big shock, I know), and a nice text editor. So, when everything's installed, and you're ready to go, fire up the program, and take a look at these tutorials: http://www.cprogramming.com/tutorial/lesson1.html, up until about lesson 11.

Console----------------------------------------------------------------------------------Objective: To familiarize you with object-oriented programming, and some of the more advanced features of C++.TL;DR: Read these up until lesson 20. Then read about templates. Then read about enums and the preprocessor. Then read about the STL. Yey! you're now pre-graphical.----------------------------------------------------------------------------------EXPANDED SECTION COMING SOON

Pre-Graphical----------------------------------------------------------------------------------Objective: To prepare you to begin working in a 2D/3D graphical environment.TL;DR: Learn to use SDL. All of it, hopefully, but mainly the core and SDL_image. Good tutorial here. Learn about OpenGL from here when you're done. A good 2D/3D math primer is here (Also applicable for introductory-level college classes!). You need to understand matrices, vectors and their transformations. When all that's done, and you can write a proper 2D/3D , you're now able to make a full-ish game!----------------------------------------------------------------------------------EXPANDED SECTION COMING SOON

Graphical----------------------------------------------------------------------------------Objective: None, we'll just swap advice, interesting tutorials/papers, etc..TL;DR: Somewhat less advice spam (though still some ) from me, more talking. I've felt the best way to gain experience and build up skills is, obviously, to try something new. That being the case, I've found it's interesting to try out novel techniques, and see how they work, and see if you can actually implement them properly. In this section, I'll basically post papers and stuff I find interesting/novel for games. And here's the first: http://www.ericrisser.com/stuff/Rend...entMapping.pdf.

Four big (optional, opinionated ) pieces of advice for the more advanced crowd; I strongly advise installing Linux, either in a virtualbox or as dual-boot if you're not running it already. It's obviously a personal preference, but I started developing stuff in Windows, and in switching to Linux I've felt my productivity and the ease of using the system for technical tasks massively increase.

Another good thing to look into is Makefiles. It's painful at first, but worth it; it gives you a lot more flexibility in how you want to structure things, though for the vast majority of projects you don't need it. However, sometimes, the IDE just isn't flexible enough to do a few things (Code::Blocks can't automatically mark folders to add all files matching a pattern to the compiling list, making it a nightmare for independent (i.e. not all in one massive include list), generated code).

Third, if you haven't already, consider learning a scripting language; there's a ton to choose from, and coming from coding C++, or Java, you'll think they're magic. If you don't care about speed, or the nitty-gritty details (games, usually do), they're dead useful to have around; you can write up a tool that might take days in C++ in hours in Perl (my special girl), Ruby or Python (or others).

And lastly, it's always a good idea to use a version control system, even if you're working alone. It's the difference between living in black and white and living in colour, in terms of coding confidence. A VCS basically lets you see all changes you, or someone else has ever made to your code, stores all files, and lets you revert the files to any point at which they ever existed (example; you break your game with a big change, and can't find the reason why. No problem, just rollback with your VCS, all your affected files are now back to the exact way they were when you comitted, yesterday. Or maybe you want to see all line changes since the game was working. You can. Magic). Example of VCSs are CVS, SVN and git. Everyone seems to love git at the moment, but SVN is also active. CVS seems to be dying out.----------------------------------------------------------------------------------

Well Done

Very nice piece Eriond, great to see you've become the heart of the game development forums, keeping them alive. So when I come back to visit, there's not just a lot of the same old that I use to enjoy, but fresh content to look over too.

Most was pretty familiar except I've never actually used git, I learned STL first and found it very powerful, I am weary of using it unless really necessary like for more complex applications/game engine.

I must check out git, sounds like it would be good for me considering I'm a very inconsistent on my programming projects. It leaves me unorganized, sometimes writing functions for the wrong programs. I jumped between small apps and a new game engine, as well as picC interfacing and microprocessor programming.

You're not the first person I've heard speak so highly of pearl, I often hear it in contrast with php scripting which I learned instead of pearl. I started learning python in between c++ and web development, never really applied the scripting for anything more than hobby projects and simple script games.

Very nice piece Eriond, great to see you've become the heart of the game development forums, keeping them alive. So when I come back to visit, there's not just a lot of the same old that I use to enjoy, but fresh content to look over too.

Most was pretty familiar except I've never actually used git, I learned STL first and found it very powerful, I am weary of using it unless really necessary like for more complex applications/game engine.

I must check out git, sounds like it would be good for me considering I'm a very inconsistent on my programming projects. It leaves me unorganized, sometimes writing functions for the wrong programs. I jumped between small apps and a new game engine, as well as picC interfacing and microprocessor programming.

You're not the first person I've heard speak so highly of pearl, I often hear it in contrast with php scripting which I learned instead of pearl. I started learning python in between c++ and web development, never really applied the scripting for anything more than hobby projects and simple script games.

Always nice to see you on your annual visit, pb .

Yeah, Perl is definitely easier for system-level scripting (not so much for web-scripting, PHP may be a better choice there). Nothing wrong with writing projects in scripts, but I find the best use you can get out of them is in complementing tools (auto-builder, assets organizer/generator, etc...)

And yeah, git is definitely an interesting way to do version control. If you have lots of projects (and it sounds like you do; very cool about the microcontroller programming, I've done some of that myself ) and you don't want to set up a server for each one, git is basically a distributed version of SVN, meaning that you can actually make local commits, meaning that you can have all the same functionality without actually having a server-side of the thing sitting somewhere. Useful.

I feel like those c++ tutorials leave a lot of, maybe not critical, but still important, stuff out. Can you recommend any other resource I could use in addition to those tutorials, to round out my knowledge of what I can do with the language?

Also, I feel like those tutorials are mm, reasonably good at explaining "how" you do things, but not "why" you would want to do things.

I like noise. I like big-ass vicious noise that makes my head spin. I wanna feel it whipping through me like a fucking jolt. We're so dilapidated and crushed by our pathetic existence we need it like a fix.
-Steve Albini

I feel like those c++ tutorials leave a lot of, maybe not critical, but still important, stuff out. Can you recommend any other resource I could use in addition to those tutorials, to round out my knowledge of what I can do with the language?

Also, I feel like those tutorials are mm, reasonably good at explaining "how" you do things, but not "why" you would want to do things.

Well, that's a good point. To be honest, the best I've found for to you to find out the why is to set yourself a goal, and actually try to do it yourself, with what you know.

For example, try and write a simple text-based RPG, where you have rooms, and you can go n,s,e,w, pick up and drop items, and maybe even have a fight or two.

That'll go a huge way to rounding out your knowledge of the basic language, and getting your familiar with stuff like input and output, math and the basic data structures.

um, one more question I think. the cprogramming tutorials don't explain everything there is to know (for obvious reasons) by a long shot. In fact, especially later on, they make reference to things that the writer never bothered to cover at all fairly frequently.

So, upon getting to pre-graphical, should I just get some sort of encyclopaedia type thing? because all of the stuff that was left out of the cprogramming tutorials seems important, albeit not critical, and I feel like I should at least have a reference handy

or is the writing in any such source likely to be beyond me at this point (beginning pre-graphical, according to your guide)?

and finally, if I am ready to read some sort of encyclopaedia or whatever on c++, what would you recommend?

Last edited by Frostbitten; 04-06-2012 at 09:43 PM.

I like noise. I like big-ass vicious noise that makes my head spin. I wanna feel it whipping through me like a fucking jolt. We're so dilapidated and crushed by our pathetic existence we need it like a fix.
-Steve Albini

You raise a good point; I never really acquired a full grasp of the language until I actually worked with it professionally; the tutorials do tend to leave out some of the features of the language; simply because it's so huge to begin with, very few online tutorials will cover every little bit.

Written by the man himself, that should pretty much cover everything you need to know. If you really want to know everything there is to know about C++, that's it.

However, this may not be what you're looking for; what stuff specifically, do you feel was left out? You said you were interested in 'why' you'd want to do things a certain way, rather than 'how'. That's a good question, and it deserves a proper answer that I didn't give you in my previous post.

For a lot of things, in my opinion, to understand the why, you need a low-level understanding of how a processor works and executes instructions, how it manipulates memory and interfaces with the hard drive, etc... Since I took a university course on this stuff, instead of looking it up myself, I don't have the best list of sources to give you. The university textbook that taught me the basics of computer hardware, and why it behaves the way it does (which in turn, reflect the basics of C (and in turn C++) and why it behaves the way it does) was this one: http://books.google.ca/books?id=7pEX...page&q&f=false, but it doesn't seem to be available on amazon.

It's a lot to read, and absorb, and it's not easy. It's good that you're asking the question though, because knowing these things will make you a better programmer, that, I can guarantee you. So, in the interest of maybe providing you at least a topic summary, so you can do individual research on your own, I'll try and summarize, as briefly as possible, while glossing over, generalizing and assuming many points, the 'why of C++'. I'll probably fail miserably, but here goes.

Why C++ was invented?: FORTRAN and C are the two fastest current mainstream languages. C is the current gold standard by which other languages are judged. C++ is C with added features, that, when used properly, do not cause programs to run any (in some cases, a little) slower, yet are easier to read, and more concise (debatable, but for now, just assume this is true).

Why is C++ used by game developers?: Historical reasons, speed and portability. More games now are using other languages, but all the major AAA games use C++, because historically, the majority of large game engines are written in C++, it's almost as fast as C (more FPS, more effects, more everything), and it can be used on any system on which a C++ compiler can target (which is almost all of them, PS3 (Cell), Xbox360 (PowerPC), Desktops/Servers (x86, x64), Phones (ARM) etc..).

Why can't I do X easily in C++/Why is X not a feature of C++?: C++ is organized along the lines of "You don't pay for what you don't use.". Meaning that anything that would make your life, as a programmer, easier, but make the computer's life harder (in terms of longer execution, larger program size), that you wouldn't be using in all situations, is not present in the language itself, or needs to specifically invoked to be used. (Garbage Collection, Reflection, Weak Typing, Virtual Functions, etc..). Other languages like Java, or the scripting languages, go for ease-of-use and development, over speed and size, meaning that they have features that C++ does not (garbage collection), or have features that C++ has, but always enabled (virtual functions), yet they run slower, and are larger, in some cases, significantly. This guides a lot of the reasoning behind C++.

That's the basic three whys that I can think of. If you have a specific 'why' question, I'd love to try and help; it'd give me a better idea of what kind of answer you're looking for.

But anyway; feel free to PM me with any questions you may have about pretty much anything (setting up the environment, compiling your first program, etc...), or you know, post something. Lord knows this board could use a bit of posting.