Getting Started with Game Development? 105
Knight2K writes "Recent articles about casual gaming have given me the itch to try my hand at writing some games. I haven't written any since my college projects, and they never followed any formal game design practice or patterns (unless it was unconsciously). I'd like to start just by writing simple board games and card games that my family liked to play that have no digital counterparts as far as I know. Eventually I might want to branch out and do 3D work. I mostly work in Java right now, but I'd re-learn C++, if needed. My question: what books would you recommend to a beginning game developer? Good introductions to game theory would be welcome, but also language or platform-specific suggestions are useful as well: OpenGL, Symbian, C++, Java, J2ME, etc."
Not a book, but... (Score:5, Informative)
Screw books (Score:5, Insightful)
Re:Screw books (Score:2)
Re:Screw books (Score:2, Interesting)
I agree that just doing it is best.
I started looking at the SDL Wiki example page [libsdl.org], and after looking over the code and browsing the game programming wiki [gpwiki.org] I just started coding.
My first game, and first use of SDL is mousetrap [steve.org.uk] - the graphics suck, but at least one person liked it [happypenguin.org].
SDL really was a pleasure to work with, and suprisingly easy to get started with.
Now I'm working on a more graphical platform game.
Re:Screw books (Score:2)
Re:Screw books (Score:2)
That was the theory. In the 60's. In the 80's it was Java, and that hasn't quite worked out as well as hoped, either.
"Write once, debug everywhere." Get used to it.
Oh. And I heartily agree with your suggestion of Python, but it is far slower than C. But its "glue language" facility makes it easy to recode bottlenecks in C.
While we're advocating; Objective-C rocks. Anybody who knows C should spend an afternoon learning Obj-C (that
Re:Screw books (Score:1)
Re:Screw books : Yep! (Score:2, Informative)
Well I program games, and though books can give you a headstart in doing certain things in a certain way, they never go very far or very deep, and usually are just a colleciton of tricks and tips. They just sit on my desk for the rare occasion that I need to look up the peculiarities of an A* or something or how to build a Q-Hull.
The best way to learn how to make games, is to go out and do it. The best reasons for using this or that language, is the reason YOU have, not the reason someone else has. Each
Re:Screw books (Score:2)
Those who do not study history are doomed to repeat it.
Re:Screw books (Score:2)
Let's consider you're writing a multiplayer game, consider a MUD (or even an MMORPG), which is something I'm confortable with. You'll have to understand issues like:
- Psychology (Character progression curve, interest):
How fast does a character have to develop itself in order to maintain interest. What is the breakeven point for
Just Do It (tm) (Score:4, Insightful)
The hard part, IMO, is the extra stuff like graphics and sounds. Unless you're talented in such things, making a game look and sound good is a real problem. It is especially troublesome if you don't know anyone who can do the artwork and is willing to just toy around with you for free. Good artists are expensive and games need to look good or most people will pass right over them.
The only technology that is really hard is the 3D stuff due to all of the math and such. However, there are so many libraries and engines out there (many free and open source) that most of that isn't an issue anymore and once again you're back to the art and gameplay being the hard part.
Just do it. If you run into problems, there's always Google. The best way to learn what you will need to know is to get started now and discover it on your own - that way you will not only know what doesn't work, but you'll also know *why* and that's an important element that can often go missing if you try to do it the "right way" from the beginning.
I agree, but here's another approach. (Score:2)
Here's the tough part: I can't stand the majority of design book. I've read a few (and skimmed/browsed dozens), and they mainly seem to be essays written by game designers on what games they do/dont like. Interesting, but imho they didn't equip me with any tips/trick/knowledge that could I could actually u
Re:Just Do It (tm) (Score:1)
From the post:I'd like to start just by writing simple board games and card games that my family liked to play
Graphics for simple board games and cardgames are free. most of what is in the Gnome Games are LGPL and as for
SDL & C/C++ on Linux may be a good start (Score:5, Interesting)
You might want to start here if you're going the cross-platform route:
http://www.libsdl.org [libsdl.org]
http://andrew.textux.com/tutorials/tut1/tutorial1
http://www.kekkai.org/roger/sdl/ [kekkai.org]
Re:SDL & C/C++ on Linux may be a good start (Score:3, Informative)
Makes it easy to write some cool little games
Re:SDL & C/C++ on Linux may be a good start (Score:3, Informative)
The problem with using C# and DirectX is you're requiring the user to have the .NET Framework and (I believe, not 100% sure) DirectX 9 installed.
And if the user has dial-up, then expecting them to download a 20 MB+ pre-requisite will probably turn a significant percentage of your potential audience away.
Blah, while attempting to find some sort of estimate of how many PC's have the .NET Framework installed (no dice), I stumbled upon a possible solution to the .NET Framework problem: .NET Framework Link [thinstall.com]
Re:SDL & C/C++ on Linux may be a good start (Score:1)
Comment removed (Score:5, Informative)
Re:Start Easy and Produce something. (Score:2)
For OpenGL.. (Score:5, Informative)
Re:For OpenGL.. (Score:2)
Re:For OpenGL.. (Score:3, Informative)
48 hour competitions (Score:1)
Game Production vs Game Design (Score:3, Insightful)
Programming a game and designing a game are two quite seperate disciplines. If you are interested in making a small game you'll probably be doing both.
Typically a game is designed on paper before any coding starts. Once the game design document is fairly complete a technical design document outlining the games implementation is written. Even for a small game, defining what your game is before you try to code it is an important step. That said there is nothing wrong with doing quick prototypes of gameplay ideas before you commit to something.
You game design document might list what platforms you intened to target and your technolgy choice should be influenced by that.
DirectX limits you to Windows only, SDL is great but not hardware accelerated (I think there are work arounds) but that might not matter for your target audience and platforms.
For some sample game design documents and a list of good books on the subject try http://www.ihfsoft.com/index.htm [ihfsoft.com]
Out of the books listed there I highly recommend Game Architecture & Design [amazon.com].
Re:Game Production vs Game Design (Score:1)
He doesn't say anything about coding games as a hobby. He does quote a number of articles on the phenomena of casual games, so I think in the long run perhaps he is interested in making a commercial game.
If you are intersted in finishing a game either as a hobby or as a commercial product, it's a good idea to have a plan
You need an overlaying SDK (Score:2)
Oh, and it works in both linux, windows, and Mac OSX....
SDL and patience :^) (Score:5, Informative)
http://www.nongnu.org/tong [nongnu.org]
It's from an old idea I had and was looking for an excuse to teach myself SDL, which some buddies and I had chosen for a much more ambitious game we're still working on.
We chose SDL primarily because it is cross-platform. I use and develop under GNU/Linux myself, but I want all my windows-running buddies to be able to play my games. OSX and even DreamCast porting is trivial, as SDL happily runs on those platforms and many more.
http://www.libsdl.org/ [libsdl.org]
SDL is very well documented and very slick to use, even to a newcomer (so long as you do have some programming experience). I'm a C and C++ guy, and SDL works with those natively, but if you wish to stick with Java or any other such language there are appropriate bindings. I highly recommend the libraries SDL_image and SDL_mixer as well, for boosting image and sound loading support. (I love being able to have my game just load up
I subscribe to master Miyamoto's game design theories, which basically amount to making your game into its own little playground, running on its own rules and rewarding the player for being clever. Keep the controls simple; a person should be able to pick up and play. Now, my game Tong is pretty rough at first, so I maybe don't follow this thinking very well in practice, but the philosophy is an implementation of the old "Keep It Simple, Stupid" that you've heard so often and I think it's very sensible. Especially for budding game developers.
Even with a well-documented API and a clear idea of what you want your game to be, it's going to take a while. Get a demo of "stuff happening on-screen" with mock-up graphics to get a feel for how you're going to render things, then trash the whole thing and start building up all the pieces you need. If your strengths are with object-oriented design, figure out all your game entities in terms of objects that all inherit things like how to draw themselves. If you're more of a procedural programmer, and even if not, figure out your main game loop, what needs to happen every cycle and what can be called out in special cases.
Take your time, let it be a pet project. The last thing you'd want is to extinguish your interest by making it a serious commitment. Starting small and building up is an obvious and good approach.
Best wishes! Long live the independant game developer!
Re:SDL and patience :^) (Score:1)
If you check the install folder, you'll find that most of that is taken up by the soundtrack in
Blatant Plug, but on Subject (Score:3, Interesting)
Everything's based on a CCL license, so you're (mostly - see site for details) free to take any part of the process and alter it to suit your personal needs.
The Project only started a couple weeks ago, so I'm still in the project specification stage. The first milestone (Initial Specification document) is already complete, and I'm well on my way to getting the next one done (a full high-level plan of what needs to be done, and where future milestones are going to sit.)
Is the whole thing overkill for such a small project involving a single coder? Of course! But, that's really half the point - the project is small enough that the basic principles I'm exploring can be understood by anyone coming into it.
For small, personal projects like what you're describing, you may not want to go to the lengths that I'm going to, but it might prove helpful to see what sorts of steps need to be addressed that are commonly forgotten about until it's too late (sound design, for one).
And, of course, it's not too late to add your own $0.02 (US) to the project's design, as I'm soliciting input via the forums on the site.
OpenGL Superbible (Score:2, Informative)
Good introduction to game theory! (Score:4, Interesting)
You and a partner commit a crime, and are arrested. In the interrogation room, you learn that the two of you will each go to jail for 2 years if neither of you says anything; however, if you testify against your partner, you'll get off free while he ends up with 6 years. If both of you confess, you both go to jail for 4 years. What do you do?
You are playing a game where you are given $50, and then asked whether you would like to take it as is, or flip a fair coin. If you make the latter choice and turn up heads, then your total amount will be doubled to $100; if you turn up tails, then the amount will be halved. Do you take the $50, or take your chance with the coin?
You appear on a game show where, at some point, you are told to pick one of three doors. Behind one of these doors is a prize; behind the other two, nothing. You pick a door. The host then declares that he will open one of the empty doors. Having done this, he offers you a chance to switch to the other, single remaining door. Do you switch, or do you stay?
Re:Good introduction to game theory! (Score:2)
The 2nd seems very obvious, maybe I missed something.
Re:Good introduction to game theory! (Score:2)
2) expected value for coin flip > 1, always take it ((50% * +50) + (50% * -25))
3) flame wars...
Re:Good introduction to game theory! (Score:2)
1) in one instance this is pointless, it's only if you can all learn from your mistakes that the probability wins out. Better to stay silent, usually.
2) I don't know the answer to this one, I suspect that you attempt to double, but being in this category of 'things that dont make immediate sense', you're probably better off staying.
3) Always stay. you now have a 2/3rds change of being right, as opposed to 1/2 (or is it 1/3rd) if you switch.
So, did I pass your game?
Re:Good introduction to game theory! (Score:4, Informative)
this site [uvm.edu] explains it better than I can.
Re:Good introduction to game theory! (Score:4, Funny)
2) Easy one -- flip! Half the time your total drops $25, the other half it goes UP $50. If you keep playing you'll make out better than just sticking every time.
3) Don't go on this game show. If you pick the right door, sure, you get a prize, but you'll also get a lot of publicity, your relatives and old friends will pop up out of the woodwork asking for money, and you may pick up a stalker or two. If you pick the wrong one you will be forever haunted by it. You'll wake up in the night covered in sweat, shouting "No, I said DON'T change, DON'T change!!"
Re:Good introduction to game theory! (Score:3, Interesting)
Get the DA to agree, in writing to grant you immunity before you rat out your buddy.
Easy: turn up heads. Flip it to your hand, and if it's tails, quickly slap it on your wrist, insisting it was "part of the flip". The other guy doesn't have any experience with how you flip coins.
Mod parent up! (Score:1)
You must allways offer choices to the players. You can make some of this choices random to add uncertainty (like in the third case), but you must add some problems where the player can evaluate the conditions and try to take an informed decision, which must be rewarded if it's good (like th
Re: (Score:1)
Re:Good introduction to game theory! (Score:1)
No fair! (Score:2, Insightful)
Pygame. (Score:3, Interesting)
The perfect way of starting a simple game.
Re:Pygame. (Score:1)
Plus, if I can do it [suttree.com], then you should have no problem
How about Flash? (Score:4, Insightful)
I know much of Slashdot's audience can't stand Flash, but I've had quite a bit of experience with it over the past five years -- I was a Flash game developer -- and I've got to say, ActionScript has become o very powerful language. Don't be fooled by its name: It's not a scripting language. It's an entirely object-oriented similar to Java and C#. You should feel right at home with it.
The upside is a very rapid development phase: you could bang out a prototype in a couple of hours, depending on complexity. It's also an almost-ubiquitous platform: With the exception of *nix (of which I know very little, and as such refrain from commenting), the player is reportedly installed in 90% of all browsers [flashmagazine.com].
The does-side is that you have little-to-no control over lower-level functions, such as memory-management; no direct disk access outside of 'Flash cookies'; and absolutely no access to a user's video card. It's also quite an expensive application -- it starts at $499.00 USD for the standard version.
Quite a number of amazing games have been developed using Flash, most notably (IMHO) Alien Hominid [newgrounds.com], which, ironically, has been turned into a full-fledged console game.
That's just my two cents, at any rate.
Re:How about Flash? (Score:3, Informative)
Right on, and with the addition of a good open source component framework [actionstep.org], it's only getting better. MTASC + ActionStep == good times.
It is a scripting language. (Score:2)
Re:It is a scripting language. (Score:2)
Re:It is a scripting language. (Score:2)
Re:It is a scripting language. (Score:2)
Re:It is a scripting language. (Score:2)
Re:How about Flash? (Score:2, Interesting)
What about Flash? [drizzle.com] is a great paper on wiritng games in Flash, from a programmers perspective.
The real advice I'd give once you've decided what tools to use, is to finish the project. Games aren't easy to write as they end up in play testing and bug hunting like any other app so put in the hours and finish off the game. If you never do it again at least you have a working game.
Best advice: Don't! (Score:3, Funny)
Start here. (Score:2, Informative)
And FYI, I'm resisting the urge to make snide remarks about the naivety of your comments. You state that you're ernestly going to try "making some games" (if you manage ONE coherent game I'll be impressed), and that you enthusiastically want to make 3D games (but appear to be scared of C++).
In the words of Yoda: Try not. Do. Or in this case, "after asking on Slashdot, try some of the suggestions".
Learn from games you play. You've obviously played a computer
Splashdamage (Score:1)
This will give you an excellent platform to start developing games from. You can dabble in gameplay, graphics, sound, AI, and so forth in a proven game. And heck, if you break it, you can always download it again :)
Writing your own modification is probably the easiest way to get into game development, for the simple fact that it is extremely popular and there's a large knowledge base to support
Don't forget... (Score:1)
Re:Don't forget... (Score:2)
Personally, I'd love to see a web version of Nethack, just to see it done. Or better yet, games like the early Final Fantasy series. To me, those games represent when gaming was actually fun and not all about eye candy or competition, it was the story that drew you in, got
Re:Don't forget... (Score:1)
Re:Don't forget... (Score:1)
I was writing Flash based interfaces which interacted with the server "AJAX-style" (ie. without page reloads, just sending xml to the perl backend) around 2000, long before anyone ever heard of "AJAX" except for the Greek hero and the Dutch soccer team.
In other words, "AJAX" is just a new name for a paradigm which has been used by Flash developers for many years, using actionscript instead of javascript.
To avoid flames: I'm not a Flash developer anymore. I'm
Torque 2D (Score:4, Informative)
2D is a nice way to go: it's a lot more fun getting so much more bang for your buck, without nearly as many content hassles either.
One cheaply available 2D engine that comes with source is from the good people at garage games, called Torque 2D [garagegames.com]. It's got a decent scripting language, and nice enough C++ code. If you don't want to re-learn C++ right away, you can accomplish quite a bit with only the scripting language.
There are probably some other nice 2D engines out there as well, so you can look before you buy. However, I'd recommend picking one and starting from there: it'll save you a ton of work, and you're much more likely to actually get something done.
One other possibility: I made a funnish GBA game [animalocean.com] in my spare time a while back. It just took a few weekends (and a flash linker from Lik-Sang), and the help of a couple friends. I never finished it, but it was a reasonable demo. GBA dev is slightly tougher than 2D dev with an existing engine, but the libraries out there make it really not too much worse.
Re:Torque 2D (Score:1, Informative)
http://developer.popcap.com/ [popcap.com]
Brackeen: Developing Games in Java (Score:1)
The Author's Website [brackeen.com] (Includes demo-project and source codes to all chapters)
I'm not affiliated with this in any way
Re:Brackeen: Developing Games in Java (Score:2, Troll)
Re:Brackeen: Developing Games in Java (Score:1)
Re:Brackeen: Developing Games in Java (Score:2)
Seems reasonable to me...
Graphics (Score:1)
For quick 2d adventures: AGS (Score:2, Informative)
You're in luck! (Score:2, Informative)
Gamemaker (Score:2)
Quick and easy (Score:2, Informative)
Then try to finish at least one game. It doesn't matter how simple it is. If you then want to concentrate on design, instead of the nitty-gritty details, you might want to try http://www.cs.uu.nl/people/markov/gmaker/ [cs.uu.nl]
For 3D, 3DGamestudio http://www.conitec.net/a4info.htm [conitec.net] is a cheap, decent, all-around game authoring system. You can cobble together a quick FPS
Two books (Score:2, Informative)
When it comes time for yo
J2ME is fun! (Score:3, Informative)
Realm Forge (Score:2, Informative)
10 Resources You Can't Live Without (Score:3, Informative)
I agree with those who say that knowledge of OpenGL and/or DirectX is a must, (always know something about what goes on under the hood), but I'm also a big fan of short time-to-market once you actually start developing a concept. Here are some 2D engines that speed up development:
---
Inago Rage [dejobaan.com] - Create and fight in your own FPS arenas.
---
Try PopCap Games' 2D Game Framework (Score:2, Informative)
Get A Job... (Score:2)
Seriously, working in the video game industry is a lot harder than playing video games at home. I spent six years working in the
2 books I can recommend (Score:1)
These two books really helped me:
- "Focus On SDL [amazon.com]" by Ernest Pazera
- ""Tricks of the Windows Game Programming Gurus [amazon.com]" by Andre LaMothe
handheld (Score:1)
If you come up with something cool its easy to just send a demo rom to a dev house.
Check SourceForge (Score:1)
While a lot of them are ports of older games, like Doom, others are new. All types, and many are written in Perl and Java, as well as C.
Don't for Allegro! (Score:4, Informative)
http://www.talula.demon.co.uk/allegro [demon.co.uk]
Don't Read (Score:1)
Clickteam Products (Score:2, Interesting)
www.clickteam.com
flipcode.org (Score:2)
I'm going to get blasted for this, but... (Score:3, Informative)
Killer Game Programming in Java [bookpool.com] from O'Reilly, and Developing Games in Java [bookpool.com] by David Brackeen, from New Riders.
Brackeen's book (Developing...) is particularly well-written, and a great place to start. Killer Game Programming in Java is an *excellent* idea source/reference in the great O'Reilly tradition, but is a little more intimidating, since you could use a copy to beat an elephant to death. "Killer" is a more recent book, and covers some aspects of Java 5.0 game development that Brackeen's book necessarily omitted. Both books also point out various commercial games, and games in development, that were written with Java. You're probably not going to end up writing a screaming, graphically stunning FPS with self-shadowing objects, etc., but since you're not EA, you can't afford to do that in your own time anyway. So why throw out your current skill with Java and learn C++ all over?
Re:I'm going to get blasted for this, but... (Score:2)
Typical Slashdot Advice (Score:3, Informative)
Core Techniques and Algorithms in Game Programming [amazon.com]. I own many game development tomes, and this one replaced 3 1/2 shelf feet of my reference material. This book contains everything the beginning competent programmer needs to get a quick start at programming any sort of game imaginable, and it covers topics from *useful* design patterns and data structures to shader programming.
Game Architecture and Design [amazon.com] is another good book, but is a survey of information from design patterns, architecture, game design/ludology, project management, and business practices in games. Probably up your alley but not exactly what you asked for.
As for an introduction to game theory, none is better than Rules of Play [mit.edu]. This book is the first extensive critique of the entire field of game theory as it is applied to game design that I have read. Lengthy, and it reads like a textbook (it was designed as one), but engaging.
bah. (Score:2, Insightful)
The other thing I found out was that
For test only (Score:1)