   Game Code Basics
  Hi,I'm trying to make a simple game engine, I got the basic layout done, but now I've some doubts of how to proceed... I'm using OpenGL for graphics, and I think I got the basic construction of it.So I'm working on a 3D Studio Max plugin that exports the data of all vertices into a .TXT file, and I intend to make a loop that reads the file and reconstructs the 3D model with OpenGL methods.For now, I'm saving only the X, Y and Z of each vertex in the .TXT file.After I get the loop that builds the 3D model, I'm thinking in getting each model a name in the 3DModel.TXT, and save it's position/status in another file, say... GameData.TXT.After this I'd get the engine to read from the GameData.TXT, look for the equivalent model in the 3DModel.TXT, and builds it in the position stated in the GameData.TXT.I'm new to game programming, but this sounds kinda heavy for the engine... is this viable? Is there any other way to do this? What's the best practice?   
  I'm not an expert so I can't exactly say what is a best practice, but you can ask yourself some questions.What is the desired goal of your engine?Is it a physics engine, or a rendering/object manager, or both, or something else?Do you want to eventually make this in to a game, or a part to be used later?As for the text file, is it a wavefront object? (*.obj type file) From what I understand a game will store maps, or levels, in a file with all the required information of the objects, their locations, routes the objects take, etc... and that gets loaded in to the engine which then begins to process everything once the player starts the game. Again, I'm not an expert so I could be way off base.;  First of all there is something I highly recommend you to read: write games not engines.I would refer to the processes you wrote about as model loading and loading of game data.Now for model loading what you are doing is a very good practice, however bear in mind, that it has been solved tons of times. A standard file format would be the Wavefront OBJ format which pretty much all 3D programs can export. So rather than writing your own export format, use that and try to parse it when loading. You also might consider use existing code, but that depends on what you are focusing on: a game (use existing library) or engine / graphics programming (do it yourself).As the latter might sound and feel as being more fun and that you might learn more by doing it, the process of your game will stall for all the time you are rewriting existing code. Additionally there is still a lot of work involved in understanding someone else's code and integrating that. You would also learn a lot about reading and understanding code by doing so.Concerning loading game data, your approach also sounds good and I would call it perfectly viable. Actually I find it very good to separate the information of the visual model, and the game logic model. Or what do you mean by it being heavy for your "engine"?In general: just try to get it working first and then see later when there is need for it on how to improve it. Don't fear to make some mistakes. You will learn as you code more and more.   ;After I get the loop that builds the 3D model, I'm thinking in getting each model a name in the 3DModel.TXT, and save it's position/status in another file, say... GameData.TXT.After this I'd get the engine to read from the GameData.TXT, look for the equivalent model in the 3DModel.TXT, and builds it in the position stated in the GameData.TXT.What you're basically talking about here is separating the graphics data of the model from it's in-game data such as position, orientation, animation, etc. This is good programming practice. The in-game data is usually bundled up into an Entity type object that will simply have a pointer or reference to the model that it uses.   ;  Text formats are useful when you want to read and modify the file using a text editor, but they are difficult to parse for a computer. Since you will probably never modify your meshes using a text editor, I think it's better to use a binary format to save your model data.   ;First of all there is something I highly recommend you to read: write games not engines.Good reading, I was expecting something else just to be surprised. Thanks for the link.The wording in my original post sounded misleading now that I see it, but I'm actually trying to get a game running. I had some experiences with XNA GameStudio and really liked it (it was what hooked me up in the programming world... I had that feeling of joy of seeing something accomplished that I had actually programmed), so I was thinking of how I'd get to that but with a C++ code.I would refer to the processes you wrote about as model loading and loading of game data.Now for model loading what you are doing is a very good practice, however bear in mind, that it has been solved tons of times. A standard file format would be the Wavefront OBJ format which pretty much all 3D programs can export. So rather than writing your own export format, use that and try to parse it when loading. You also might consider use existing code, but that depends on what you are focusing on: a game (use existing library) or engine / graphics programming (do it yourself).As the latter might sound and feel as being more fun and that you might  learn more by doing it, the process of your game will stall for all the  time you are rewriting existing code. Additionally there is still a lot  of work involved in understanding someone else's code and integrating  that. You would also learn a lot about reading and understanding code by  doing so.I stumbled on the OBJ format when I was reading about how to write a 3ds max plugin, but after seeing it, I got excited on how I'd make my own. I remember using an Exporter to .DTS files to use with TorqueGameEngine a few years back, so I always wanted to know how to create one.My final objective is to make a game, that I'm certain about, but I am curious on how I get a game running from scratch... I'd like to understand all the steps taken to each point, just to satisfy my curiosity. I always wondered how games get to the actual "game" state when all I know about programming is writing some line codes.Concerning loading game data, your approach also sounds good and I would call it perfectly viable. Actually I find it very good to separate the information of the visual model, and the game logic model. Or what do you mean by it being heavy for your "engine"?In general: just try to get it working first and then see later when there is need for it on how to improve it. Don't fear to make some mistakes. You will learn as you code more and more.By heavy I mean... since I don't have any experience writing any sorta of game engine or anything close, I'm not sure of what is considered to be heavy or light loading.I see people talking about system prereqs when developing games, but I don't have a clue on how they get to that.What I think is that a "loop that reads a file inside another loop reading from a file" sounds heavy when it comes to actually loading this data, so I was wondering if there is any other way or practice that developers usually do.I could get it working first, but I think I might get discouraged if I have to rewrite it because I went wrong in the basics... I'm looking for info on this, but all books/tutorials I can find only teach about either game design (no coding at all) or c++ programming...   ;I stumbled on the OBJ format when I was reading about how to write a 3ds max plugin, but after seeing it, I got excited on how I'd make my own. I remember using an Exporter to .DTS files to use with TorqueGameEngine a few years back, so I always wanted to know how to create one.I would start with writing a Wavefront object then if that is one of your interests. Once you understand the format of how it is loaded you can write one in a weekend easy. From beginning to end of understanding, to writing, to getting it working, might take some more time. I believe it took me a week or so when I wrote mine a few years ago.By heavy I mean... since I don't have any experience writing any sorta of game engine or anything close, I'm not sure of what is considered to be heavy or light loading.I see people talking about system prereqs when developing games, but I don't have a clue on how they get to that.What I think is that a "loop that reads a file inside another loop reading from a file" sounds heavy when it comes to actually loading this data, so I was wondering if there is any other way or practice that developers usually do.A heavy/light load is relative to the person. As you get more experience you will have a better feel for what you consider is a heavy load. No one can tell you what a heavy load for you is except for yourself. The best anyone can do for you is suggest what to do. Get a firm grasp on your abilities and understand them, then you'll have a good idea of what a heavy load for you might be. If you never wrote a game in your life, start with the basics such as pong, or pacman, or something similar. My first game was pong a few years ago. It helps give you a starting ground to expanding your own abilities.I could get it working first, but I think I might get discouraged if I have to rewrite it because I went wrong in the basics... I'm looking for info on this, but all books/tutorials I can find only teach about either game design (no coding at all) or c++ programming...Get it working first. There is nothing more detrimental to a beginning developer than taking on too much work. Once you know how it works, start to refine design characteristics. It's usually takes some work to getting the right balance of both. In the end, the one who gets it done is the one who gets paid, not the one who has a perfect design with no finished product.