Need help coming up with a project skeleton
I have been programming for 4 year now in c++ and asm now. I have played around with directx and windows programming.
i have tried making games but I always get stuck on how to structure them and setting up the project tree and how to divide it up into different files. Hope someone can understand what I mean a and can give me some insight.
Just create some classes that encapsulate the basic operations like a Grapics class that does all the ddraw functions and a Sound class that does all the soud things. Its called Object Oreinted Programming or OOP
I understand what you mean...The structure of the program is the hardest part in my opinion....
Can´t really give you any tips because I suck at it myself.
Well, for the files, I use the "each class has its own separate header and .cpp file" rule.
When I start a project, I first decide what I'm going to do and sketch out the game concept. Then I write down everything the game will need, and group things together in blocks. For instance, everything having to do with a character would be one block. Everything having to do with an item would be another. Everything having to do with sound, yet another. Then I take these major blocks and start breaking them into smaller blocks. For instance, taking the "character" block, I will make a block for sprites, a block for items he can carry, a block for items he can wear, etc. I would take the "items" block and create a class out of it, and create a character class, and give the character class an instance of the items class. The "entire world" block would probably also want some "items" so that it can hold stuff that the character hasn't picked up yet.
You might want to take a look at a few class diagram/UML tutorials on the web... it's a lot easier to conceptualize the object portion of your code if you can draw it (it is for me at least).
-fel
Edited by - felisandria on 4/25/00 1:45:52 PM
When I start a project, I first decide what I'm going to do and sketch out the game concept. Then I write down everything the game will need, and group things together in blocks. For instance, everything having to do with a character would be one block. Everything having to do with an item would be another. Everything having to do with sound, yet another. Then I take these major blocks and start breaking them into smaller blocks. For instance, taking the "character" block, I will make a block for sprites, a block for items he can carry, a block for items he can wear, etc. I would take the "items" block and create a class out of it, and create a character class, and give the character class an instance of the items class. The "entire world" block would probably also want some "items" so that it can hold stuff that the character hasn't picked up yet.
You might want to take a look at a few class diagram/UML tutorials on the web... it's a lot easier to conceptualize the object portion of your code if you can draw it (it is for me at least).
-fel
Edited by - felisandria on 4/25/00 1:45:52 PM
Thanks for the assistance. I would like more comments on the subject. I understand OOP and messed with it since i have started programming.
Well, here''s a quick guideline I came up with: write down how your game works -- as design doc. Don''t put any code in the design doc, just the structure of how it must work together. Then take the nouns (classes), verbs (functions), and adjectives (data) from the design doc, and make them into classes. If you have trouble or something is outright impossible, post about it. Most often, though, you are not understanding an important concept correctly.
Remember: coding is a continual learning process.
SOME RULES OF THUMB FOR DESIGN
Most important thing here is: start small! Build small classes (as small as you can get them and still accomplish their purpose), then make bigger classes that manipulate them. Build a class to load and convert bitmaps easily, then it will be much easier to manage and cache sprites. Don''t try to write the SpriteManager before the Sprite!
By the same token, you will need to know a little of how the SpriteManager works while you are building the Sprite class. So, you will need to keep re-designing both while you are writing them. Try to keep an ordered method for changing things, and comment well. (They pay huge dividends when it comes to finding bugs.)
If you have lots of switch statements or 200 line functions, then you are trying to stuff everything into a "do-everything" class. That''s a clue that you need to break it up into smaller classes.
Also, if ever you find that you cannot code what you are talking about (i.e., it is impossible), then either you don''t know enough about what you are coding or you have misunderstood how it works. Head back to the ''net and find a tutorial that explains things. (You will find this like 20 times a week at first ).
Several small classes are more easily used than one large class. (What could be easier than pSoundManager->Play(Sound) ?)
Small classes are much more easily debugged than their larger counterparts. Write one, debug it, and it''s done for the remainder of the program. Rinse and repeat.
- null_pointer
Sabre Multimedia
Remember: coding is a continual learning process.
SOME RULES OF THUMB FOR DESIGN
Most important thing here is: start small! Build small classes (as small as you can get them and still accomplish their purpose), then make bigger classes that manipulate them. Build a class to load and convert bitmaps easily, then it will be much easier to manage and cache sprites. Don''t try to write the SpriteManager before the Sprite!
By the same token, you will need to know a little of how the SpriteManager works while you are building the Sprite class. So, you will need to keep re-designing both while you are writing them. Try to keep an ordered method for changing things, and comment well. (They pay huge dividends when it comes to finding bugs.)
If you have lots of switch statements or 200 line functions, then you are trying to stuff everything into a "do-everything" class. That''s a clue that you need to break it up into smaller classes.
Also, if ever you find that you cannot code what you are talking about (i.e., it is impossible), then either you don''t know enough about what you are coding or you have misunderstood how it works. Head back to the ''net and find a tutorial that explains things. (You will find this like 20 times a week at first ).
Several small classes are more easily used than one large class. (What could be easier than pSoundManager->Play(Sound) ?)
Small classes are much more easily debugged than their larger counterparts. Write one, debug it, and it''s done for the remainder of the program. Rinse and repeat.
- null_pointer
Sabre Multimedia
quote:Original post by null_pointer
Several small classes are more easily used than one large class. (What could be easier than pSoundManager->Play(Sound) ?)
Aaahhh! Don''t say that! My SoundManager->PlaySound() function gave me Substantial Grief (see Pure Virtual thread on this very forum)
Joking aside though, I find it easier to split the game up into AI, Graphics, Sound, Input, Networking, etc. Then think about making sure these components interact as minimally as they can. From there, you work downwards - take one of those subsystems and divide that up into sub-subsystems and/or classes, and consider the minimal interactions between those, etc. Your classes should pretty much write themselves, or at least that''s what I find.
One thing that has kept me out of a lot of trouble regarding naming my functions is the fact that my company decided to put a prefix on all of their functions (so the mission management planner/scheduler I was working on had all functions preceded with "PS") When I do that in my code, I can pretty much count on not running over anything standard.
-fel
-fel
Try looking at my source code for a game I made called "Wasted Space". It''s my second try at game programming. I''m pretty satisfied the way the structure of the program came out.
I''ve also been programming for 4 years now. I only know C/C++ though. Everything I know I learned from reading. I couldn''t afford the time for school.
Image preview:
[img]http://www.gamestead.com/images/ws.jpg[/img]
Download Wasted Space
I''ve also been programming for 4 years now. I only know C/C++ though. Everything I know I learned from reading. I couldn''t afford the time for school.
Image preview:
[img]http://www.gamestead.com/images/ws.jpg[/img]
Download Wasted Space
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement