   Planning and coding objects efficiently
  Hello and thanks for the vast amount of information on gamedev.net. I'll try to make this short (I'm on my umpteenth rewrite.)Basically what I need to learn is a good planning & programming technique using objects. That's the short version; a long one starts with an example:As part of a RPG you generally have a bunch of different items. Weapons, armor, wands, potions and so on. So I'm thinking about all those goodies and realize that that's an extremely complex collection of objects; some items can be used, some equipped, some destroyed, some have charges, some impart magical effects on the player, some are plot critical etc. etc. It boggles my mind as to how those things are organized efficiently, from a programmatical, speed and space standpoint. On one hand you wouldn't want to give every item the ability to have every available property (eg have all items in a single class or struct) because you'd waste a lot of space. OTOH all these items are so diverse that it gets extremely complicated trying to define various classes of items. Potions would be fairly easy since they're all similar. Weapons a little more difficult, like melee weps (a sword), ranged weps and projectiles (bow and arrow) and weps that are both, as well as being their own projectile (a throwing dagger which could be used as a melee weapon). Or worse, something like a staff that allows for several types of magical effects and has charges, maybe is cursed AND is a melee weapon.Okay, so coding a RPG is getting WAY ahead of myself; what I'm trying to get at is the short version above; a solid way to break down a complex task into individual pieces, code them and then put them together into something meaningful without running into too many nasty suprises. A large part of that is just good planning and preparation, more (for now) is me learning more C++ and the biggie is being able to intuitively understand the entire process and then implementing it for any type of program, big or small. [edit] I've read and reread the 'beginner' stuff here and will continue to do so.I ran into mention of some sort of 'programming practices' book on GameDev; if anyone has the link I'd appreciate it. I need to get a couple more books too; the Petzold book on Windows Programming, something dealing with DirectX and maybe an impulse buy or three--I've bought or inherited something along the lines of 20 C/C++ books (going back to "The Black Art of Macintosh Game Programming") and god knows how many compilers. I use a total of 3 books and Visual C++ 6.0 which I need to upgrade. BTW I can't say enough good things about "Beginning C++ Game Programming" by Michael Dawson and the "C++ Primer Plus" (4th ed.) by Stephen Prata. Both have been essential and are well written.   
  It will pass a very long long time before you arrive to the "RPG collecting items" part of the game design if you're making it from the ground up, you alone.My humble advice for you on this is that you first determine the main technical characterists of the game you're planning to do, and then the tools you're going to need to make them work.Fore example: Windows only or Cross Platform / 3D or 2D / MP3 or MOD music / Network support or not? / if 3D, skeletal or key-framed / Which programs am I going to need for the art (commercial or free). And: do I know how to use all of the above? Can I do everything myself? When do I want to actually finish working on this? Do I want to finsh it someday?Once you're confident you have the complete development enviroment, only then start thinking about how you're going to structure the game data. I've experienced there is a lot to be done (and to be decided) if you're planning to do something seriously.   ;  Although I am not familiar with the actual programming side of what you're asking for, I have a bit of experience with the planning side - although you didn't mention it specifically I assume when you say "object" you mean you want to use an Object-Oriented approach (and that you're already regarding items as objects). In terms of planning these types of systems, UML is a good way to get your ideas down on paper - I'd strongly recommend finding out about that. There's plenty of information on the web, but if you'd prefer a book I found "Practical Object-Oriented Design With UML" by Mark Priestley to be a helpful introduction.As for your specific design question, the way I would design that would be to have a generic base object for each type of item (potion, weapon, clothing etc), containing nothing more than what is common to every item falling under that label.These objects/classes aren't very useful on their own, so one way to define particular "makes/brands" of these (i.e. sword, dagger, axe and so on) could be to use inheritance to define a new class, and add the extra information required in that. I'm not sure if I explained that very well, but here's an example:Object:Sword is a type of Object:WeaponObject:Leather Vest is a type of Object:ArmourDepending on how complicated you want to get, you could have several layers of inheritance, with more specific information as the classes become less generic:Longsword is a type of Sword; Sword is a type of Weapon; Weapon is a type of Item...Maybe that's not a great choice as the stats for a longsword could probably fit in the sword class without requiring another separate class, but hopefully you get the idea. Also this is largely down to your own personal preferences.A bit more thought will be required if you want to have classes for melee and ranged weaponry & then have something that can do both. (perhaps a cursed magical staff would inherit from a melee weapon class & also have variables of type Curse, Magic etc, which may or may not be classes themselves)   ;  One thing I would add to the discussion; dont worry about all the 1001 different items at this point. Make your game work using the 5-10 most basic items. When you do that, try to make your code design easy to extend with more items later on. With that huge amount of items and item properties, you will find inheritance to be very helpful in the long run, as Drewgreen said.Bottom line: Worry about how to design the basic concepts in you game before you even think about how many items/properties there will be in the end.   ;  It also helps when you realise that game objects are often best not being code objects. It's usually better to differentiate objects by their properties or function [equipable, usable, drinkable...].   ;  I was in the same boat as yourself, but I first started with...what kinds of capabilities did I want to accomplish with my object system? I took sort of a neverwinter nights approach in the design. Have your base item object, then inheret from that some other base items.ItemItem:SwordItem:PotionItem:BookI also knew that I wanted this system to be very flexible in what items can do, for instance some swords have powers you can activate, some misc. items you can attack with... I then created an action object that gets attached to each item instance that describes what it can do.Item:Swordhas Action:ActionEquiphas Action:ActionAttackhas Action:ActionUseItem:Potionhas Action:ActionUseThen finally each Action object has Effects and Requirements, these indicate what happens when that ability is triggered and if the action can be used by the player.Hope this helps get you started, there are several approaches you could take in designing your object system. You need to find what works for you and your system.   ;Quote:Original post by pulpfistOne thing I would add to the discussion; dont worry about all the 1001 different items at this point. Make your game work using the 5-10 most basic items. When you do that, try to make your code design easy to extend with more items later on. With that huge amount of items and item properties, you will find inheritance to be very helpful in the long run, as Drewgreen said.Bottom line: Worry about how to design the basic concepts in you game before you even think about how many items/properties there will be in the end.A few basic items is where I'm at now. Here's the specific example:Game: The player must hit a target from his ship, using aim (degrees) and a speed to fire the bullet. A defined 2D playing field also contains a star which exerts gravitational pull on the bullet. Hit the target before the ship's energy level reaches 0 (1 point energy per shot). If the bullet hits the ship, game over.That's it. Simple but this will allow me to apply all sorts of more advanced things to it (like a GUI, more granular Bullet movement etc.) as I learn.How I'm thinking about this is that I should have two classes and four derived classes:Piece - the playing pieces (Ship, Star, Target and Bullet are all derived classes from Piece).Map - the playing field -- right now it's just a width and height (0,0 to x,y are the bounds) and a couple of bools, one to allow Bullets to bounce of the edge of the field; the other to allow Bullets to roll over from one edge of the field to the opposite edge. If both are false the shot ends if it crosses any boundary. Both cannot be true.Now's where I'm running into questions, because of several things I need to do to each Piece:1) place a Piece on the map (set piece x,y coordinate and width/height, ensuring no part of the piece is off the map)2) adjust the Bullet's speed based on the distance from the Star and the Star's gravity.3) change a Piece's coordinates (the Bullet so it can move)4) check for collisions between a bullet and another Piece5) do something if a Bullet travels off the playing field (either end the shot or adjust the Bullet's position and possibly speed, depending on whether shots bounce, roll over or neither.)That's not quite everything; for example I need to get input from the user to set the ship's aim, but something like that seems to fall into the Ship class quite nicely.So my question is, what handles these? I have 4 options:1) Map member functions2) Piece member functions3) new class member functions4) main() (or some function in the main .cpp source file)#4 is not really an option, not when I want to abstract the objects.#2 doesn't make much sense to me either. Pieces 'are', they do not 'do' for the most part. Possibly excepting the Bullet updating its own position (but it wouldn't make sense for the Bullet to calculate the change in speed based on gravity, would it?)That leaves me with #1 or #3, and I'm not sure which I should use. This example is related specifically to what I'm doing NOW, but I'm trying to understand the *concept* so I can apply it to anything.   ;  More info. This is the way I drew it up using a third class. It seems like it makes sense, though I'm still a little unsure about the bullet movement, because down the road it's going to become more granular; eg right now if a Bullet is moving at a speed of 20 (in any direction) it could skip right over a 10x10 piece (which for now all pieces will be). So I'm essentially going to need to break down movement into turns and rounds when it comes to bullet travel to make sure it hits anything along it's arc.Note: By the layout you can tell that I'm not using 'protected' class data and member functions yet. That will come in time:MEMBER DATAMap hasbounds, rollover, bouncePiece hascoordinates (x,y), size (x,y), typePiece::Ship hasaim, energyPiece::Star hasgravityPiece::Bullet hasprecise coordinates (double vs. int), speed, lifetimePiece::Target has(nothing)PieceMgr hasarray of pointers-to-Piece (which I can do with derived classes; not sure if a vector will handle it though. something to learn)MEMBER FUNCTIONSMap hasInit - set bounds, rollover, bouncegetBounds - get boundsgetAttrib - get rollover & bouncePiece hasInit - set coordinates and sizegetCoord - get coordinatessetCoord - set coordinatesPiece::Ship hasgetAim - get the ship's aimsetAim - change the ship's aimgetEnergy - get the ship's energysetEnergy - change the ship's energyPiece::Star has(nothing)Piece::Bullet hasgetSpeed - get the current speedsetSpeed - change the speedgetPCoord - get precise coordinatessetPCoord - set precise coordinatesgetLife - get lifetime of bulletsetLife - set lifetime of bulletPiece::Target has(nothing)PieceMgr hasplacePiece - put piece on Map (checking bounds) using Piece::Init - put pointer to Piece in arrayapplyGrav - calculate the effect of gravity on the Bullet's speed and then modify the Bullet's speed (using Bullet member function)checkCollision - check Bullet's coordinate against the coordinates of all other pieces, taking into account each piece's sizemoveBullet - modify Bullet's coordinates (both sets) - check coordinates against map bounds and modify coordinates/speed as necessary (if rollover or bounce are true) - return false if Bullet has ended (falls off map or lifetime expires)   