I've started working on my first major project, an adventure game called Testament. For the past month or so, I've been writing the design document for the game. I have a team writing a story, the plot, and puzzles (normal for an adventure game). But here is my problem, I've never done code for a program/game that would require multiple .cpp files. Also, should I write parts of the game as libraries (such as a library for the graphic handler, room information, sound, whatever...) and try to keep my .exe small or should I keep the whole program as one big .exe (including everything, even resources). All the games I've ever played, commerical ones that is, all have at least a dozen files when they are installed - some have hundreds (guessing those are just resources). How do you all recommend going about organizing a project like this? Just for the record, I am using VC++6. Thanks a lot! Edited by - Coaster Kev on 11/14/00 8:52:35 PM

It kind of depends on you if alot of files dont bother you than use them if not then pack a whole lot of functions in a few files. The way I would do it is, put my bitmap minipulation code in a library everything from loading bitmaps to unloading them. Then make a library for your sound and input. Then I would make a library just for the game itself lev1 lev2 and maybe even seperate that into even more files. just dont get confused

Ok, to seperate your files up, what I usually do is make a .h file named after the class that I will insert into that file, for instance, my surface class will go into Surface.h (just the interface, not the methods, you know the "class CSurface..." part. Then, I put member functions into a .cpp file named after the class, such as Surface.cpp. At the beginning of Surface.cpp, I put #include "surface.h", and then whenever i need a Surface, I just do #include "surface.cpp", and all is well in the world. If I were you, I wouldn''t worry about .exe size. H.Drives are big enough so that you don''t really have to worry. Although, bandwidth could be a problem, but it''s not so bad anymore. So don''t worry about it for now. Anyways, just using a .lib will not decrease the size of the .exe, it will be the same, the only difference is how you got the code into the exe, typed or loaded from a lib. to decrease .exe size, use a .dll, but that can be a pain. Just don''t worry about it for now. Oh, and if you use seperate files, which I recommend, keep similar things in the same file, and give each a general, but descriptive name, such as Globals.h, Game.h, Constants.h, Macros.h, Main.h/cpp, Typedefs.h (I like to use Types), get it? Another thing. I know it may not have occured to you (this is how i started out, too) but it makes everything REALLY difficult later on, to change your game at least, if you put Level info, and character traits/stats, etc, into your source. If you can, or you think you can learn how w/o much effort (haha)(not to say it''s hard...) learn how to load in that sort of stuff from files. read the tuts on scripting, and try to pick up some ideas. maybe make a simple asteroids clone using files, instead of hard-code. later.
farmersckn

Call me the extreme newbie, but is there anything I should know about using multiple .cpp''s? I tried to access a class from one .cpp in my main and the complier gave me "undeclared class/namespace" errors. So, I tried to include it "#include " and I got an error about the class already being defined. Argh! Probably something simple.

At the very top, the first line of code, add the following to your header files.

  #ifndef _CLASSNAME_H_#define _CLASSNAME_H_//Include your class declartion here. #endif  

I have seen dynamic libraries used frequently in a game. They are used so that when you need to make a modification to the code of the library, you do not need to recompile your executable, simply restart it. It makes patching a program much easier, as you do not need to send all the files, simply the patched dll.

If I were you, I wouldn''t start out putting everything in DLL''s.
Neither should you need to put stuff in library''s unless you use a lot of functions in multiple .exe files. Otherwise, you should just add them to a single Visual Studio workspace and compile your program into a single .exe file.

You can just put all your resources (graphics, sound, levels) in a seperate directory which makes loading and saving easier and also keeps your code and data seperated a bit. Don''t worry too much about having hundreds of files.

If this is your first real project then its probably smart to get some basic reference books on C and C++. Perhaps you''d want to stay away from C++ for the time being because making C++ code is a bit harder. Simple C code that gets the job done beats a supercomplex C++ system that doesn''t work. (duh)

So, in short my advice is: K.I.S.S (Keep It Simple Stupid!)

Good luck with your project

First off, the only reason to avoid C++ is your skill set. The C++ language (classes, inheritence, overloading) allows for another level of abstraction which can be taken advantage of by skilled developers.

Partitioning of your software is a graet question. It''s not just how to organize your code "physically'' (source and binaries/librarie types), but how to partition the functionality. It makes perfect sense to have .cpp and .h files devoted to classes and to possibly have utility libraries. But, how are you going to partition your application. It makes absolute sense to isolate the functionality of your application in layers or components which are dedicated to some aspect of your application, making the interfaces between components independent of the implementation. Consider the concept of class implementation isolation and apply it to your application components. If it''s a network app, hide how it works and make the interface as generic as possible so that you could replace the component with another physical interface type (LAN/WAN versus modem connection). How can you make your app work with OpenGL and DirectX? Hide the rendering of your world inside a rendering component. Do not let the overall application "know" (and take advantage of) the implementation of lower level functionality.

One last comment with regard to code organization on the same line as my last comment. Layer you app implementation so that the code is readable and on a consistant level. Your code can (and should) read like a book. At the topmost level, your coide and comments should bre addressing high-level app issues (initlization, processing and shutdown). The next, lower level, should be high-level implemntations of the above functions, not bogged down with lower level details. Keep the level of "abstraction" consistant by pushing implementation details down to the level where they will naturally occur. I find this works well.

Although what I have said may be obvious or considered unecessary, I have spent lots of time working on existing code that has been partitioned and implemented poorly causing lts of work to understand the implementation and enhancing it.

Good luck,

TheViper

Comment and document.

Write code you can read, and if you are working with a partner, make sure to agree on a style both of you can read.

Dont optimize until its nessicary.

-----------------------------
First off, the only reason to avoid C++ is your skill set. The C++ language (classes, inheritence, overloading) allows for another level of abstraction which can be taken advantage of by skilled developers.
-----------------------------

Yes, and a skilled developer can take advantage of C''s lack of it. But thats not an argument, its Coaster''s choice.

-----------------------------

A wise man once said "A person with half a clue is more dangerous than a person with or without one."

The Micro$haft BSOD T-Shirt

Coaster:

If you have a global variable containg the class in another file, ie:

// in file myclass.hclass CMyClass {  // whatever};// in file myclass.cpp#include "myclass.h"CMyClass  varMyClass;  // declare new variable containing class// and in your main.cpp file#include "myclass.h"extern CMyClass varMyClass; 

Note the ''extern'' keyword, this will make the ''varMyClass'' avalible in the main file.

ALSO: make sure that you''re #including the .h file in the main file, and that the .h file has the ''class'' bit in it. I see that ''farmersckn'' made a typo and suggested that you should #include the .cpp file - this is wrong, only #include the .h files!

Thanks for all the replies.

I''ve been programming in C++ for about 6 months, and I''ve been trying to work out the details of inherience and all that OOP stuff.

I''ll keep you guys updated. Just glad that I can ask a question here and get replies within maybe an hour or so (if not sooner). Thanks again.