Crash Course in Game Programming? 142
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 as a Game Programmer in HS (Score:5, Interesting)
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.
Andre Lamothe (Score:2, Interesting)
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.
Flash (Score:1, Interesting)
It's not the most powerful tool for making games, but its definitely one of the most rapid.
Make sure you *really* want to PROGRAM games... (Score:3, Interesting)
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 [sun.com] too - maybe grab Eclipse [eclipse.org] as your IDE, or just use a simple text editor [jedit.org]. 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 [xenoveritas.org].) 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.
putting flamesuit on...but how about flash? (Score:5, Interesting)
-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++ [mindview.net] (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.
General Advice (Score:3, Interesting)
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...)
Re:Flash (Score:5, Interesting)
Flash is a great medium for 2D games. the graphics are drag and drop, and the actionscripting is a perfect introduction to handling the logic associated with managing a game.
but, this being slashdot, anything mentioning Flash in a positive light will probably get modded downward and derided by the community.
Re:SDL Graphics library (Score:3, Interesting)
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.
Re:Flash (Score:2, Interesting)
Flash is easy if you have no experience, and there are lots of popular flash games. One of my favourite is curveball (just google it), not to mention yeti games.
I made my first flash game some time ago, and it is still a challenge to play. Took me only a couple of weeks, based mostly on the excelent tutorials at kirupa (google it).
And in my limited experience, actionscript is a great gateway language. At first, I found it really easy to do very simple stuff using the Flash GUI.
Soon that was not enough, so I started playing with actionscript in 'expert' mode. I even managed to create a few nice data structures there. But then I wanted to dynamically load stuff, so I learnt about URL variables, XML, etc...
Then I wanted to keep scores, so I learnt PHP and SQL. And to integrate my little flash experiments into a website, so I learnt HTML and CSS, which led to a little JavaScript.
At that time, my flash projects were so bloated and slow, that I grew frustrated, and started learning other languages, like java, perl, python, and just starting now, C++.
Give Flash a try, it does have its legitimate uses.
Re:Ignore everything else you've read here. (Score:4, Interesting)
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
Blender + Python = Games (Score:2, Interesting)
What is your true goal here? (Score:2, Interesting)
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 [alfray.com]
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.)