Game Design: 1 Class per ability or 1 Class for all abilities

[0026sd]

Hey everyone,

I'm fairly new to Java and even newer to Java gaming.

I'm creating a tournament-style fighter game (2D) and each character has a set of 3 abilities: Punch, Kick, and a Special. What I'm wondering is if I should create a class for each ability (in this case 3 classes) or if I should just have 1 big class for all abilities using conditional statements and arguments to determine the ability used, amount of damage, etc.

I'm sure that I can do either well enough however I'm looking at this from both an efficiency/portability/reusability standpoint as well as for best practices.

Thanks!

Scott

EDIT: I just thought of something else. perhaps it would be best to create a parent class "Abilities" which would extend to the children class "Punch", "Kick", and "Special"...

ehh.. this is so complicated.

[KevinWorkman]

Hmm, sounds like you might want to have one Ability class, then either extend it (Punch extends Ability, Kick extends Ability, Special extends Ability) or pass in parameters to set each Ability instance's data (new Ability("Punch", 3) creates an Ability called Punch that causes 3 damage, for example). In the end it's really up to you though. I wouldn't worry too much about it at this stage in the process.

[0026sd]

Hmm, sounds like you might want to have one Ability class, then either extend it (Punch extends Ability, Kick extends Ability, Special extends Ability) or pass in parameters to set each Ability instance's data (new Ability("Punch", 3) creates an Ability called Punch that causes 3 damage, for example). In the end it's really up to you though. I wouldn't worry too much about it at this stage in the process.

Hi Kevin,

Thanks for your quick reply. Both of those options seem reasonable to me. I do feel as though the first option would be best even from an organization perspective. Perhaps it might make for easier reading later on.

Then, I'm probably over-complicated the situation. Ha.

Thanks again.

[KevinWorkman]

It really depends on how different the Abilities are. If they simply have different names and damage values, then just having one class that you instantiate with the correct values makes sense. But if each Ability is going to be very different or have its own implementation of some method, then inheritance seems best to me. Either way, having one big class with all abilities and a bunch of if statements is probably not the way to go.

But yeah, I think it's a mistake to worry too much about doing things the right way, especially if you're relatively new to programming. No matter which way you choose, in six months you're going to cringe when you look at your code- that's simply the nature of programming. So go the way that makes the most sense to you, and you can always change it later.

[0026sd]

It really depends on how different the Abilities are. If they simply have different names and damage values, then just having one class that you instantiate with the correct values makes sense. But if each Ability is going to be very different or have its own implementation of some method, then inheritance seems best to me. Either way, having one big class with all abilities and a bunch of if statements is probably not the way to go.

But yeah, I think it's a mistake to worry too much about doing things the right way, especially if you're relatively new to programming. No matter which way you choose, in six months you're going to cringe when you look at your code- that's simply the nature of programming. So go the way that makes the most sense to you, and you can always change it later.

Wonderful. Thank you for taking the time to respond -- it helped a lot.

[JosAH]

Google for "role pattern"; your abilities are the roles.

kind regards,

Jos

[Fubarable]

But yeah, I think it's a mistake to worry too much about doing things the right way, especially if you're relatively new to programming. No matter which way you choose, in six months you're going to cringe when you look at your code- that's simply the nature of programming. So go the way that makes the most sense to you, and you can always change it later.

Amen. This reminds me of a clever concept I've read about recently called "trace bullet" programming, the idea being that often the best way to get a complex project off of the ground is to first write quick and dirty code that does what you want, prototype if you like, and then use successive improvements to make your code prettier and of higher quality.

[0026sd]

Amen. This reminds me of a clever concept I've read about recently called "trace bullet" programming, the idea being that often the best way to get a complex project off of the ground is to first write quick and dirty code that does what you want, prototype if you like, and then use successive improvements to make your code prettier and of higher quality.

You know, I come from a web-programming background and I very much support this "trace bullet" style that you speak of in that context. Since I've begun programming in Java, however, I've been getting the vibe that it's something you really need to plan out meticulously before you can begin writing anything. Perhaps because switching my mind to thinking in obj-orientation is limiting me from writing these prototypes but I just feel like there are way too many things to consider when building a program.

I hope I can look at this post again in 6 months and chuckle!! How naive I was, I'll say.

[JosAH]

You know, I come from a web-programming background and I very much support this "trace bullet" style that you speak of in that context. Since I've begun programming in Java, however, I've been getting the vibe that it's something you really need to plan out meticulously before you can begin writing anything. Perhaps because switching my mind to thinking in obj-orientation is limiting me from writing these prototypes but I just feel like there are way too many things to consider when building a program.

I hope I can look at this post again in 6 months and chuckle!! How naive I was, I'll say.

I have been using OO languages and systems since the 1980s; I've seen the first versions of C++ with single inheritance and no templates and a lot of other crappy, half cooked languages. I normally play a game of CRC in my head when I have to design something. CRC (Classes Responsibilies Collaboration) is a process actually but I made it into a small mental game. If you think of it, if you have to design some software, you usually think of "it should do this and it should do that and it should do so and so". That it thing should do everything, which is not fair. Think of each and every 'it' as a separate thing, a separate object, possibly an instantiation of a separate class; but first let those 'it' things do what they have to do and give them a name, no matter which one. Make those 'it' things as simple (stupid?) as possible, i.e. no Swiss Army Knives nor magic allowed there. Add more different 'ít' things when needed and don't feel guilty when you remove other 'it' things when they're not needed.

When you can manage to let those 'it' things play the entire game, i.e. they can solve your problem for you, you have found the first stages of your solution: you have found your Classes, you have found the Collaboration of the instantiations of your classes and you have found the several Responsibilities (which 'it' does what). The fun part of it all is that you can play this game in your head, laying on your couch, smoking a sigarette, drinking a Grolsch, no fancy tools are needed; even pen and paper is optional.

You can start writing the code for your classes (the 'it' thing blueprints) and slowly by slowly you can see how your imagination becomes a true 'living' thing in that stupid computer. That's the way I do it and have done it for years.

kind regards,

Jos

[0026sd]

I have been using OO languages and systems since the 1980s; I've seen the first versions of C++ with single inheritance and no templates and a lot of other crappy, half cooked languages. I normally play a game of CRC in my head when I have to design something. CRC (Classes Responsibilies Collaboration) is a process actually but I made it into a small mental game. If you think of it, if you have to design some software, you usually think of "it should do this and it should do that and it should do so and so". That it thing should do everything, which is not fair. Think of each and every 'it' as a separate thing, a separate object, possibly an instantiation of a separate class; but first let those 'it' things do what they have to do and give them a name, no matter which one. Make those 'it' things as simple (stupid?) as possible, i.e. no Swiss Army Knives nor magic allowed there. Add more different 'ít' things when needed and don't feel guilty when you remove other 'it' things when they're not needed.

When you can manage to let those 'it' things play the entire game, i.e. they can solve your problem for you, you have found the first stages of your solution: you have found your Classes, you have found the Collaboration of the instantiations of your classes and you have found the several Responsibilities (which 'it' does what). The fun part of it all is that you can play this game in your head, laying on your couch, smoking a sigarette, drinking a Grolsch, no fancy tools are needed; even pen and paper is optional.

You can start writing the code for your classes (the 'it' thing blueprints) and slowly by slowly you can see how your imagination becomes a true 'living' thing in that stupid computer. That's the way I do it and have done it for years.

kind regards,

Jos

Hi Jos,

Wonderful insight! I appreciate your mentallity about building programs and share your contempt for these stupid machines we call computers (ha ha)! Well, actually, without these computers I suppose I wouldn't have 3 out of 4 of my hobbies so I guess there's something good to say about them.

As for this CRC method I think it's something I can really get into as I'm constantly mulling over the details of a project in my head. Any time I have a second to think it's usually about whatever I'm working on so this is perfect!

To everyone who has replied to this post I thank you very much. You've helped me make a little more sense of this overwhelming world that is OO programming.

[KevinWorkman]

Amen. This reminds me of a clever concept I've read about recently called "trace bullet" programming, the idea being that often the best way to get a complex project off of the ground is to first write quick and dirty code that does what you want, prototype if you like, and then use successive improvements to make your code prettier and of higher quality.

It's almost creepy how similar that tracer bullet theory is to my every day approach. Make something simple that proves a theory and shows how the requirements might be accomplished, then adapt from there.

I think too many people get caught up in the mentality that they have to plan out every atom of a program before they start writing it. Even if they do come up with the perfect design, and even if their requirements don't change ten times a week, that type of person almost never actually completes a project. Meanwhile, I've put together 3 different programs that prove a concept, even if maybe not in the most well-designed way. But something that works is better than something that doesn't work (or isn't finished), no matter how well-designed the thing that doesn't work is.

[JosAH]

Refactorings are of great help here (see Martin Fowler)

kind regards,

Jos