Welcome to the Java Game Development Tutorials!

This tutorial series was designed specifically for people who already know the basics of Java programming but would like to learn how to make games with Java. If you don't know how to program in Java or are unfamiliar with it, we recommend Sun's The Java Tutorial. It's one of the best ways to learn Java--the only better way, we think, is to buy a book or take a class. (Incidentally, some of the tutorials on The Java Tutorial covers a lot of the same material that we cover, although not all of it.)

Another very important Java resource is the Java API documentation (currently version 6), which will provide you with top of the line documentation on all of Java's core classes, functions, etc. Due to their very nature, most tutorials (ours included) are simply unable to cover every single function or class of a given Java feature, and in most cases, the only way you'll ever find out about them (other than by stumbling across them in sample code) is to look for them in the Java API documentation.

Anyways, we promised some tips, right?

Tip #1 - The compiler is your friend

A newbie mistake that many beginning programmers make is that they try to scrutinize every line of code they write to make sure that it is absolutely perfect before they even attempt to pass it through the compiler. For some reason, they believe that it's an embarrassment to have compile errors or code that outright fails when they try to run it. That view is highly egoistic and very time-innefficient.

Whenever I write code, I rarely get something that compiles on the first try. In general, for every 100 lines of code I write, I expect at least 3-4 compile errors, and once I fix those, I'm usually surprised if there isn't a bug.

Basically, the compiler was made to catch your errors for you. A compiler error isn't an insult to your awesome programming skills. It's a safety net. A spell-checker for programming, so to speak. Why waste your valuable time for typos and other silly errors when the compiler can do that in mere seconds.

Sure, there are sometimes legitimate reasons for scrutinizing code, but unless your program takes more than a minute to compile, eliminating compiler errors prematurely is not one of them.

Tip #2 - When in doubt, try it out

Don't be afraid to just try stuff. It's impossible to understand exactly how something works just by reading manuals, spec sheets, documentation, or even sample code. When it comes down to it, you'll just have to code something up and see how it works. And if it doesn't work, or if it works in a way you didn't expect, make the necessary modifications and try again. There's no shame in writing code without knowing 100% how it works. After all, experimentation is a perfectly legitimate--and extremely effective--learning technique.

Besides, what's the worst that could plausibly happen? You can't bring down your system with just any poorly coded program these days.

Tip #3 - Write readable code

You may think you're a hotshot programmer who can work with any code no matter how obfuscated it is, and maybe you're right. But maybe you're not, so you really should be writing easily readable code. It really helps when you're looking at your code 6 months later and you're trying to figure out exactly what you did. It helps even more if you're working in a team and there are other people who will need to read your code.

First of all, write comments. Sometimes, reading code is easy. You have a few variables and a few statements and a few function calls whose name and structure make what the code is doing obvious. At other times, the code will be doing some arcane stuff that isn't readily apparent until you scrutinize it. In general, 6 months after you write the code, if there's any chance whatsoever that what the code does is not immediately obvious to you, then add a comment or two. If you believe that simply adding the comment will help you comprehend it 6 months from now, you should prolly add it. (Don't go overboard with adding comments, though.) Also, most functions should be commented explaining what the function does, its arguments, and its return value. (Also, note that sample code tends to be much more heavily commented than "normal" code.)

Second of all, indent consistently. There's nothing harder to read than code that's indented incorrectly or inconsistently. Always indent your code. It's infinitely easier to read and debug code that is indented well.

Third of all, avoid tabs. Granted, this is prolly just a pet peeve of mine, but it's good advice just the same. Sure, there's nothing wrong with the tab button. It saves you the time of pressing space bar 2-8 times (depending on your IDE, your settings, and your indentation). However, the tab character is one of the most IDE unfriendly characters in existence. It annoys me to no end when someone gives me a file that's indented with some ugly combination of tabs and spaces (and tabs and spaces on a single line (yes, it's happened before)). It also annoys me to no end when that file is written in an IDE that has a tab-width of 4 instead of a tab-width of 8 (because, you know, tab widths have yet to be standardized), which means the file looks totally messed up until I figure out what tab width they're using and re-configure my IDE accordingly (or alternatively, I tell my IDE to re-indent everything). There's a very very simple solution to this: Configure your IDE to replace your tabs with spaces. That way, you can hit the tab button to save yourself trouble, but also save other people trouble by not using the tab character.

Last of all, if you're working in a group, sometimes, it's a good idea to adopt coding conventions, for stuff like how to indent, whether to put brackets on the same line or a new line, how classes should be organized, spacing, etc. While not always necessary, coding conventions help people agree how their code should be formatted and, as a result, helps keep there code consistenly formatted and readable.

Tip #4 - Print statements are good for debugging, but a good debugger is even better

A common debugging practice is to insert print statements at critical points to either confirm that execution reaches a certain point or to print the value of variables or expressions. It's generally a good technique and quite a popular one, too.

However, using a debugger is almost always better. It avoids the whole compile-recompile thing, and instead of just spitting information at you, it allows you to step through your program step-by-step.

Debuggers won't always work, though. It's kinda hard to determine how good an animation is when you're stepping through it in a debugger.

(Don't use a command-line debugger, though. The lack of, well, a graphical user interface makes them extremely clunky.)

Tip #5 - You are smarter than your computer

If you're a programmer, you're smarter than your computer. Sure, computers can process information really, really quickly, but they can only do what you tell them to do. Computer programming is literally telling your computer what to do. You tell it to print "Hello world!", and it obeys. You tell it to add 2 and 2, and it obeys. You tell it to connect to viltris.com, and it obeys.

Don't think of your computer as an opponent you have to defeat and subdue. This kind of thinking will only lead you to frustration. Instead, think of your computer as a simple-minded creature, to which you have to give very specific and very detailed directions on how to do things. Don't work against your computer. Work with it.

Tip #6 - Programming becomes easier with practice

Like many things, programming becomes easier with practice. Sure, it might feel difficult now, and sure, it feels like you're never going to get it. But every programmer feels like that when they first start out. After a few years of experience, things that they had trouble with when they first started out become second-nature. And as the years go on by, if you keep at it, you'll learn new techniques and keep getting better and better.

Just give it time, and you'll get the hang of it. Then, you'll get good at it. I promise.

Conclusion

That's it for tips. Next time, the tutorial begins for real. You're going to learn how to make your first graphical Java program using Applets.