Zedtho wrote:If I want to have multiple swords for the character (or atleast open the possibility for that) should I have a sword class (with an enum class in it for which type) and have either a separate animation for each sword where the user uses it or one animation for the user that is swinging its hands holding no sword and draw a sword animation ontop of that.
If the swords are going to behave differently, then have different sword classes through polymorphism, or use the enums if you aren't ready for polymorphism. If the swords are going to behave the same, but have different data, then just create a struct for each sword type, and pass the active type to a function in sword or sword constructor. If it's just different sprites with no behavior change and no value changes, load all the sprites for all the swords, create a current sword sprite pointer, and when the user changes swords, assign the address of one of those preloaded sprites to the current sword pointer.
Make the animations for the character and sword separate. You'll still have to draw the different sword animations, but not the character. The other way, If you have 5 swords, you'd have to draw the 8 directions for the charcter for standing, running and fighting times the 5 different swords, minus the three mirrord versions I supoose.
Just to give you a reference, the sprite class and alphasprite class in my project do practically the same thing and I could have used an enum to determine which PutPixel function to call, but they DO have different behavior for their drawing, so I made them different classes with the common stuff in the parent class.
The AnimationController class has the same behavior and can display either solid or transparent sprites, depending on which type were loaded into the frames object passed in. And in Frames, that's why I made the Frames::SpriteType enum, so I didn't have to make separate alphaframes and solidframes classes, they both would have the exact same behavior.
I'm going to try the same approach for the Particles I've been working on for a couple of days.
NOTE: Before you buy the book, check out the link in my tag,
Game Programming Patters. There is an online version you can read through and see for yourself if it's worth buy the hard back version or not. I've looked through it quite a few times over the past year, and have found it informative and it's a nice read. The explanations of how to use the different design patterns is clear, and the examples are nice, it's probably just me, but there's not enough depth for grasp the patterns just by reading it. I'm have to practice the crap out of it to get it to sink in. Not the authors fault, I'm sure most people get it the first few times.
Some patterns are easier to understand; Game Loop and Update are both things you're already doing. The strategy pattern ( or close to it ), is pretty much the style that chili has been using for teaching.