Slashdot Mirror
Getting Started with Game Development?
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."
I have never been a fan of learning how to do something by reading about it. The only way to learn good game programming, IMO, is to actually try doing it. That's how I started with the game in my sig and its been working so far. While not a book, may I recommend you take a look at the Simple DirectMedia Layer (SDL) library? It's free, cross-platform, and is really easy to learn to use. It's written in C, but there are extensions to it in other languages. Good luck!
Hero of Allacrost, a FOSS RPG for *NIX/*BSD/OS X/Win
I toyed with this myself. In my experience, it isn't the technology that's hard. Simple games like you're talking about aren't much different from any other apps out there, so just dive in and do it in whatever language you want to use. It doesn't take some kind of special training to code a card game if you already know how to do GUI programming.
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.
Hexy - a strategy game for iPhone/iPod Touch
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
Out of the books listed there I highly recommend Game Architecture & Design.
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.
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, which, ironically, has been turned into a full-fledged console game.
That's just my two cents, at any rate.
"Yeah, well, Dracula called and he's coming over tonight for you and I said okay."
You stole that idea from the Dirty Bomb episode of NUMB3RS!
I have really tried to learn game development. I am a relatively experienced programmer so I picked up OpenGL and with in three months I was writing useful "applications" but no games, that's because games are more than code. I can show case some great demos; I can model a shape with triangles, skin it with a texture, give it a good shading, put it all in a display list and have it run an optimum speed. But I can't write pacman to save my life. I have no artistic talent.
The other thing I found out was that game programmers in general are very specialized to games programming and have no knowledge of other domains. I met some competent game hackers who have never used a unix variant, or who have never writen code in anything other than C++ who don't know of the freely available tools. Most game programmers seem too narrow in their knowledge of programming. I once shared an array implementation of a binary search tree with a few hackers on IRC and they had no clue what it was supposed to do. Those same guys are comfortable implementing a BSP if needed be.
Culture wise I found game developers too young and naive to work with, and I later found out that graphics programming was not my cup of tea and I much prefer writing shell-code.