   Short Questions With Long Answers!
  I've been programming for a while, but not using any graphics really. I know the road is long, and I can tell I'm gonna need to commit a bit more to really get into game making, as a hobby that is. I was just wondering about a few things like:1. I've read a bit about OpenGL, it directly communicates with your graphics card right? Can you make a 3D game with OpenGL by itself. Don't you need a 3D Engine to make a 3D game (like 3DS Max).2. When making a game, say a 2D RPG, how do you make the computer identify between the source code you've written and the item in a game, say a chest? How does the computer know (sorry that I sound oblivious) that you open the chest and not attack it?Thanks in return. It can't be easy answering newbie questions.   
  1. OpenGL itself is enough to make a game. A graphics engine is not required but it presumably will make it easier to write a game.2. That really depends on how you write the game. You need to write the code so that the program can distinquish between a character attacking a chest or opening it. This could be done by making seperate key presses for each command (press a to attack and o to open).As a side note, most RPG's use some form of scripting language to handle most of the game logic.   ;  Careful not to confuse 3d studio max with a graphics engine you can implement in the game.  It only creates a model which is saved and then loaded by opengl.  Opengl actually has all of the functionality to allow you to create the exact same model you made in 3dstudio max, however nobody would want to do it by hand because millions of GLTriangles would be a pain to manually set up...  That said, you can do terrain generation and such purely with OpenGL (or directx really, both packages are equivilant graphics wise.)Ogre is an example of a 3d engine you can use in game, 3ds Max, blender, Maya, milkshape 3d are all examples of modelling programs (they do have 3d engines, but you certainly don't use it directly in your program.)Google NeHe and start reading tutorials and come back with more specific problems and we can help you from there.  That's assuming you have a very solid foundation with C++ or C first.2. Just because you enter the realm of graphics does not mean you leave behind every shred of programming experience that you have.  You're going to have to create structures that keep track of what objects are, where they are, and of players and monsters and other things.  You'll also need methods for checking player position vs those objects and can then decide what functions to call when you detect a collision.  Collision detection depends on what you're testing so it's hard to just say here is "X" algorithm, go code.  Bounding boxes and spheres are typical though, especially in 2d games (not spheres, circles) so that's one option.  To set up a bounding box it has nothing to do with opengl, you keep track of that stuff.Basically, you're still going to have to set up code around everything to keep track of where it is and what it's doing and where to display it and EVERY aspect of that except that opengl will do graphics for you based on what you store.  Now, that being said this is where a graphics or game engine comes into play.  Sometimes they have collision detection and they definitly should have object classes that have all of this information in well defined structures for you.  It really depends on if you're building from scratch or using an existing engine.Think that you're storing X, Y, Z coordinates in your own c++ code (hopefully abstracted on higher levels, but still visible for calling) and that should help... Opengl doesn't do all the work for you, it just does all the drawing.Think of it like a paintbrush.  You have something planned in your head as far as positions of where things should be and how they should interact.  Your head is the code.  Now think of the paintbrush and paint as opengl.  That's a really abstract and odd analogy, but hope it helps.   ;Quote:Original post by ozzoright1. I've read a bit about OpenGL, it directly communicates with your graphics card right? Can you make a 3D game with OpenGL by itself. Don't you need a 3D Engine to make a 3D game (like 3DS Max).OpenGL is a library which allows you to bridge the gap between "I have some data that represents the shape and positions of objects in the game world" and "I have a window and I want to draw the game world in it". You still need to have data to represent the objects, and you do that by programming stuff yourself. 3D engines are other libraries of code designed to simplify that process - e.g. by giving you classes to represent common things you might want to exist in your world, and handling some of the data manipulation (e.g. changing positions of stuff). 3DS Max is not an engine, but a modelling tool. It is designed to let you draw some object, and produce a data file with "raw" information about the shape of the object. The engine might for example be responsible for reading the data file, creating some data structure to represent the object's "geometry", and making calls to the OpenGL functions to draw the object. Among other things. 3D programming can get ridiculously complex - to the point that one can fairly easily find what I'd consider embarrassing bugs in AAA titles.Quote:2. When making a game, say a 2D RPG, how do you make the computer identify between the source code you've written and the item in a game, say a chest? How does the computer know (sorry that I sound oblivious) that you open the chest and not attack it?This is the process of "modelling". You write code to define a data structure that represents the chest, and the things that are interesting about it - for example, the material it's made out of, some identification of the geometry that it has, its current state (locked/unlocked/open), its contents etc. Then you write code that accepts this data structure as input and modifies the structure, possibly returning something as output. In object-oriented programming (which is probably the best approach for this particular task), you can define the "methods" as properties of the data structure itself, so that the "input" of the current object is implicit.Corresponding to the notion of data structures is the notion of algorithms: the processes that the code in question follows. For example, if our chest has the behaviour "grabTheContents", then we produce as output the object that was contained (or possibly "nothing"), and modify the state of the chest. The algorithm is like this:- If the chest is not OPEN, then yield nothing as output.- Otherwise:  - Put the contents off to the side temporarily (so that we don't lose track of it).  - Set the chest's new contents to nothing.  - Yield the old contents as output.Similarly we can define methods for (un)locking the chest, opening, closing etc.In Python, this may look like:class Jewel: pass# We can worry about what's interesting about the Jewel later. For now, what# we care about is that a Chest might contain one.class Key: pass # Similarly.class Chest:  # We will use plain numbers to represent states.  OPEN = 0  CLOSED = 1  LOCKED = 2  def __init__(self, key):    # A Chest always starts out being locked and containing a Jewel.    self.contents = Jewel()    self.state = Chest.LOCKED    # We will also remember the Key which opens this chest.    self.myKey = key  # Unlock the chest, if the provided key is the right one, and the chest is  # currently locked.  def unlock(self, key):    if key is self.myKey and self.state == Chest.LOCKED: # We have the right one self.state = Chest.CLOSED    else: print "Couldn't unlock the chest."  # Lock the chest, similarly.  def lock(self, key):    if key is self.myKey and self.state == Chest.CLOSED: self.state = Chest.LOCKED    else: print "Couldn't lock the chest."  # Opening and closing don't involve a key.  def open(self):    if self.state == Chest.CLOSED: self.state = Chest.OPEN    else: print "Couldn't open the chest."  def close(self):    if self.state == Chest.OPEN: self.state = Chest.CLOSED    else: print "Couldn't close the chest."  # Remove stuff and get it, if it's there.  def grab(self):    if self.state == Chest.OPEN: result = self.contents self.contents = None return result    else: return None # Can't get anything out of the chest without opening it firstNow we have something we can play around with:(Save the above in a source file, then edit it with IDLE, then run it: those class definitions are now loaded and you can play around with them at the interpreter prompt as follows)>>> silverKey = Key()>>> silverKey # Ok, make sure this is a key<__main__.Key instance at 0x00CE6AF8>>>> woodenChest = Chest(silverKey)>>> woodenChest.state # It will result in 2, which means LOCKED2>>> woodenChest.myKey # Make sure it wants the silver key<__main__.Key instance at 0x00CE6AF8>>>> woodenChest.unlock(Key()) # fails because that's a different keyCouldn't unlock the chest.>>> woodenChest.unlock(silverKey) # This will work>>> woodenChest.state # Now the chest is CLOSED1>>> woodenChest.open()>>> woodenChest.state # Now the chest is OPEN0>>> woodenChest.grab() # We should get the Jewel.<__main__.Jewel instance at 0x00CE8058>>>> woodenChest.contents # Prints nothing because it is empty ('None')>>> woodenChest.contents = silverKey # not all languages would let you do this!# In C++, if you say the chest holds a Jewel, then the compiler won't let you# tell it to put in a Key. Then again, in C++ you don't get this interpreter# shell anyway>>> tmp = woodenChest.grab() # now 'tmp' is an alias for the silver key:>>> tmp<__main__.Key instance at 0x00CE6AF8> # See? Same object ID.>>> woodenChest.lock(tmp) # Fails because we have to close it firstCouldn't lock the chest.>>> woodenChest.close()>>> woodenChest.lock(tmp) # A key by any other name would lock as soundly...>>> woodenChest.state2