   Know how to program but new to game programming
  Hey everyone,I'd like to start programming games, but I'm having a little bit of trouble deciding how I should go about it. I don't want to make anything terribly complex, although eventually I would like to make a Super Smash Bros clone (meaning 3d programming as well). But for now I would like to start off making 2d games. Here is my dilemma, I know Ruby, Python, Java, and C++ about the same, which is to say, I have a working knowledge of each (not an expert by any means). Though I know Ruby best. My question is, which one of these would be best suited for programming games as a hobby?I'm not looking to get into the gaming industry, and the game has to be able to run on Linux and OS X. In terms of development time, execution speed, resources, and cross-platform compatibility, which would be the best choice? I'm reluctant to use C++, and I think that Python and Ruby will be too slow, so I'm thinking Java for now. But I am hoping you guys would know this much better than I do and would be able to point me in the right direction. Thanks :)   
  Hey, I don't have any experience with Python or Ruby.  However, I do have experience in Java and C++.  When I started programming games I knew Java a bit more than C++ so naturally, I chose to program games in Java.  After a while I decided to switch to C++ just for fun, to get more experience with some features that don't exist in Java.  Now, I'm no expert but i've written a couple of 2D games and I'm working on a basic 3D engine in C++ right now.  What I can say is that Java was actually harder all around for games programming.In Java I used AWT for 2D and tried both LWJGL and JOGL for 3D.  In C++ I used OpenGL coupled with SDL.  The Java Graphics 2D API is a lot more trouble than SDL to set up in a way that's suitable for games programming.  JOGL and LWJGL are poorly documented, overly complicated in an attempt to be OOP, not fully featured and even have a few bugs compared to native OpenGL (JOGL is abandoned now too, I believe).I would advise that you choose either Python or C++.  I've heard good things about Python and apparently it has some good libraries for game development.   ;  Python or C++ would also be my choice. Although I would be careful on your choice of a clone/remake. I thought that game would be under Nintendo, who if I am not mistaken are very strict with these things. You might end up receiving a cease and desist letter, but I might be wrong. But please check up on this before you do anything as it can cause a whole lot of hell later on :)   ;  If it's hobby programming I'd go with what you know best. [The law here is to produce and get your program to be distributable. Too much vaporware.]For Ruby, check out gosu. For python, check out pygame or pyglet. These are good for 2d things. In addition to this there is Panda3D for 3D game development using python.That's assuming that if you want to stay with what you know best. If you are willing to leap a little, you may also want to check out C# and xna. It's similar to java and has a good IDE and library/tools ready to go. I think this is a good option too.So basically, I'd recommend Panda 3D for 3D programming with python, or go the C#/xna route.   ;  I second the advice to stick with what you know. Most games are just realtime applications; provided your language can handle that, and provided it's got some appropriate libraries/APIs, then you can use pretty much anything.Why do you think Python or Ruby would be slow?   ;  These are exactly the kinds of things I wanted to hear, thanks. I've had a bad experience with Python/Pygame, so I'm not sure if I want to go back there. It was probably bad programming on my part, but the game felt like it was hacked together. I'm now leaning towards C++, mainly because of the resources available. What I need to learn is how games are constructed (simply learning an API won't do me any good). This widens my choices, but as of now I am only aware of SDL and OpenGL (I am running Ubuntu as my main OS). Is it possible to make 2d games in OpenGL, and would anyone recommend it over SDL? What else is out there?   ;Quote:Original post by sam191What I need to learn is how games are constructed (simply learning an API won't do me any good). Games are constructed just like any other program: come up with a good design and implement it using the proper and most efficient tools to accomplish a goal. Games are mostly real-time applications. So there will be an update loop. In this update loop, you must write code that will acquire player inputs, update game logic, and then render the result. Personally, I use a modular design and write classes to take care of all these things. It works nicely for me.So that's it a simple way to construct a game. If you haven't already, why not make a few simple games before you move on to more complicated projects? If you made nice polished clones of tic-tac-toe, tetris, pac-man, as a quick series of practice projects, you would understand completely on how to construct a game. Then you can extend these principles to your more complicated 'dream project'.Quote:Original post by sam191This[C++] widens my choices, but as of now I am only aware of SDL and OpenGL (I am running Ubuntu as my main OS). Is it possible to make 2d games in OpenGL, and would anyone recommend it over SDL? What else is out there?So now you want to use C++? Yes, it is possible to make 2D games using openGL. To use opengl, you need to create a window. So many people, myself included, use SDL to create an openGL window. So you can use SDL to acquire user input, create the window, process sounds if you want, etc., but you use opengl to render.As for your last question, what else is there? Well, there's lots. It doesn't really matter what one recommends. For C++: Ogre3D, Irrlicht, Haaf's Game Engine, Esenthel Engine, Lightfeather, SDL, Allegro, etc., etc. The thing is pick something and get started. Make tic-tac-toe, tetris....So if you want C++ then SDL is fine. SDL using opengl is good too, more complicated, but you will have nice opengl rendering.   