Problem-specific design question

Say I have a Ninja with certain configurable skills. By configurable, I mean the program reads in a configuration file and adds them in at runtime. ie:

Code :

---

Ninja:
  color: Red
  Skills:
    - High Jump
    - Invisibility

---

Now, assume these skills need to dynamically add functionality to the Ninja class. As in, if we configure Ninja to have a High Jump skill, then the class needs to follow the CanHighJump Interface, with public void highJump() as a method.

Now there are two ways I can think of to go about this. My first reaction would be to have a Ninja class with String color and then use Reflection to add in the functionality. However, now I realize I could do it through a relational database as well. Have a Ninja class with String color, and forget about any objects relating Ninjas with Skills - instead, whenever I need to check for a skill, just make a call to the database retrieving the possible skills that class can use. Those are the only two truly dynamic solutions I can come up with, and I can't comprehend the design pros/cons of each. I have a feeling the database solution would be far more scale-able, but the reflection method would make most sense to me when coding. No need to guess which skills a Ninja has, because I could easily check for the interface.

I'm hoping someone can give me a bit of insight over a standard design solution for this problem. Whether it be one of the two I came up with, or more likely something i didn't think of.

Thank you,
Phil

With questions like these, it's almost always entirely dependent on how it fits best into your head, so what we say doesn't really matter.

But for what it's worth, I try to keep things as simple as possible- why not just have a List of Skills, and populate that based on the config file? Then each Skill would contain the code that does the work for that skill instead of an interface that is added to the Ninja class. To check whether a Ninja had that skill, you'd just check whether its List contained an instanceof that Skill (you could optimize it if you really felt the need, but that's the gist).

This would also allow you to have multiple instances of Ninja, each with different Skills, and it would make adding Skills later easier, IMHO.

But like I said, it's really up to how you see it.

Quote:

---

Originally Posted by KevinWorkman

Then each Skill would contain the code that does the work for that skill

---

Hmm, I'd say I'm familiar with java yet I don't understand how this would work. So say I want the Ninja to highJump, I would then...

Code :

---

ArrayList<Skill> mySkills = new ArrayList<Skill>
mySkills.add(new HighJump())
mySkills.add(new Invisibility())
 
Ninja myRedNinja = new Ninja("Red", mySkills)
Skill jump = myRedNinja.getSkill(HighJump)
if(jump != null){
  jump.executeSkill()
}else{
  //can't jump
}

---

The skill would gain a reference to the Ninja in the Ninja's constructor, thus executing the skill as expected. This code just reads strangely to me because it seems as if the Ninja is not the one jumping. Although i always read how reflection should be avoided - and this is basically doing the same thing as the relational database, so it's obviously not a bad solution. Two questions then.

1) I'm understanding your solution correctly?
2) Are there any large differences between using this solution as opposed to having the database? I mean in terms of functionality. The reason i ask is because this game Ragnarok uses a database to solve this exact problem, but I can't tell if it was a functional decision or solving a scaling problem (thousands of monsters with skills)

Quote:

---

Originally Posted by olsonpm

1) I'm understanding your solution correctly?

---

I think you get the gist of it, although I did leave the implementation details in the air.

Quote:

---

Originally Posted by olsonpm

2) Are there any large differences between using this solution as opposed to having the database? I mean in terms of functionality. The reason i ask is because this game Ragnarok uses a database to solve this exact problem, but I can't tell if it was a functional decision or solving a scaling problem (thousands of monsters with skills)

---

There is a huge functional difference, in that "my" way avoids anything like database lookups or reflection. But in terms of what is possible with either approach, they're probably pretty similar. I can't really speak for their decisions, but in that game, does each class of monster contain the same skills? I gathered that you wanted different Ninja instances to have different skills. And I would also predict that "my" approach would be completely scalable- thousands of Ninjas probably isn't too bad, as long as you aren't displaying them all at the same time (not that a database would fix that problem at all).

In the end, just go with whatever way fits in your brain the best. I like my way because I probably could have implemented it in the time it took to write this post, but I don't really know anything about databases. If you're a database guy, go that route. I don't really put much importance in the "what is the absolute best way to do this" first step, as everything is going to change by the end anyway.

I'm not a database guy, but I couldn't figure out why they used a database to solve that problem. I will post on their forum to understand that portion.

It seems to me that as long as your solution is scalable, it will be the route I take. I do not want to use reflection if I don't have to, and this is very flexible.

Thanks for your time,
Phil

Well, they probably used a database so that they could centralize it. Also, it's a bit of two different questions- they might be storing this information in a database, but that doesn't describe how they're using and accessing that data in the game. Sure, they're looking the data up in a database, but then what? I wouldn't be surprised if they're building a data structure similar to the one I suggested.

So, like I said, it's a bit of two different questions: how are you going to store the information (text config file, database, hardcoded, etc), then how are you going to represent that data in the data structures of the game?

But again, I know nothing about that game, so I can't speak for them.

Quote:

---

I wouldn't be surprised if they're building a data structure similar to the one I suggested.

---

I guess that makes sense. Where they might have 6000 monsters with associated skills, but the game only needs maybe 500 of them in memory at a time. That would be the only reason to use it in that situation correct? Because otherwise they might as well build the structure and hold it in memory, saving database calls.