Slashdot Mirror
Crash Course in Game Programming?
Lullabye_Muse asks: "I want to write a game program for an independent research class I am taking at my High School. I have until June to deliver a final product or a good demo. I'm somewhat new to programming and will be doing work at home, and at school (Linux and Windows, so cross platform OSS is best). What is the best language to learn to code games in, and do you have suggestions for any useful sites, on game programming?"
My suggestion would be Java, simply because the graphics libraries are pretty decent and it's not hard to write a decent GUI. Additionally, it's cross-platform and would probably help you in the real world later.
But the real question is, how much experience do you have currently? I started programming in HS by doing games on those little calculators (TI-81 to 85 completely self-taught) and enjoyed the experience so much I decided to do CS in college (graduated last year). If I were in your shoes, you may want to think small. Many of the early video games were text-based, many made by one person. Nowadays due to complication, you need teams. So it may not be a bad idea to write something simple and textbased in whatever language. Text-based doesn't need to mean uncomplicated or compromised gameplay; chess, othello, hearts, and dungeon-crawlers were all very popular and I still know people who prefer these over newer games.
-- Political fascism requires a Fuhrer.
Buy a couple of his books. You can find them dirt cheap at discount book stores or eBay.
If you want to go cross-platform, pick up his Java book. You could be writing primitive games in a week.
The easiest and most rapid way is with Flash. Loads of major stuff (importing sprites/moving sprites/collision detection) is taken care of. The langiage (actionscript) is very similar to Javascript. There are millions of easy tutorials/samples online to teach you the basics. Plus swf's are cross platform.
It's not the most powerful tool for making games, but its definitely one of the most rapid.
You need to ask yourself one thing before starting to learn to program: Do you want to program games, or just make games? The two are different.
A lot of gamers wind up deciding "hey, I want to program video games!" at some point, without realizing that what they really want to do is make games. If you don't know anything about programming, then you should start by learning the basics of programming and forget making video games for a while. You need to understand the basics first, before you can start doing anything complicated.
If you really do decide to make video games, I'd highly suggest making a couple of really simple games first. Something like hangman, where you just take a list of words and make the user enter letters until they "guess" it. This will teach you the basics of keyboard input and graphical display without having to worry too much about speed or game mechanics.
I'd suggest starting with Java too - maybe grab Eclipse as your IDE, or just use a simple text editor. This solves the "cross-platform" part, and as long as you understand that you won't be creating Quake in it, you shouldn't be too disappointed. (You could, of course, also try using Mozilla.) It's similar enough to C and C++ that you'll should be able to pick up those if later you wind up making a game in C.
But based on your post, I'd suggest learning more about how to program in general first. Take some classes, if you can. Learn the basics. Learn about basic data structures. This will give you the ground-work you need to create a game, as well as help you determine if programming is really for you.
You are in a maze of twisty little relative jumps, all alike.
Before the locals gather their pitchforks to run me out of town, here's why:
-If you don't know much about programming, even something basic like vectors or graphics libraries could be more than a little daunting. Flash makes graphics dog-dumb easy, leaving you to focus on the logic. A lot of the abstractions (game speed, display parameters, collision detection) can be handled easily, leaving you to learn how to program.
-You can do some OO programming with Actionscript, so you can start with a simple program, and when you get skilled, learn how to extract that functionality into libraries or classes.
-You should be able to focus on some simple programming aspects like game physics, or making it fun (which doesn't have much to do with programming).
-There are a zillion sites out there with bits of code that you can learn from and modify. Granted, lots of it sucks (i.e. it works, but it will not show you how to be a 'good' coder). Offhand, I don't know what to recommend to become a good coder, but at the least, I'd recommend plowing through at least the first 3 chapters of Bruce Eckel's Thinking in C++ (free online). Once you get through pointers and address references, actionscript will look like child's play. Sure, there are sites out there with sample PyGame/Java/etc. code, but Flash code is easier to cherry pick and drop in.
-You have to realize that what you're doing is similar to saying "I've never turned a wrench before, but I want to build a car in 4 months." Game programming can be exceptionally difficult on a number of levels.
Push all the "great ideas" to the back of your head, for now. They'll only get in the way at this point. Lay out a very basic game design and write it down. Do this both in plain English and in pseudocode. Resist the temptation to dive into feature details; don't go on about how different guns will do different things, and how there will be ten different types of enemies, or how you want the explosions to be green and shimmery. For now, make it simple: one guy, one gun, one type of enemy, one behavior. Note that this doesn't mean you shouldn't design for such expansion, though--be thinking about how to go about building your code to allow all sorts of things down the road, just don't get mired down in the minutae.
Build a basic, working prototype. Get input working; get drawing working; get audio working; get physics working; get collisions working; get interaction working; get menus and user interface working. Use placeholder graphics and sounds for now. Once you've made a good, solid, stable engine, then start working on graphics, audio, backgrounds, et. cetera. A good way to tell if you've reached this point is if you can play your ugly, bare-bones game and enjoy it. If you don't enjoy the game without the flashy stuff, adding finished content will just be like putting lipstick on a pig.
Finally, stick to 2D. You'll learn more about the "game" part of making games if you don't need to wade through all the extra crap you need to know to work in 3D. (It is also much faster and easier to create 2D content than it is to create 3D content, but again--that comes after you've got a solid engine in place...)
Obliteracy: Words with explosions
you suggest C++ with good reason, next to Assembler; IMHO it's one of the best languages for game programming. Granted game programming language pluses are speed and granular level control, at the sacrifice of user friendliness.
Then again if you're programming for a deadline project, maybe a simpler project coded in a higher up language, If you're a C++ programmer and using Windows, think C#, all the syntax none of the headaches though a bit slower since you're compiling to IL. If you're in a *nix environment I'd consider a simple Java game with the same considerations (similar to C++, none of the headaches and slower). Choose appropriately.
...in bed
domino.php --- 1k
dominoes.php --- 3k
dominoesBoard.php --- 10k
dominoesGame.php --- 13k
dominoesGui.php --- 18k
dominoesHand.php --- 2k
opHandler.php --- 3k
rules.php --- 2k
test_domino.php --- 1k
test_dominoes.php --- 1k
test_dominoesBoard.php --- 9k
test_dominoesGame.php --- 10k
test_dominoesHand.php --- 10k
WRITE YOUR TESTS! Notice almost 50% of my code is tests (and I feel that it's not enough, I currently got ahead of myself and need to catch up on my tests before I feel comfortable adding more functionality).
I would do a lot of thinking about what the parent poster said, specifically: Start Simple. Think About Your Win/Lose Conditions.
I'd like to add the note: Write Tests. To continue the blackjack example, what happens when a user has an "A, J" in their hand? (blackjack). How can you test that? Write a test for it. What happens when they have "J, K, Q" in their hand? (bust) How can you test for that? Write a test for it. What happens when they run out of money? What happens when they try to bet too much money? A negative amount of money? Write tests and repeat as necessary.
A whirlwind tour of my dominoes layout (this is to back-up the parent poster about the game libraries, and mechanics, etc):
For the GUI code, it's mostly HTML text to display stuff to the user, which is why it's so big. But even then, recognize that the bulk of the work is in stuff that the user doesn't even see (Board, Game)
--Robert
I think Blender is an excellent choice here. It's free, cross platform and very easy to get started in. Combinde with Pythin and the info available at GameBlender.org it should be very easy to get a awesome project out quickly. My 11 year old daugher got going with the 3D modeling in an afternoon after watching the online video tutorials.
T.J. Schmitz - the man, the myth, the legend - o
That post is probably the best advice I've seen here.
l
s p
The most important question I think is
"what is your true goal?"
Possible answer include:
a- something new and original
b- something really usable
c- something pretty
d- a combination of a/b/c?
Is the goal just to create any game? Being for a class and depending on your TA or professor, I would expect the engine to be more important than the look. (if it were commercial, it would probably be the reverse, ymmv.)
One important detail is how it should look, depending on your true goal. Be warned that if you are not already a designer (i.e. used to draw manually or with computer tools) then stay away from anything that requires a lot of art.
Even something as simple as a Pacman clone or 2d vertical shooter requires a lot of art and that can divert a substantial amount of time from your project.
If it's a class project and what matter is more having a complete usable game with a real engine that just pretty static picture, nobody will care if your pacman looks like a blue circle as long as it can travel around and properly collide with walls.
Now for the specifics: some people like card games, some others don't. Personally I'm more into 2D games. They can be easy to program. As a start, you can have a look at a basic game I wrote a long time ago (it clones an old Amiga game) and that I regularly port to different platforms (it's a great way to learn a new language and framework):
http://www.alfray.com/projects/Nerdkill/index.htm
This one is in C# and uses DirectX (desktop) or GDI (PocketPC). The engine was written to reasonably easy to understand and adaptable to other languages or platforms and is somewhat described here:
http://www.codeproject.com/netcf/cfgamenerdkill.a
and
http://ralf.alfray.com/.izumi/Dev/NerdkillDev
Technically it could sure be ported to work under Linux using Mono and GTK#, although there's some work there especially if you have to learn these APIs too.
The whole thing is GPL so feel free to reuse it if you like. I thinking of it more as a way to see how to organize your project (or not.)