Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology Entertainment Games

Getting Started with Game Development? 105

Posted by Zonk from the new-devs-in-the-making dept.
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."
This discussion has been archived. No new comments can be posted.

Getting Started with Game Development? More

Getting Started with Game Development?

Comments Filter:

  • Not a book, but... (Score:5, Informative)

    by Dial-Up ( 842218 ) on Thursday July 07, 2005 @06:17PM (#13008553)
    Well, this isn't a book, but just as good. The Game Programming Wiki [gpwiki.org] is a great resource for game programming in several major languages. There's also a very active message board that is extremely helpful.

  • Screw books (Score:5, Insightful)

    by RootsLINUX ( 854452 ) <{moc.liamg} {ta} {xunilstoor}> on Thursday July 07, 2005 @06:22PM (#13008610) Homepage
    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) [libsdl.org] 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!
    • I second the notion of just doing it (as I posted elsewhere in the parent thread). I also just wanted to chime in with my support for SDL as well. SDL is a wonderful platform for learning game programming as well as just messing around with OpenGL or 2D in general. SDL is not only available for several languages, it has a ton of plugins that do all sorts of things for you while adhering to an SDL-like API. This makes it very easy to add sound effects, do networking, draw text, etc. Much fun.

      • Re:Screw books (Score:2, Interesting)

        by stevey ( 64018 )

        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.

        • I would also suggest using OPAL [sf.net] (based off ODE) if you ever need physics. SDL will handle pretty much everything else. There are also some pretty nice pre-built engines like Ogre [ogre3d.org] and Crystal Space. There are alot of 2D ones... Whatever you code in, make sure it's multiplatform. C/C++ is good because you can compile it on just about any OS/machine and it's fast. Python [pygame.org]'s also pretty nice, but it's not quite as fast as C. For a simple card game or something it should be fine though.
          • "C/C++ is good because you can compile it on just about any OS/machine"

            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

    • I agree completely. The best way to learn to make games is just to do it. I recommend starting out with a scrolling shooter type of game, since they're pretty simple to write. You don't have to make your characters stand on the ground and not walk through walls and such. Make simple games first, until you get the hang of mapping controls to screen movements in an effective way, making enemies seek the player just right, and all the other fundamental tasks involved in constructing a game. The most important

    • 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
    • "Screw books" is insightful? Jesus.

      Those who do not study history are doomed to repeat it.
    • While I agree that hands on experience is important, do not underestimate the power of educating yourself. Writing a game might be about programming, but developing a game isn't.

      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)

    by BigZaphod ( 12942 ) on Thursday July 07, 2005 @06:23PM (#13008621) Homepage
    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.
    • The projects that the poster wants to work on sound like more of a showcase of gameplay rather than graphics. So, it might not be necessary to dive into linear algebra and x86 assembly just yet ;-)

      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
    • 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.

      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)

    by green pizza ( 159161 ) on Thursday July 07, 2005 @06:29PM (#13008690) Homepage
    What is your target? Do you want to write a game for a Windows PC? If so, then maybe you should look into C# and Direct3D. If you want a cross-platform game that you can compile on Windows, Linux, BSD, and Mac OS X, then look into SDL and OpenGL.

    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. html [textux.com]
    http://www.kekkai.org/roger/sdl/ [kekkai.org]
    • There's also pygame [pygame.org] which is a python interface to the SDL/OpenGL stack.

      Makes it easy to write some cool little games :)

    • 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]

      • Granted, but after a typical development time span (1-2 years for a small indie game), what will be the market penetration of .NET and DX9? If you've installed a new game over the last year, you probably have DX9. If you run XP, you probably have .NET. In two years this will be even more true, making this issue moot.

  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Thursday July 07, 2005 @06:31PM (#13008713)
    Comment removed based on user account deletion
    • FlashMX is expensive. I personally use Torque2d from Garagegames. Its in its "early adopter" stage, but its coming along nicely, and is usable enough for me. there are other 2d game engines out there (for people who are more interested in making games than writing the more boring parts of game engines). I forget their names at this moment. Several are free. If you went the t2d route, branching into garagegames' 3d engine would be simple (they share the same roots for their code base)

  • For OpenGL.. (Score:5, Informative)

    by BigZaphod ( 12942 ) on Thursday July 07, 2005 @06:32PM (#13008734) Homepage
    Possibly the best way to get started with OpenGL is the NeHe Tutorials [gamedev.net]. The articles are often written in a C or C++ style but most of them have been ported to tons of other languages and platforms. Check the ends of the articles for links to source for whatever platform you want to work with.
    • heh.. as I checked the link to the site I took a glance and suddenly found myself learning something new... how about that? :-) Ok, this is a mostly pointless comment, but I think it illustrates the usefulness of NeHe quite nicely!

    • Re:For OpenGL.. (Score:3, Informative)

      by The boojum ( 70419 )
      I'd also suggest the red book [amazon.com] as a companion/reference. The OpenGL consortium's site [opengl.org] also has some some documentation and tutorials (e.g. the spec downloadable in PDF form.)

  • 48 hour competitions (Score:1)

    by Anonymous Coward
    You don't have to start with them but they are good challenges and will probably help you feel more confident about your skills. You want to be able to build a skeleton game quickly so that there's something to play, not a case of "at some point in the future..." Forcing the time pressure will make you really seriously consider which pieces of technology are essential and which pieces aren't.

  • Game Production vs Game Design (Score:3, Insightful)

    by dacaffinator ( 750403 ) on Thursday July 07, 2005 @06:48PM (#13008904) Homepage

    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].

    • I've been playing with this [ogre3d.org]. So far I'm getting a nasty segfault that I need to debug, but there are lots of demos etc that are quite nice (just wish they'd fix the directory/hierarchy structure on the samples).

      Oh, and it works in both linux, windows, and Mac OSX....

  • SDL and patience :^) (Score:5, Informative)

    by swerk ( 675797 ) on Thursday July 07, 2005 @06:52PM (#13008942) Journal
    I've written a small game that some folks find addictive:
    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 .png and .ogg files directly... it just feels all warm and fuzzy :^)

    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!

  • Blatant Plug, but on Subject (Score:3, Interesting)

    by Xaroth ( 67516 ) on Thursday July 07, 2005 @07:03PM (#13009048) Homepage
    While my project is still in its beginning stages, you may wish to take a look at Improbable Drive [improbabledrive.com]. The basic concept is that I'm going through the game development process following formal techniques for project management, and documenting things as they go along.

    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)

    by ValiantSoul ( 801152 )
    Against some people's ideas, books can be a great way to learn (especially because you don't have to keep switching between programs, just keep the book on your lap). I like the OpenGL Superbible (ISBN 0672326019 or linky [amazon.com]) despite the name pissing me off.

  • Good introduction to game theory! (Score:4, Interesting)

    by MrDomino ( 799876 ) <mrdominoNO@SPAMgmail.com> on Thursday July 07, 2005 @07:10PM (#13009115) Homepage

    [...] Good introductions to game theory would be welcome, [...]

    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?

    • Nice questions, though the 3rd will turn into a flame war.

      The 2nd seems very obvious, maybe I missed something.
    • 1) prisoner's dilemma, nice. I first heard this talking about morality, weird to know the moral choice was to not admit to your crime.
      2) expected value for coin flip > 1, always take it ((50% * +50) + (50% * -25))
      3) flame wars...
    • Thank you mr. nash.

      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)

        by spectral ( 158121 ) on Thursday July 07, 2005 @07:34PM (#13009313)
        of course then I go and screw up #3. I should have said always switch, since you had a 1/3rd chance of being right when you chose your original guess, leaving a 2/3rds chance that you were wrong. Now the problem is reduced to two choices.. so you'd think that you'd have 1/2 chance of being right, but you don't.. the 2/3rds never went away, it just compressed down on to one door, so you should pick that.

        this site [uvm.edu] explains it better than I can.

    • Re:Good introduction to game theory! (Score:4, Funny)

      by JavaRob ( 28971 ) on Thursday July 07, 2005 @08:15PM (#13009649) Homepage Journal
      1) Prisoner's dilemma: It's not really probability (since the other guy isn't deciding randomly) but... Don't confess. If you do, and your buddy *doesn't*, you are out of jail immediately but you probably have only 6 years left to live. You're risking 6 years if he confesses, but you can hope the same fear will shut him up too.

      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!!"

    • f both of you confess, you both go to jail for 4 years. What do you do?

      Get the DA to agree, in writing to grant you immunity before you rat out your buddy.

      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.

      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.

    • This may seem silly, but it's really very important to keep things like this in mind when designing a game. Many games nowadays take more into account the technical aspects and forget the basical principles about gaming.
      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
    • Only the first problem pertains to game theory [wikipedia.org]. The 2nd problem is a probability/statistic problem and is a crippled version of the Envelope Paradox [wikipedia.org]. The third problem is another probability problem known as the Monty Hall problem [wikipedia.org]. It can turn into a game theory problem if the host is able to decide whether or not to offer the switch.

    • No fair! (Score:2, Insightful)

      by maiku ( 167604 )
      You stole that idea from the Dirty Bomb [tv.com] episode of NUMB3RS [cbs.com]!

  • Pygame. (Score:3, Interesting)

    by Zangief ( 461457 ) on Thursday July 07, 2005 @07:27PM (#13009265) Homepage Journal
    www.pygame.org

    The perfect way of starting a simple game.
    • Yes, spot on. If you're a Java programmer already then hopping over to Python isn't going to be huge jump. I'm surprised at the number of people suggesting SDL in here but I guess I shouldn't be- it's well documented and performs fast enough for anything you'll want to do.

      Plus, if I can do it [suttree.com], then you should have no problem :)

  • How about Flash? (Score:4, Insightful)

    by breon.halling ( 235909 ) on Thursday July 07, 2005 @07:32PM (#13009298)

    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)

      by tcopeland ( 32225 )
      > ActionScript has become o very powerful language

      Right on, and with the addition of a good open source component framework [actionstep.org], it's only getting better. MTASC + ActionStep == good times.
    • Guess what, lots of scripting languages are object oriented and very featureful. That doesn't mean they aren't scripting languages. Scripting isn't a bad word you know, python and perl seem to be doing pretty well for themselves.
      • If that's the case, then I fail to see the difference between a scripting language and programming language. Care to enlighten me, or at least point me in the right direction?
        • I seem to recall that one metric was whether the language could be used to write its own compiler. I don't particularly know how often that is still used, however.
          • Um, any turing complete language can be used to write its own compiler. So that's a completely useless metric. Now whether or not a scripting language's VM is fast enough to support compiler written in that language is another question entirely.
        • A scripting language and a programming language are not two different options, scripting languages are a kind of programming language. Scripting languages are high level languages that trade away execution speed in favour of programming speed, and are not directly compiled to machine code like a systems language (C, C++, ocaml, etc). Typically a scripting language can either be #!'d on a unix system, or is embedded in a program to let you customize that program (or both).
    • Flash is a good alternative, but just make sure you use Actionscript 2. The IDE is poor so use your own wherever possible.

      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)

    by AtariEric ( 571910 ) on Thursday July 07, 2005 @07:38PM (#13009346)
    Hire an already existing and out of work game programmer to program your game. We need the money!

  • Start here. (Score:2, Informative)

    by Anonymous Coward
    Start Here [gamedev.net]. Go there, read and do what it says.

    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
  • Here's a good start for you. Download the Enemy Territory Source Code here [splashdamage.com], and start tinkering with the code.

    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

  • OpenGL, SDL, DirectX, 3rd party engines, etc. are all well and good...but what about PHP? Particularly with AJAX, a whole new world of possibility exists. We're working on a RPG that does just this. While not graphic heavy, it does look nice and is amazing snappy even over a 28.8k connection. And there's no download.
    • Agreed. The invention of AJAX will bring a new era to web gaming; flash games where you can actually save state on server basically. When SVG comes to maturity, we'll see a lot of the lower class game citizens being reimplemented here.

      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
      • Our game is in a sort of early Final Fantasy style, but think more Wasteland. Still one of my favorite games.
      • I think we've got a Buzzwords victim here.

        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)

    by startled ( 144833 ) on Thursday July 07, 2005 @08:39PM (#13009806)
    If you're not already used to programming in 3D, it can take way too much time to ramp up, find an engine that works how you want, understand it, and so on and so forth. Writing a 3D engine is also a massive task, and will probably kill your interest before you get around to actually writing a game.

    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.
  • Surely not inexpensive, but it does a very good job of showing how to implement games in Java, including 3d-rendering...

    The Author's Website [brackeen.com] (Includes demo-project and source codes to all chapters)

    I'm not affiliated with this in any way :-P
  • Good books on Graphics are exceptionally hard to find. 3D math primer for graphics and game development by Fletcher Dunn and Ian Parberry is a rare gem. Starts off extremely simple and ramps up fast. It assumes you have some math expertise though.
  • Adventure Game Studio [adventureg...udio.co.uk] provides an extremely simple way of doing old-style adventures quickly and has an active community behind it, which is rather friendly.

  • You're in luck! (Score:2, Informative)

    by Digital Vomit ( 891734 )
    Slashdot just posted another story [slashdot.org] about a great developer tool you can use to get started in your game programming career!
  • GameMaker [gamemaker.nl] is an excellent tool for learning about making your own games. It handles all of the low level things like graphics and audio for you so you concentrate on actually designing the game. It was mainly for learning 2D programming, but with the most recent release, Mark Overmars added some 3D functionality and its quite amazing what people have done with it. It is also quite cheap shareware (about $20 or so) and you can still use most of the functions using the free version.

  • Quick and easy (Score:2, Informative)

    by owlman17 ( 871857 )
    Yes, it wouldn't do any harm to brush up on your C++ skills. If you don't have a C++ compiler yet, get Dev-C++ http://www.bloodshed.net/devcpp.html [bloodshed.net]

    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)

    by tansey ( 238786 )
    For a generic book on game programming, check out Andre LaMothe's book Tricks of the Windows Game Programming Guru's [amazon.com] (assuming you're developing for windows...and if you're trying to find a decent sized audience, you really should be) That provides the technical introduction you'll need, from COM to DirectX. Note that you can skip a lot of it if you're a seasoned windows developer. If you're not though, this is the best book to start with IMO, since it has a great windows primer.

    When it comes time for yo

  • J2ME is fun! (Score:3, Informative)

    by llamaluvr ( 575102 ) on Thursday July 07, 2005 @10:10PM (#13010321) Journal
    J2ME (I mean, provided you have some portable device to really use it on, instead of just a lame cell phone emulator or whatever) is rather fun to program in. When I did it for a class, I did not program a game, but my program was relatively similar in terms of what I used from the language (it was a baseball-game scorer). Doing the UI was a snap. J2ME offers graphical/ interface program that is not only ideal for a cell phone/ PDA, but because of those concessions, it's really easy and straightforward and cool, because the interfaces are flexible and they do what you'd expect them to- MUCH better than Swing/AWT. I don't feel like writing a book, but, let me tell you, the stuff inside J2ME (from the graphics to the internet stuff, etc) is very helpful for writing games. The only annoyance was losing random (non-UI related) libraries that you had in normal Java for no apparent reason. By and large, I liked programming in J2ME as much as I do in VS/#C/.NET, and I really enjoy doing that.

  • Realm Forge (Score:2, Informative)

    by cfavader ( 754724 )
    From the site: [ http://realmforge.com/ [realmforge.com] ] """ The RealmForge GDK is the cross-platform game development platform for .NET. It is written entirely in C# to ensure portability and allow the productivity, flexibility, and dynamic nature of the .NET Framework to be leveraged in all aspects of game development. This middleware is architected with both power and ease of use in mind and is released under the LPGL so that it is the free and ideal solution for both commercial and hobbyist projects. This gam

  • 10 Resources You Can't Live Without (Score:3, Informative)

    by MiceHead ( 723398 ) on Thursday July 07, 2005 @11:04PM (#13010598) Homepage
    There are, nowadays, enormous piles of resources for those starting out in game development. Some suggestions as to where to start...

    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:
    • Torque2D [garagegames.com] - GarageGame's upcoming 2D tiling engine SDK. This looks promising, but is in its early-adopter release. Not yet ready for primetime, according to GarageGames.
    • Pygame [pygame.org] - Python [python.org]-based 2D engine. My feeling is that Python is a great language to start game development in.
    • Orbforms Designer [orbworks.com] - Why limit yourself to the PC? PDA games can give you a greater return on your time than Windows games do. (Per man-hour, our PDA titles bring us more revenue than our PC titles do.)
    • Game Editor [game-editor.com] - For those who want to go even higher-level than an SDK.
    So you want to write a 3D game! Try one of these:
    • 3D Gamestudio [conitec.net] - The engine of choice for our latest [dejobaan.com] games [dejobaan.com]. I love it, and hope they'll extend to the Xbox 360 platform when it comes out.
    • Torque [garagegames.com] - Maybe the single most popular 3D engine among indies and hobbyists. Focuses, in part, on cross-platform compatibility (Windows/Linux/Mac).
    • OGRE [ogre3d.org] - An open-source package. Frequently updated. Some nice projects [ogre3d.org] using the engine.
    • DarkBASIC [thegamecreators.com] - A popular package among new developers and independents.
    Also check out what kind of games independents are making now:
    • Game Tunnel [gametunnel.com] - Previews, articles, and reviews of indie games.
    • DIY Games [diygames.com] - Covering the latest independent/shareware titles.
    And ignore anyone who says that you should start off by developing something simple. It's good advice, but nobody ever listens to it.
    ---
    Inago Rage [dejobaan.com] - Create and fight in your own FPS arenas.
    ---
  • Check out our 2D game framework and real game samples, available at http://developer.popcap.com/index.php [popcap.com]. We've used and continue to use this framework for all our own games. Nearly all the hard technical issues you'd need to tackle have been solved here, so you can really put your focus on game design. There's a pretty active community of people on the Popcap Developer Forums who can help you out too. Best of all, it comes with one of the most free and open open-source licenses out there. Give it a shot!
  • If you really want to learn about the video game industry, get a job. Expect to work 80+ hours per week for months on end, living off junk food and soda, and maybe seeing family once a month. Get treated like trash by people in management who whould be taken outside and shot if they weren't in the video game industry. Mandatory retirement age is at 30. So enjoy it while it last.

    Seriously, working in the video game industry is a lot harder than playing video games at home. I spent six years working in the
  • I was in the same situation a couple of years ago.

    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
  • There are plenty of tools & materials on the net for programming the Gameboy Advance. As a plus it is a pretty simple platform, as is probably good for starting out. You can compile to a rom file & run on an emulator & You don't need the actual SDK, which is probably pretty pricey.

    If you come up with something cool its easy to just send a demo rom to a dev house.
  • SourceForge has a lot of open-source game projects now, and many of them are quite good.

    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)

    by slapout ( 93640 ) on Friday July 08, 2005 @09:32AM (#13012864)
    Many people have mentioned SDL. You should also check out Allegro. It's a multiplatform game programming library.

    http://www.talula.demon.co.uk/allegro [demon.co.uk]
  • If you already know Java and you've never written a game before, I wouldn't bother investing in a book right away. I bought a book about game programming in Java (coming from a C++ background) when I started my second game project [sourceforge.net] and found it totally useless. With your first game, the most important thing to do is to restrict the scope. Your eagerness could very easily impell you to start a project you will never be able to complete (this is why my first project flopped). Pick a 2D genre that doesn't requi

  • Clickteam Products (Score:2, Interesting)

    by Quincysan ( 884015 )
    As an IT professional with not a whole lot of time to miff around, I prefer using Multimedia Fusion, a product created by Clickteam. You might have heard of their more popular install maker program.

    www.clickteam.com
  • A lot of game programmers hang out at flipcode.com They also have tutorials and other resources.

  • I'm going to get blasted for this, but... (Score:3, Informative)

    by MmmmAqua ( 613624 ) on Friday July 08, 2005 @04:40PM (#13016504)
    You CAN develop modern, well-performing games in Java. Since you already have a good Java skillset, try these:
    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?

  • Typical Slashdot Advice (Score:3, Informative)

    by SteevR ( 612047 ) on Friday July 08, 2005 @05:32PM (#13016909) Homepage Journal
    Very few responses have actually answered this guy's first question: "What books would you recommend to a beginning game developer?"

    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)

    by sinserve ( 455889 )
    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
  • hello, this is a test! http://example.com/ [example.com]

Slashdot Top Deals

All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin

Close